Print

Print


Thanks, Ray. I'll try to incorporate some of this into the report for PCC.


kc


On 1/27/17 12:36 PM, Denenberg, Ray wrote:
>
> 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.
>
>  
>
>  
>
> *Extensions*
>
>  
>
> 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.
>
>  
>
> Ray
>
>  
>
>  
>
>  
>
> > -----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.
>
> >
>
> > Thanks,
>
> >
>
> > kc
>
> >
>
> > --
>
> > Karen Coyle
>
> > [log in to unmask] <mailto:[log in to unmask]> http://kcoyle.net
>
> > m: +1-510-435-8234
>
> > skype: kcoylenet/+1-510-984-3600
>

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600