RE: Non- and Partial-FRBR Metadata

Can someone give an example of how a blank node will connect a  
manifestation to a Work? Is the predicate still "is expression of"?

kc

Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:

> I like Antoine's suggestion. It's lightweight and solves my concern
> about consistent queries in aggregated RDF data.
>
> I don't like blank nodes as a rule, but this seems like a clear
> exception.
>
> Jeff
>
>> -----Original Message-----
>> From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
>> Behalf Of Antoine Isaac
>> Sent: Thursday, September 16, 2010 6:46 AM
>> To: public-lld@w3.org
>> Cc: public-lld
>> Subject: Re: Non- and Partial-FRBR Metadata
>>
>> Hi Ross, Jeff,
>>
>>
>> > On Wed, Sep 15, 2010 at 11:28 AM, Young,Jeff (OR)<jyoung@oclc.org>
>> wrote:
>> >> The counter argument is that the dcterms:hasVersion/isVersionOf
>> solution
>> >> isn't documented anywhere and other solutions are plausible.
> Without
>> a
>> >> systematic connection, SPARQL connections between Work and
>> Manifestation
>> >> become a guessing game.
>> >>
>> > You'll notice that in my example I didn't use
>> > dcterms:hasVersion/isVersionOf, but rather rda:workManifested
> (which,
>> > actually, looking more closely at it, doesn't seem right either: "A
>> > work embodied in a manifestation." with no range -- implying a
>> > literal?).  My point actually isn't either of those, it just is
>> making
>> > the point that a direct relationship between M and W is useful,
>> simple
>> > and eliminates a lot of hand waving and teeth gnashing with no
>> > discernible downside.
>> >
>> > And while, no, dcterms:hasVersion/isVersionOf isn't documented
>> > anywhere, if this group saw it as useful (or any other combination
> of
>> > inverse relationships, including something new) it could document,
>> > recommend and endorse it.  Then your semantics are there.  There is
>> > practically zero RDF/FRBR/RDA data to draw upon presently - I don't
>> > see the point in stubbornly sticking to the letter of a model that
> is
>> > currently unproven, unused and doesn't deal well with our hundreds
> of
>> > millions of legacy records.  Is the FRBR model so immutable that it
>> > cannot exist with the addition of a direct relationship between W
> and
>> > M?  If it eases the transition of the old into the new and reduces
>> > costs, wouldn't that generally be considered beneficial?
>> >
>> >> The question is, how much grief will the RDF designer get for
>> wanting to
>> >> coin a new 303 URI? If the framework is flexible, then go ahead and
>> have
>> >> them coin a 303 URI for Expression:
>> >>
>> >> http://example.org/expression/45678 a frbr:Expression .
>> >>
>> >> My suggestion of using a hash assumes that Expression will always
> be
>> a
>> >> twin to Work and is easily piggybacked on it without fighting for
>> >> infrastructure support. If and when Expressions deserve 303 URIs,
>> the
>> >> old hash URIs can migrate to the 303 URI using owl:sameAs.
>> >>
>> > Unless assertions are applied to the Fauxpression and then you get
>> > into reconciliation, which is expensive and most likely requires
>> human
>> > intervention.
>> >
>> > If the Fauxpression is, indeed, just a placeholder that we aren't
>> > expecting to add any assertions to -- again, I ask, what's the
> point?
>> > Just to make things more complicated?
>>
>>
>> Btw could we use RDF blank nodes as an alternative here? That would
>> bring no extra URI, and *if you think you need it*, the ability to
> have
>> these FRBR statements that link the W and the M (and thus to access
> one
>> from another) .
>>
>> Jeff's solution seems better if one wants to reconcile one day the Es.
>> But if we manage to reconcile Ws and Ms properly, I doubt that
>> reconciling *non-described* Es would really bring anything useful
>> addition for an application.
>>
>> Cheers,
>>
>> Antoine
>>
>
>
>
>



-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Thursday, 16 September 2010 13:57:56 UTC