Print

Print


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