Hi Karen –
During the development of 2.0 there was considerable analysis of and discussion (with other institutions as well as ontology experts) of many of these sorts of ontological issues, including constraints imposed by domains and ranges on properties. And while I’m not completely convinced that bibframe 2.0 has significantly fewer constraints than 1.0, here are some of our thoughts.
Unexpected “constraint” imposed by a constraint
In 1.0, titles applied only to Works and Instances. Subject and creators applied only to Works. What we found was that for some (admittedly rare) cases, title, creator, and subject could apply at the Item level.
On the other hand, in some cases removing a domain would suggest a rather significant re-thinking of the BIBFRAME model. For example, only a Work can have an Instance so the domain of bf:hasInstance remains bf:Work. (Someday perhaps there will be a use case for an Instance to have an Instance, but that would likely require a change to the underlying model.)
Complexity of constructed classes
Let’s say you want to restrict titles to Works, Instances, and Items, by imposing a domain on property bf:title. You can do that in a number of ways, including constructed or artificial classes. We decided that the benefit of doing this is not worth the cost of the added complexity this would impose.
As another example consider property hasEquivalent. A Work can be equivalent to another Work, an Instance to an Instance, or an Item to an Item. But a Work cannot be equivalent to an Instance, or an Instance to an Item, etc. In other words, the resource type of the subject (Work, Instance, or Item) must be the same as the resource type of the object. This would be a logical constraint to impose, if it could be imposed in a sensible manner. But it cannot, and so the range of hasEquivalent is unconstrained.
On the other hand, for property hasExpression both the subject and object must be a Work, and so both its domain and range are specified as bf:Work.
BIBFRAME supports the capability to provide information from an external (non bibframe) namespace.
A bibframe Title, for example, is a resource of type bf:Title. If it were intended that the object of property bf:title must always be in the bibframe namespace then the range of bf:title would be bf:Title. The range of bf:title is unconstrained to allow its object to be some title resource defined in a different namespace.
If there are specific properties that you have questions about, please mention them.
> -----Original Message-----
> From: Bibliographic Framework Transition Initiative Forum
> [mailto:[log in to unmask]] On Behalf Of Karen Coyle
> Sent: Monday, January 16, 2017 3:10 PM
> To: [log in to unmask]
> Subject: [BIBFRAME] BIBFRAME 2.0 question
> BIBFRAME 2.0 removed the domains and ranges from properties, greatly
> opening up the vocabulary to non-constrained definitions of works and
> instances. What I would like to hear is whether there were specific use cases
> that informed this change.
> I ask this both out of my own curiosity but also as a member of the "PCC
> Standing Committee on Standards/Linked Data Advisory Group on the Work
> Entity and Work URIs in MARC Group". We've been asked to do a study
> comparing some of the varying interpretations of "work" (RDA, FRBRoo,
> BIBFRAME, and others). Knowing *why* the change from BIBFRAME 1.0 to
> 2.0 made the decisions it did would be very helpful.
> Karen Coyle
> m: +1-510-435-8234
> skype: kcoylenet/+1-510-984-3600