W3C home > Mailing lists > Public > public-lld@w3.org > September 2010

RE: Non- and Partial-FRBR Metadata

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Wed, 15 Sep 2010 09:13:23 -0700
Message-ID: <20100915091323.fnzfyovc00ocs8o4@kcoyle.net>
To: "Young,Jeff (OR)" <jyoung@oclc.org>
Cc: Ross Singer <ross.singer@talis.com>, public-lld <public-lld@w3.org>
I am leery of creating false Expressions, for a couple of reasons, not  
the least being that they really shouldn't need to exist. Expressions  
are neither one-to-one with Works nor with Manifestations. Empty  
Expressions add nothing to the usefulness of our data. But the bigger  
problem is that the "Manifestation" that we will be declaring in that  
case will be where an application will find the properties that should  
be in the Expression, like language of the resource. So how does an  
application know, when the Expression entity has no language, that  
information about the language is elsewhere? I think that declaring  
things to be something they are not is a formula for confusion.

I would rather be able to say what actually *is*. I think we need some  
new entities that reflect current bibliographic data, not the FRBR  
future. I often see "Manifestation" used for MARC-like bibliographic  
data, which is W + E + M. The intention, of course, is to say that  
this data is manifestation-level on up. (I tried to define this better  
in a rather disorganized blog post [1].)

Since so many of us have this need, it seems to be mainly a matter of  
determining who and where this bibliographic entity (or entities) will  
be defined.

kc

Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:

> 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
Received on Wednesday, 15 September 2010 16:13:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 15 September 2010 16:13:59 GMT