RE: Question about MARCXML to Models transformation

> Karen, I agree completely.  Where I think Jeff's argument stumbles a
> bit (and let me be clear, Jeff, I agree with your general point!) is
> that we have enough data to fill out a Manifestation and then half the
> story for an Expression and Work, which may or may not be enough to
> actually identify the "real" Expression or Work.

Inferencing aside, having half the story for an Expression or Work is still enough to justify identifying these individuals. I wouldn't consider them any less "real" than their fully described counterparts. UUIDs are free. This allows downstream agents to assert owl:sameAs with another individual and thus fill in more of the story on both sides. (As mere mortals, we'll never ever have "the full story" on anything.)

>  Since creator and
> language are not tied to Manifestation, the appropriate Expression and
> Work either need to be found, created (contrived, possibly) or simply
> throw away the data until one of the first two conditions are met.

The primary problem is that MARC is the coin of the realm and thus we're forced to play finger puppets for now. If somebody combined AtomPub, FRBR, and started from scratch, it wouldn't be that are to identify and describe new WEMIs.

> 
> Now, in Jeff's defense, he's also absolutely right :).  There's nothing
> in OWL or /anything/ that can prevent you putting a dcterms:language or
> dcterms:creator/contributor property on a frbr:Manifestation.  None of
> these properties have domains, so nothing is being implied about the
> resource by asserting them.  It is solely the FRBR /conceptual model/
> that prohibits this.

I didn't mean to advocate an anything-goes approach. DC elements and terms are useful as super-properties in OWL, but I get disturbed by their direct use in instance data. 

For example, a metadata creator COULD use dcterms:creator assertions on WEM entities as a "simplification" of frbr:createdBy (connecting Work and Group2) frbr:isRealizedBy (connecting Expression and Group2) and frbr:isProducedBy (connecting Manifestation and Group2). These are all "creator" relationships relative to the entity they are being used with. (To be clear, I think this would be poor practice.)

> 
> But one could argue at this point, what's the advantage of calling the
> "Thing" a "Manifestation"?

That's the danger of using properties without domain/range settings. Without these clues the "Thing" is at risk of being/becoming an un-differentiable chimera. Some chimeras are more hideous than others.

>  Where is the value of an isolated E or M
> (I'm going to say that Ws are useful on their own), especially when
> asserting a property that is more appropriate somewhere else in the
> hierarchy doesn't cause all cultural heritage institutions to
> simultaneously vanish in a puff of logic?

I can believe there are enough bibliographic use cases to justify splitting E&M into two entities and distributing their properties. It might be better if these two classes were demoted to subclasses of another class that cultural heritage institutions would also appreciate, but I'm not sure what that class could be called to make everyone happy. This would also require FRBR to adopt subclasses as part of its model, but my sense is that subclassing is a non-starter.

> 
> I guess what I'm asking is, does anything more than implied WEMI
> matter?  What are we prevented from doing if we model our resources
> using an implied FRBR model?

In terms of the 80/20 rule, I assume you're right. It would undermine certain industrial use cases, though, which make this worth discussing.

Jeff

> 
> -Ross.
> On Tue, Mar 8, 2011 at 11:14 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:
> Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:
> 
> 
> I think the nice thing about having FRBR expressed in open-world OWL
> is that we don't need to have omniscience, perfection, or
> comprehensiveness. If we only have information for a Manifestation,
> we can publish it in RDF and know that the constrained elements
> surrounding it can be inferred and reconciled later.
> 
> I hear this said a lot, but I want to understand what it means to only
> have information for a Manifestation. That would mean that you do not
> have an author, because primary creator(s) is a Work property. Also,
> if you have a text, language of text is an expression property. A very
> simple citation, like:
> 
> MELVILLE, H. (1997). Moby Dick. New York, Farrar, Straus, and Giroux
> 
> cannot be coded by using only properties from the manifestation entity.
> 
> The only one of the WEMI entities that can stand alone is W. The rest
> are incomplete for just about any bibliographic use without the ones
> (which may be plural) above it.
> 
> I think we need to develop a set of examples that allow us to see what
> really goes on when you divide up your bibliographic data into WEMI --
> I think it will be much easier to understand that way. I think we have
> some on the DCMI/RDA wiki, and we could develop others.
> 
> kc
> 
> 
> -----Original Message-----
> From: rxs@talisplatform.com [mailto:rxs@talisplatform.com] On Behalf Of
> Ross Singer
> Sent: Tuesday, March 08, 2011 12:25 AM
> To: Young,Jeff (OR)
> Cc: Thomas Baker; Karen Coyle; Diane I. Hillmann; public-lld@w3.org
> Subject: 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.
> 
> 
> 
> 
> 
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
> 
> 
> 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.

Received on Tuesday, 8 March 2011 19:15:22 UTC