Remove bib:Origin class

[rjyounes]

Rationale: hasOrigin is similar to hasSource or subject: it's a relationship rather than a type of entity.

Involves three changes:

• Remove bib:Origin class
• Remove typing of origin individuals
• Remove range specification on bib:hasOrigin.

Consider deprecating bib:Origin class rather than removing, for backward compatibility. But then in order to maintain full backward compatibility of all changes, need to deprecate bf:hasOrigin and define a new predicate without a range specification.

[sfolsom]

Deprecation and a new property without the range specification sound good to me. Would the new property have the same name on a new ontology version URI?

[rjyounes]

It wouldn't have to be a new property, would it? I was imagining removing the range from the existing property.

[sfolsom]

But is that good practice? idk. (probably doesn't matter in this stage of the model, but eventually we'll want to think about these type changes; implementors might be looking for these entailments)

[rjyounes]

Is it good practice to remove the range, do you mean? That would be a non-backwards-compatible change, technically. I don't think we have to create a new term in order to change an existing term, do we? For this release, Jim and Simeon have proposed only a minor upgrade even though we have non-backward-compatible changes, because it seems odd (to me as well) to already release version 2. They thought it was acceptable because as yet we have no implementers, and we can add a note on the release stating that we're making an exception. In the long run we may need to modify the criteria, else I can see us being at version 4 or 5 pretty soon.

Originally this idea came from Christine - she thought Origin was like Source - that something is inherently an origin, but rather that something being the origin of something else is a relationship between two resources. That makes sense to me.

[eslao]

I agree (surprise!) with what I said before, and I'm fine with removing the range from bib:hasOrigin and not creating a new class.

[rjyounes]

Not creating a new property?

[eslao]

@rjyounes ...Not creating a new property. Thanks.

[rjyounes]

Adding to Q2 2017 milestone but it's fine if we defer it.

[rjyounes]

Looking at this again, I don't find it clear-cut. First, hasOrigin already has an unspecified domain. This means that objects of the predicate may be independent resources, in which case the semantics of origin as a relationship between entities applies. Objects may also be named individuals of type bib:Origin, such as :addedTitlePage, :cover, etc. Note that these do not denote specific resources but rather (the beginnings of) a controlled vocabulary of origins. Where we want to create a binding resource (as ArtFrame and RareMat are proposing in certain cases) that could be the origin.