Re: AW: Non- and Partial-FRBR Metadata

Lars and others:
 
On 14 September 2010 at 10:55 "Svensson, Lars" <l.svensson@d-nb.de> wrote:


> Karen:
> >
> > Jon Phipps:
> >
> > > On Mon, Sep 13, 2010 at 9:28 PM, Jon Phipps <jonp@jesandco.org>
> > wrote:
> > >> Karen,
> > >>
> > >> This might be a bit radical, but what would happen to your model
> if,
> > >> rather than thinking of the FRBR entities as 'entities', you
> thought
> > of
> > >> them as simply classifications/groupings of the properties
> > describing a
> > >> single bibliographic resource -- an item
> >
> >
> > > Quoting Dan Brickley <danbri@danbri.org>
> >
> > > I've been tempted by this kind of design too.
> >
> > > I tend to see FRBR as a source of functional requirements, rather
> > than
> > > of a direct OO class model to use in RDF.
>This is a useful way of thinking about the utility of FRBR with respect to
>end-users. FRBR also has significant utility for cataloguers: the WEM(I)
>packages ("records") can reduce duplication in catalogues, as a new
>Manifestation can be linked to an existing Expression (which is already linked
>to the Work) rather than be incorporated into a new monolithic
>Manifestation/Expression/Work record which contains duplicate Expression/Work
>metadata statements. This distributed architecture of linked but separate W, E,
>M and I records is the equivalent of RDA database scenario 1, for which RDA is
>optimised.

> Yes, and particulary in RDF (open world) we don't _have_ to have
> manifestation-to-expression relation.I think you do, if you are to conform to
> the FRBR model (as OWL ontology). There is not much utility in a pure
> Manifestation record (no "author", no subject, no form of content, etc.).
> (btw, note that RDA database scenario 1 does allow for a manifestation-to-work
> relation, which does not seem to conform to FRBR.) However, the unbounded (no
> domain, no range) versions of the FRBR attributes (as RDF properties) which we
> hope to publish real soon now will side-step the need for WEMI class
> individuals.

>
> > Me, three, I have thought about it this way, but I can't figure out
> > how to make it work on a real bibliographic system.
> > Essentially, this
> > is what we have today with MARC21 records (and ISBD records, I
> > believe). All of the data describing either an item or a manifestation
> > is created as a single set. Then say that you want to present a view
> > to your users that shows them works, and all of the expressions of
> > those works.
>
> I agree in general, too. Would a possible solution  for the expression
> level be to create an ad hoc-expression for each manifestation, just in
> order to have one? That way you cannot build a good user interface _at
> once_ but eventually you could (intellectually) merge the "records"
> describing the same expression. That would definitely be a human task
> (crowdsourcing?).I think this would be a useful approach. It can work
> bottom-up and top-down. Bottom-up is the process of cataloguing a new
> Manifestation (Item in hand - the Item attributes can be ignored for most
> purposes). Say the cataloguing context requires instance triples for the
> manifestation title and the date of publication, and the environment is
> distributed, discrete WEMI records:
 
this:manifestation123 frbrer:has-title-of-the-manifestation "The title in hand".
this:manifestation123 frbrer:has-date-of-publication-or-distribution "2010".
 
The URI represented by this:manifestation123 is auto-generated by the
cataloguing system as a running number (this is what happens in most current
systems when a new bibliographic record is created).
 
If the cataloguer has already identified an existing expression (say
that:expression456) for the manifestation, then it is trivial to generate:
 
this:manifestation123 frbrer:is-embodiment-of that:expression456.
(that:expression456 frbrer:is-realization-of elsewhere:work789. will already
exist, somewhere)
 
If there is no existing Expression, then the system could auto-generate:
 
this:manifestation123 frbrer:is-embodiment-of this:expression123. (that is,
using the same running number)
 
and, if necessary: this:expression123 frbrer:is-realization-of this:work123.
 
Top-down can be used for legacy records:
 
If the legacy record has URI, say, this:bibrecord123, then auto-generate:
 
this:work123 frbrer:is-realized-through this:expression123.
this:expression123 frbrer:is-embodied-in this:manifestation123.
(if necessary) this:manifestation123 frbrer:is-exemplified-by this:item123.
 
Whichever way, we end up with URIs for the WEM(I) necessary to display a full
bibliographic record to the end-user. Object values for attribute properties can
then be assigned as required. It would not be a problem if no attributes are
assigned; the URIs can still be used to create the relationships mentioned by
Karen earlier in this thread:
 
this:work123 frbrer:is-an-adaption-of-(work-from-work) that:work456.
this:expression123 frbrer:is-a-translation-(expression)-of that:expression789.
 
An obvious issue with the top-down approach is proliferation of URIs for the
same Work and Expression (and Manifestation if Item is non-trivial). This just
adds to the proliferation of WEMI URIs from duplicate legacy bibliogaphic
records.
 
Crowd-sourcing is not required to generate the WEMI URIs - but could be
useful/essential to identify URIs for the same thing, and make them equivalent.

>
> All the best,
>
> Lars
> 
>
>
 
Cheers
 
Gordon