- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Wed, 15 Sep 2010 09:13:23 -0700
- 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 UTC