Re: AW: Non- and Partial-FRBR Metadata

All
 
Please ignore last reply - my responses got tangled up with Lars' email; trying
again:

 

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. 
GD: 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. 
GD: 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?). 
GD: 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