Re: Non- and Partial-FRBR Metadata

Antoine
 
I'm not sure that "intuition" is the problem here; it seems to be more about the
issues of FRBRizing legacy data. The issues are structure and content, as usual:
legacy structures may not easily map to the FRBR model, and even when they do,
legacy content may appear strange (e.g. a literal value that is the middle of
sentence with no apparent beginning or end).
 
An easier way of producing linked data from legacy records may be to use ISBD.
Many record structures are based to a greater or lesser extent on ISBD, which
resolves one of the issues.
 
The University of Mannheim [1] is exploring the use of some ISBD draft RDF
properties from the Open Metadata Registry. So is the British Library [2].
 
Nobody has to stick to the FRBR model. If it doesn't suit the purpose, why use
it? On the other hand, if the advantages of alignment with user tasks and
reduction of duplication in shared cataloguing are of interest, FRBR/RDA might
be worth the effort.

[1] http://data.bib.uni-mannheim.de/dokumentation_en.html
[2] http://www.bl.uk/bibliographic/datasamples.html
 
Cheers  
Gordon
 

On 16 September 2010 at 11:49 Antoine Isaac <aisaac@few.vu.nl> wrote:

> Hi Gordon, everyone else,
>
>   
> > No - but these discussions are very useful for revisiting that thinking!
>
>
> Indeed! It's interesting to have these discussions if we can gain some insight
> from FRBR to structure LLD. But if (an implementation of) FRBR ends up
> imposing unrealistic constraints on a specific case, then it's not worth
> carrying the burden.
>
> To tell the truth, I find it cumbersome that we have to read and write dozens
> of mails on this. We're a quite specialized group and I understand we do
> it--especially if it helps making the FRBR ontology better. But I feel deeply
> worried when even people who are not really newcomers in the field have to
> request further expertise (yours!) to validate their intuition.
>
> Also, I fully subscribe with Ross'
>
> > 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.
>
>
> We shouldn't be shy about FRBR-incomplete data. I'd answer to Karen saying she
> should just create the linking property she needs for her data, and map her
> pattern later to FRBR if the FRBR ontology allows her to do so. And if that
> requires to create an single aggregate of EMI, as she suggest, so be it.
> Better make one distinction that is useful for the application at hand than
> three distinctions that make a scenario unfeasible.
>
> Of course if FRBRization is easy, it is clearly worth doing it. But it is
> difficult, let's not have it stand in the crucial path of these applications
> that try to make something out the wealth of data *already* available.
>
> Cheers,
>
> Antoine
>
>
>
>
> >
> > Gordon
> >
> >  >
> >  > kc
> >  >
> >  >
> >  > > 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.
> >  > >>
> >  > >>
> >  > >>
> >  >
> >  >
> >  >
> >  > --
> >  > Karen Coyle
> >  > kcoyle@kcoyle.net http://kcoyle.net
> >  > ph: 1-510-540-7596
> >  > m: 1-510-435-8234
> >  > skype: kcoylenet
> >  >
>
>