On Tue, Jul 29, 2014 at 6:44 AM, Trail, Nate <[log in to unmask]> wrote:

Are you saying that because there are 2 links, one in each direction, that it unnecessarily overly complicates the ways of querying between resources?


Yes... if you can't assume that /both/ will always be present, then you need to check both of them rather than just one.  You could assume that both are always present, for example by a rule that infers the inverse when the triple is added to the triplestore, but it seems unlikely that all systems would support that. Especially if it's not a requirement.

 In regular cataloging workflow, we believe most will use:

bf:Instance bf:instanceOf bfWork;

and more rarely,

bf:Work bf:hasInstance bf:Work,

but didn’t want to preclude doing it that way.


It doesn't really matter which predicate is used, they're just triples at the end of the day.  But there should be one way to do it.
 

 For  example, a movie comes out and the bf:Work and bf:Instance are created, and then subsequent DVD and other formats come out, which will mean more Instances pointing back to the original Work.


Sure, but you can add a new triple with the Work as subject as easily as you can add a triple with the Instance as subject ... there isn't a "record" any more.

In fact relying on bf:hasInstance is pretty impractical in the open, because a system would have to know all the places to query that may have new Instances that point to them, and the bf:Work would become prohibitively large.


Right, when serializing the Work, it would have all of the hasInstance predicates that the system knows about.  So for serialization it would be better to use instanceOf if there are many many instances and the intent is to keep the Work resource's serialization short, but it's the same number of triples (and hence the same amount of data) at the end of the day if you're getting everything.  

Overall my preference is for instanceOf, as serializing the work separately from its instances is a valid thing to want to do.

Hope that helps,

Rob
 



 Yes, the query in the UC doc is one of the many, many possible ways to encode a title using the current vocabulary.

 

There is, in English rather than SPARQL:

 

* Work with bf:title ( http://bibframe.org/vocab/title.html )

* Instance with bf:title

* Work with bf:titleStatement ( http://bibframe.org/vocab/titleStatement.html )

* Instance with bf:titleStatement

* Work with bf:label ( http://bibframe.org/vocab/label.html ) N.B. look at the example here

* Instance with bf:label

* Work with bf:workTitle of a bf:Title

* Instance with bf:instanceTitle of a bf:Title

* Work with bf:titleVariation of a bf:Title 

* Instance with bf:titleVariation of a bf:Title 

* Instance with bf:abbreviatedTitle of a bf:Title

* Instance with bf:keyTitle of a bf:Title 

 

* Multiplied by two ways to get from Work to Instance (bf:hasInstance, bf:instanceOf)

 

* Multiplied by the matrix of title-string-holding attributes of bf:Title:

  * bf:Title uses bf:titleValue alone

  * bf:Title uses bf:titleValue and bf:subtitle

  * ...plus bf:partTitle, bf:partNumber, bf:titleAttribute, bf:titleQualifier 

  * bf:label could also be used instead of bf:titleValue

 

And this without translation, transliteration or the other complexities introduced in the thread's discussion.

 

Notes:

 

* Presumably one could have a HeldItem/HeldMaterial with a title different from its Instance, if someone physically modified a particular copy.  This isn't in the model at the moment, but thinking in an archival way rather than library way I don't see why not.  I leave this as an exercise for the reader.

 

Rob 




--
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305