W3C home > Mailing lists > Public > public-lld@w3.org > September 2010

Re: Non- and Partial-FRBR Metadata

From: Ross Singer <ross.singer@talis.com>
Date: Wed, 15 Sep 2010 12:29:24 -0400
Message-ID: <AANLkTikdRBXsLO-Fqz86Hv7ebkQF=c0P9uEF+5+tDt1+@mail.gmail.com>
To: "gordon@gordondunsire.com" <gordon@gordondunsire.com>
Cc: "Young,Jeff (OR)" <jyoung@oclc.org>, public-lld <public-lld@w3.org>, Karen Coyle <kcoyle@kcoyle.net>
Gordon, these restrictions/requirements only apply to FRBR as an
abstract model, however, though, right?

It seems like it would be unrealistic (and probably impossible) to
require and enforce them in RDF.  We can infer that a Manifestation
belongs to *some* Expression without the existence of that Expression
being in hand, right?

-Ross.

On Wed, Sep 15, 2010 at 12:23 PM, gordon@gordondunsire.com
<gordon@gordondunsire.com> wrote:
> Jeff and others
>
>
>
> The assumption that "Expression will always be a twin to Work" is
> practically correct.
>
>
>
> FRBR gives cardinality restrictions on the WEMI "chain":
>
>
>
> An Item is an exemplar of one-and-only-one Manifestation;
>
> A Manifestation is an embodiment of one-or-more-than-one (i.e. at-least-one)
> Expression;
>
> An Expression is a realization of one-and-only-one Work.
>
>
>
> There are no such restrictions in the inverse direction, so a Work does not
> need to have an Expression, etc. However, I suspect that expressionless
> Works will be rare or short-lived; e.g. "lost" Works for which only a brief
> reference such as author and title are known, or Works yet to be expressed
> but cited in publisher announcements.
>
>
>
> Cheers
>
>
>
> Gordon
>
>
>
> On 15 September 2010 at 17:28 "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.
>>
>> 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.
>>
>> Jeff
>>
>> > -----Original Message-----
>> > From: rxs@talisplatform.com [mailto:rxs@talisplatform.com] On Behalf
>> Of
>> > Ross Singer
>> > Sent: Wednesday, September 15, 2010 11:13 AM
>> > To: Young,Jeff (OR)
>> > Cc: Karen Coyle; public-lld
>> > Subject: Re: Non- and Partial-FRBR Metadata
>> >
>> > On Wed, Sep 15, 2010 at 10:57 AM, Young,Jeff (OR) <jyoung@oclc.org>
>> > wrote:
>> > > Another solution would be to identify the expression as a hash on
>> the
>> > > work URI. For example:
>> > >
>> > > <http://example.org/work/12345> a frbr:Work .
>> > > <http://example.org/work/12345/#frbr:Expression> a frbr:Expression .
>> > > <http://example.org/manifestation/98765> a frbr:Manifestation .
>> > >
>> >
>> > This would work, sure.  The only downside I see is that it would
>> > require reconciliation and maintenance should a real Expression
>> > eventually come along.
>> >
>> > Personally, I think sacrificing the purity of FRBR (via
>> > rda:workManifested, etc. with no Expression declared) would be a more
>> > desirable alternative than the potential costs associated with
>> > shimming in some Fauxpression just to meet the (unrealistic, frankly)
>> > requirements of a(n ivory tower-esque) data model.
>> >
>> > Honestly, does the internet break, do libraries spontaneously combust,
>> > does data turn into meaningless gibberish all because somebody left
>> > out an Expression resource?
>> >
>> > -Ross.
>>
>>
>>
>
Received on Wednesday, 15 September 2010 16:30:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 15 September 2010 16:30:00 GMT