Re: Non- and Partial-FRBR Metadata

Hi Gordon, everyone else,

  
> No - but these discussions are very useful for revisiting that thinking!


Indeed! It's interesting to have these discussions if we can gain some insight from FRBR to structure LLD. But if (an implementation of) FRBR ends up imposing unrealistic constraints on a specific case, then it's not worth carrying the burden.

To tell the truth, I find it cumbersome that we have to read and write dozens of mails on this. We're a quite specialized group and I understand we do it--especially if it helps making the FRBR ontology better. But I feel deeply worried when even people who are not really newcomers in the field have to request further expertise (yours!) to validate their intuition.

Also, I fully subscribe with Ross'

> There is
> practically zero RDF/FRBR/RDA data to draw upon presently - I don't
> see the point in stubbornly sticking to the letter of a model that is
> currently unproven, unused and doesn't deal well with our hundreds of
> millions of legacy records.


We shouldn't be shy about FRBR-incomplete data. I'd answer to Karen saying she should just create the linking property she needs for her data, and map her pattern later to FRBR if the FRBR ontology allows her to do so. And if that requires to create an single aggregate of EMI, as she suggest, so be it. Better make one distinction that is useful for the application at hand than three distinctions that make a scenario unfeasible.

Of course if FRBRization is easy, it is clearly worth doing it. But it is difficult, let's not have it stand in the crucial path of these applications that try to make something out the wealth of data *already* available.

Cheers,

Antoine




>
> 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
>  >

Received on Thursday, 16 September 2010 09:49:53 UTC