On 11/11/14 9:20 AM, Robert Sanderson wrote:
[log in to unmask]" type="cite">

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.

[log in to unmask]" type="cite">
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.)

[log in to unmask]" type="cite">
 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

[log in to unmask]" type="cite">

R

On Mon, Nov 10, 2014 at 12:57 PM, Karen Coyle <[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] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-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