RE: Non- and Partial-FRBR Metadata

Karen:
 

On 15 September 2010 at 19:13 Karen Coyle <kcoyle@kcoyle.net> wrote:

> Quoting "gordon@gordondunsire.com" <gordon@gordondunsire.com>:
>
>
> >  
> > There are no such restrictions in the inverse direction, so a Work   
> > does not need
> > to have an Expression, etc.
>
>
> Gordon, I am not sure this is true, that a work does not need an 
> expression. The FRBR diagrams show explicit relationships between work 
> and expression and expression and manifestation, but no such 
> relationship between work and manifestation. 
 
Yes, there is no direct relationship between Work and Manifestation.
 

>
> The text (2008) describes work thus:
>
> "We recognize the work through individual realizations or expressions 
> of the work, but the work itself exists only in the commonality of 
> content between and among the various expressions of the work." (p.17, 
> PDF)(http://archive.ifla.org/VII/s13/frbr/frbr_current3.htm#3.2)
>
> So it sounds like a work is a sum of its expressions, and without an 
> expression there is no work. 
 
Yes, this is also correct. In the case of a lost Work, say where only the author
and possible title are known, there are no Expressions, Manifestations or Items
known to exist. Since a Work is an abstract entity, I think it is reasonable to
say that if a Work is known to have existed in the past (when at least one Item,
therefore Manifestation, therefore Expression must have existed), and some
attribute of the Work (e.g. author) is known in the present, then the Work is a
recordable entity. But I don't think it would be necessary, in a practical
sense, to generate Expression and Manifestation URIs as placeholders in these
circumstances. If, subsequently, some copy of that Work (e.g. a Dead Sea scroll)
is discovered, then it would no longer be a lost Work, and a WEM(I) set of URIs
should be generated and appropriate attributes assigned as properties using
those URIs.
 
But, generally, any instance of a Work should be accompanied by at least one
Expression, and at least one Manifestation (and at least one Item). My use of
"need" is ambiguous; I meant it in the practical/practice application of FRBR,
not the model itself, and I should have expressed it better.
 

>
> In addition, the FRBR "attributes" are very strictly bound to the 
> entities, so it appears that you cannot have, for example, a language 
> of text if you do not have an expression entity. 
 
Absolutely. In the strict FRBR ontology, the instance triple this:thing
frbrer:has-language-of-expression "English" leads to the inferred triple
this:thing rdf:type frbrer:Expression.
 
Continuing the thread more generally: I think one of the issues about partial
FRBR metadata is that most, if not all, FRBRized "records" should have at least
one attribute in each corresponding Work, Expression and Manifestation record to
be useful. The Manifestation ought to have a value for the form-of-carrier
attribute, and the Expression a value for the form-of-expression attribute;
these are really basic for utility (identify/select/obtain) in a general/global
environment. Many legacy records will have implicit values for these attributes
(e.g. "volume" and "text"), and I think we tend to overlook the fact that
explicit values can be assigned during FRBRization. Similarly, we really ought
to assign the value "English" to the language attribute in a FRBRized record,
where appropriate, if it is to be used in a multilingual environment. As for
Work, some value ought to be assigned to the attribute title-of-the-work -
derived from a Manifestation title, constructed as a "uniform" title from
multiple Manifestation titles, supplied by the cataloguer, or whatever.
 
FRBR indicates which attributes have high, medium and low value in supporting
user tasks, and suggests which attributes should form a basic national
bibliographic record (although nothing is mandatory, as is also the case with
RDA).
 
There is little utility (and therefore value) in FRBRized records which don't
provide values for "high value" attributes. Even if the record is not intended
to address all four FRBR user tasks, there will be at least one high value
attribute assigned to and instance of each of the Work, Expression and
Manifestation entities, so WEM(I) URIs will be required.
 

>
> Or has some thinking changed since the text was written? 
 
No - but these discussions are very useful for revisiting that thinking!
 
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
>