Print

Print


On 11/11/14 9:20 AM, Robert Sanderson wrote:
>
> My interpretation (which does not imply endorsement) is that the 
> majority of bf predicates are currently limited by domain and range of 
> either Work or Instance,

By my crude calculation on the vocabulary, less than half are limited by 
domain to Work or Instance, and only a handful have Work or Instance as 
their range. That does not, of course, necessarily reflect what the 
BIBFRAME software provides, and it looks to me like relationships 
between W and I and authorities are as yet under-defined.

Perhaps we should agree on language to use to specify whether we are 
talking about the BIBFRAME application or the BIBFRAME vocabulary. The 
application does appear to act on an implicit profile that provides more 
specificity than the RDF vocabulary itself. Having those rules explicit 
in a profile (or even a document) would make it easier to study and 
discuss them. For example, I had a vague recollection of a 
MARC-to-BIBFRAME document, but I can't find anything at the moment. When 
I have questions about the transformation, I usually just run a MARC 
record through the transformation tool and look at the output, but 
that's hardly ideal.

> and the intent is that Work / Instance / HeldItem are intended (but 
> not formally specified) to be disjoint.

This is another area where a profile would be of use. Having disjoint 
classes in the "wild" can lead to some unfortunate results when 
reasoners *are* applied, so keeping a closed world concept of 
disjointness out of the RDF vocabulary itself has benefits. The profile 
could document this rule without altering the vocabulary itself. (This 
also confirms for me that some of the statements made in this discussion 
are based on a "closed world assumption" which isn't explicitly stated, 
and which isn't consistent with the RDF vocabulary as defined today.)

>  There have been many discussions on the list and elsewhere about 
> whether a predicate is to be used on a Work or Instance, and how hard 
> it is to generate that from MARC records. The resolution of that 
> complexity is non-trivial and inevitably there will have to be 
> trade-offs between purity and practicality.

Recall the recommendations of the A-V BIBFRAME study group[1 - 
recommendations on final page], who need to be able to use some 
properties currently "confined to"[2] bf:Instance instead with bf:Event. 
And that's only one non-print group that weighed in. I would expect 
others to also have special needs. Any of these special needs could be 
defined with a profile that documents their specific needs, and drives 
their editing and display applications.

However, my understanding is that the thinking that you are representing 
(but which is probably not yours alone) is that the GLAM metadata world 
must decide on a single set of rules for its data to be "practical." I 
was hoping that with the move to RDF we could allow our specialist 
communities to finally have their needs met, while still creating 
inter-linked bibliographic data. Maybe there is a way to have that 
discussion as a "fork" while others gain experience with BIBFRAME as 
defined today as a single set of metadata creation rules.

kc
[1] http://www.loc.gov/bibframe/pdf/bibframe-avmodelingstudy-may15-2014.pdf
[2] actually, the properties have a domain of bf:Instance, but which 
does not confine their use

>
> R
>
> On Mon, Nov 10, 2014 at 12:57 PM, Karen Coyle <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
>
>     On 11/10/14 10:48 AM, Robert Sanderson wrote:
>
>
>
>         However I'll object to the two level characterization on the
>         following grounds:
>
>         1.  It's at least three level with Work, Instance and HeldItem.
>
>         2.  It's really the four level FRBR model, given the
>         bf:expressionOf predicate, just that *cough* you have to infer
>         that the subject of that predicate is an Expression-y type of
>         Work, rather than a Work-y type of Work.
>
>         Yes, I would prefer to have bf:Expression as a class and be
>         done with it, or to get rid of the FRBR work around predicates
>         (expressionOf and hasExpression)
>
>
>     Rob, in your interpretation (because I'm not sure that this is
>     baked into the BF vocabulary) is every predicate limited in its
>     use to only one of the 'levels'? Or is there some fluidity between
>     the classes of bf:Work, bf:Expression and the annotation bf:HeldItem?
>
>     kc
>
>
>
>
>
>
>
>
>         -- 
>         Rob Sanderson
>         Technology Collaboration Facilitator
>         Digital Library Systems and Services
>         Stanford, CA 94305
>
>
>     -- 
>     Karen Coyle
>     [log in to unmask] <mailto:[log in to unmask]> http://kcoyle.net
>     m: +1-510-435-8234 <tel:%2B1-510-435-8234>
>     skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600>
>
>
>
>
> -- 
> Rob Sanderson
> Technology Collaboration Facilitator
> Digital Library Systems and Services
> Stanford, CA 94305

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