RE: Non- and Partial-FRBR Metadata

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
>

Received on Thursday, 16 September 2010 13:23:26 UTC