RE: Non- and Partial-FRBR Metadata

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 .

Then you could then use the hash URI for real FRBR property
relationships:

<http://example.org/work/12345> frbr:isARealizationOf
<http://example.org/work/12345/#frbr:Expression> .
<http://example.org/work/12345/#frbr:Expression>  frbr:isAnEmbodimentOf
<http://example.org/manifestation/98765> .

This would imply a one-to-one relationship between Work and Expression
that isn't necessarily true in FRBR, but it should suffice until real
use cases come along. 

> -----Original Message-----
> From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
> Behalf Of Ross Singer
> Sent: Wednesday, September 15, 2010 10:06 AM
> To: Karen Coyle
> Cc: public-lld
> Subject: Re: Non- and Partial-FRBR Metadata
> 
> On Mon, Sep 13, 2010 at 12:53 PM, Karen Coyle <kcoyle@kcoyle.net>
> wrote:
> 
> > As defined, FRBR only allows relationships from Expression to Work,
> > and Manifestation to Expression. (I will gloss over Item because
> there
> > is little item-level information in the records I am concerned
with.)
> > What I need, however, is a relationship between a Manifestation
(with
> > some Expression information) and a Work. The same Expression
> > information may be found in more than one bibliographic entry so
> there
> > is no true Expression entity that is defined in the data.
> 
> Karen, we've also run into this problem.  The way we've worked around
> it, generally, is to basically consider the Expression "optional" (in
> fact, at this stage, we don't even mess with it - its appearance in
> the MARC records is just too spotty to account for at this pass) and
> instead focus on the Manifestation and the Work.
> 
> Since, as you point out, there's no FRBR relationship between the two,
> we've been using dcterms:hasVersion/isVersionOf to make the link
> directly between W and M.
> 
> It's not the ideal from a FRBR perspective, I realize, but it's
> pragmatic from a "we go to RDF with the data we have, not the data we
> want" point of view.  Once things are established and we can figure
> out what the Expressions are (if ever!), then we can go back and
> associate them, but we at least have the link there now until
> something better comes along.
> 
> Of course, Emmanuelle's suggestion
> (http://rdvocab.info/RDARelationshipsWEMI/workManifested) is even
> better (or, at any rate, more semantically explicit) making me think
> I'll put in a recommendation that we move towards it (and start using
> it for my own projects).
> 
> -Ross.
> >
> > I have often seen pre-FRBR bibliographic data coded as
> "Manifestation"
> > when in fact the data has elements that FRBR would associate with
> > Work, Expression and Manifestation. This brings up more than one
> > question (mainly: what does calling a bibliographic entity a
> > Manifestation mean if there is no "Manifests" relationship? -- In
> > other words, are the FRBR group 1 entities things, relationships, or
> > both?), but on a practical level it seems that we will need to work
> > with bibliographic data that either is not modeled as FRBR entities,
> > or that models a variation on these entities. I'm thinking that some
> > new classes and some new relationships may be needed to accommodate
> > this.
> >
> > Does anyone have ideas about the best way to go about this?
> >
> > kc
> > --
> > Karen Coyle
> > kcoyle@kcoyle.net http://kcoyle.net
> > ph: 1-510-540-7596
> > m: 1-510-435-8234
> > skype: kcoylenet
> >
> >
> >
> > Please consider the environment before printing this email.
> >
> > Find out more about Talis at http://www.talis.com/
> > shared innovation(tm)
> >
> > Any views or personal opinions expressed within this email may not
be
> those
> > of Talis Information Ltd or its employees. The content of this email
> message
> > and any files that may be attached are confidential, and for the
> usage of
> > the intended recipient only. If you are not the intended recipient,
> then
> > please return this message to the sender and delete it. Any use of
> this
> > e-mail by an unauthorised recipient is prohibited.
> >
> > Talis Information Ltd is a member of the Talis Group of companies
and
> is
> > registered in England No 3638278 with its registered office at
> Knights
> > Court, Solihull Parkway, Birmingham Business Park, B37 7YB.
> >
>

Received on Wednesday, 15 September 2010 14:58:06 UTC