W3C home > Mailing lists > Public > public-lld@w3.org > March 2011

RE: Question about MARCXML to Models transformation

From: Johan Stapel <johan.stapel@bibliotheek.nl>
Date: Tue, 8 Mar 2011 12:58:15 +0100
To: Ross Singer <ross.singer@talis.com>, "Young,Jeff (OR)" <jyoung@oclc.org>
CC: Thomas Baker <tbaker@tbaker.de>, Karen Coyle <kcoyle@kcoyle.net>, "Diane I. Hillmann" <dih1@cornell.edu>, "public-lld@w3.org" <public-lld@w3.org>
Message-ID: <2454384E4DACF84B99980D0DC4CAC0420BC3A13DB4@VOBmailserver.debibliotheken.local>
Dear collegues,

After having signed up to this discussion list and having read this quite impressive discussion about models, I would like to share some thoughts with you.

In our minds, thus theoretically, the bibliographic universe is perfectly designed and implemented. In practice, we have to cope with the rules and regulations and the metadata we have. I think our challenge is to take advantage of new insights and new technologies to mask c.q. cover c.q. overcome c..q. repair the flaws in our bibliographic universe.

In the Netherlands we are working towards establishment of a national discovery service, which should integrate al kinds of information objects from all kinds of (library-archive-museum) sources. Some objects have bibliographic descriptions, some have not. Some objects are public domain and digital, some are not. Nobody told us it would be easy, so it is Luctor et emergo (Dutch for: keep the faith ;-))

While working towards solutions we try to adhere to existing conceptual and bibliographic standards as much as we can (FRBR, MARC, RDA, SKOS, OWL, RDF/XML, (Q)DC, URI, NBN and, very much so, EDM, the new Europeana Data Model).. Still, I think we will have to accept that some things will get lost in the fire of our ambitions. We'll have to accept that our perfect pictures in the end will remain perfect pictures. But we will still be in need of these pictures.

Concluding, it is very important to keep discussions like this one going, just to make sure that our theoretical frameworks will support (and comfort) our practical trials and tribulations, just to create the optimal user experience for discovering quality information.

Kind regards,

Johan Stapel
Senior Consultant Digital Services & Infrastructure
Bibliotheek.nl, The Netherlands
www.stichtingbibliotheek.nl<http://www.stichtingbibliotheek.nl/> (only in Dutch, I'm sorry)



________________________________
Van: public-lld-request@w3.org [mailto:public-lld-request@w3.org] Namens Ross Singer
Verzonden: dinsdag 8 maart 2011 6:25
Aan: Young,Jeff (OR)
CC: Thomas Baker; Karen Coyle; Diane I. Hillmann; public-lld@w3.org
Onderwerp: Re: Question about MARCXML to Models transformation


I would say the major problem I have with these models that set the
expectation of rigidity (e.g. "an Expression must belong to one Work,
a Manifestation must belong to one Expression, etc.") is that implies
the intersection of omniscience, perfection and comprehensiveness from
the outset.

The MADS/RDF's implementation of coordination also runs afoul of this
(by using rdf lists).  The irony being that the subject authorities
can't themselves be modeled this way without external dependencies
(see: http://id.loc.gov/authorities/sh85120834#concept - not only does
id.loc.gov not currently have name resources -- although, obviously
they could -- there is no authorized heading for "Baconian theory").

As Diane pointed out earlier about trying to model MARC records as
"types", it's difficult to model the world and impossible to keep up
with the changes that evolution brings while maintaining integrity
with your backfile.

While RDF's "you can only know what you're looking directly at"
principle seems somewhat existential, it's also built on pragmatism.
I can't help but think there's got to be some middle ground somewhere.
 If we can agree on this sweet spot, somewhere between dogma and
abandon (which, really, isn't as big a gulf as it seems, it's just
that they're fundamentally disjointed) with an acknowledgement of both
will dramatically lower the kinetic energy needed to start getting
data modeled.

Some of these may be fairly simple (changing MADS/RDF's coordination
lists to rdf containers, for example), others, like abstracting away
the strictness of FRBRer (such as implying parts of the WEMI stack,
coupled with explicit parts elsewhere -- similar to what the Open
Library does), while still representing a compatible data model, might
be less trivial but allow for the creation of much more content.

At some point we (and by "we" I don't necessarily mean this group, but
the library community as a whole) need to step back and what exactly
we hope to accomplish and how that might realistically be done.

-Ross.

On Mon, Mar 7, 2011 at 10:12 AM, Young,Jeff (OR) <jyoung@oclc.org> wrote:
>
> I half agree. The guiding light for whether something is a WEM or I
> isn't necessarily the class name or its definition, it's the sensibility
> of properties. WEMI is what it is because the FRBR designers put careful
> thought into the property names separating them: "is realized through",
> "is embodied in", and "is exemplified by".
>
> For example, this statement "makes sense" to me and I guessing everyone
> else (forget FRBR for a second):
>
> "A newspaper editorial is a realization of a opinion."
>
> Is this use of "is a realization of" merely a pun or is its meaning the
> same as that found in the FRBR model? I would argue it's the same, which
> means (through domain/range settings) that an "Opinion" is a Work
> (presumably in the sub-class sense) and "Newspaper Editorial" is an
> "Expression" (also in the subclass sense).
>
> These subclass assignments may not be obvious in isolation, but when
> used in statements involving properties their nature becomes clearer.
>
> Jeff
>
> > -----Original Message-----
> > From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
> > Behalf Of Thomas Baker
> > Sent: Monday, March 07, 2011 9:14 AM
> > To: Karen Coyle
> > Cc: Diane I. Hillmann; public-lld@w3.org
> > Subject: Re: Question about MARCXML to Models transformation
> >
> > On Sun, Mar 06, 2011 at 09:35:22AM -0800, Karen Coyle wrote:
> > > I actually think that we should emphasize the "has a" rather than
> "is
> > > a" aspects of the resources we describe, and let the "has a" allow
> us
> > > to infer any number of "is a" qualities. This is the message that
> Jon
> > > Phipps gave at the tutorial day at DC in Pittsburgh -- that we
> > > describe things by their characteristics, and those characteristics
> > > tell us what the thing *is*.
> >
> > Yes, that sounds right to me.  Emphasize Properties
> > (relationships) over Classes. Verbs over nouns.  Describe
> > things less through giving them a name -- i.e., writing a
> > definition for a class of things to which they belong --
> > and more through enumerating their characteristics.
> >
> > --
> > Tom Baker <tbaker@tbaker.de>
> >
>
>
>
>
> Please consider the environment before printing this email.
>
> Find out more about Talis at http://www.talis.com/
> shared innovation(tm)
>
> Any views or personal opinions expressed within this email may not be those of Talis Information Ltd or its employees. The content of this email message and any files that may be attached are confidential, and for the usage of the intended recipient only. If you are not the intended recipient, then please return this message to the sender and delete it. Any use of this e-mail by an unauthorised recipient is prohibited.
>
> Talis Information Ltd is a member of the Talis Group of companies and is registered in England No 3638278 with its registered office at Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB.
>
> Talis North America is Talis Inc., 11400 Branch Ct., Fredericksburg, VA 22408, United States of America.

________________________________

Geen virus gevonden in dit bericht.
Gecontroleerd door AVG - www.avg.com<http://www.avg.com>
Versie: 10.0.1204 / Virusdatabase: 1497/3489 - datum van uitgifte: 03/07/11
Received on Tuesday, 8 March 2011 17:35:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 March 2011 17:35:36 GMT