RE: Question about MARCXML to Models transformation

Let's flip "splits" on its head and imagine "merges" instead
(owl:sameAs). Imagine that I create stand-alone W-E-M triads for every
single Manifestation and then I go back and try to "de-dup" them
class-by-class. Which FRBR properties are useful for this purpose, and
which ones are along for the ride?

If that doesn't help, I can try again.

> -----Original Message-----
> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
> Sent: Sunday, March 06, 2011 6:21 PM
> To: Young,Jeff (OR)
> Cc: public-lld@w3.org
> Subject: RE: Question about MARCXML to Models transformation
> 
> Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:
> 
> >
> > I'm still trying to make sense of WEMI, but treating "has publisher"
> and
> > "place of publication" as literals implies they have no bearing on
> WEMI
> > splits. If these properties aren't factors, it makes me wonder which
> if
> > any are. It never occurred to me that WEMI entity production
wouldn't
> > leave traces in the properties. Maybe I've been looking under the
> wrong
> > rocks?
> 
> Jeff, you completely lost me on this, so I'm going to begin by asking
> what you mean by "splits" -- then I probably will have other
> questions. :-)
> 
> kc
> 
> 
> >
> > Jeff
> >
> >> -----Original Message-----
> >> From: Tillett, Barbara [mailto:btil@loc.gov]
> >> Sent: Sunday, March 06, 2011 3:44 PM
> >> To: Young,Jeff (OR); Karen Coyle; Thomas Baker
> >> Cc: gordon@gordondunsire.com; public-lld@w3.org
> >> Subject: RE: Question about MARCXML to Models transformation
> >>
> >> I basically agree, but want to point out that FRBR's WEMI are not
> >> strictly hierarchical but rather a network graph (don't forget
about
> >> the many to many relationships for the WEMI - it's not just one to
> one
> >> or one to many or many to one - there are also many to many).
> >>
> >> Also "relational database" does not mean it has relationships...it
> >> means it's based on relational algebra with joins, unions,
> >> intersections, etc., of tables (sets of data).  I'm really looking
> >> forward to breaking away from relational database models to get to
> >> something that handles the complex graph structures of the
> >> bibliographic universe better.  It's probably because I'm rather
> fond
> >> of topological spaces and non-Euclidean geometries and see a better
> > fit
> >> in that realm, but computer science isn't there yet.  I think the
> >> Semantic Web has the potential to free us from the relational
model,
> >> while improving connections and links of relationships...but I
still
> >> see current iterations as not really "there" yet.  Gordon's work is
> a
> >> brilliant step to demonstrating and documenting the logic relations
> >> (transitive, equivalent, etc.), cardinalities, etc.  It really
helps
> > us
> >> "see" the model and note where adjustments would make it even
> better.
> >>
> >> FRBR has declared certain attributes for the entities, and I
> > completely
> >> agree some of those could better evolve into relationships (like
> >> corporate bodies with a relationship/role of "is publisher" to a
> >> particular manifestation rather than leaving them as attributes of
a
> >> manifestation) - we started to do that with RDA, but stopped short
> as
> >> being too drastic a change from FRBR for this first round...but I
am
> >> sure it will be revisited once we have more registries like VIAF
and
> >> the RDA registries that make linking and declaration of
> relationships
> >> easier and more stable, and schemas and systems that can actually
do
> >> something with such structures. - Barbara
> >> ________________________________________
> >> From: public-lld-request@w3.org [public-lld-request@w3.org] On
> Behalf
> >> Of Young,Jeff (OR) [jyoung@oclc.org]
> >> Sent: Sunday, March 06, 2011 4:15 AM
> >> To: Karen Coyle; Thomas Baker
> >> Cc: gordon@gordondunsire.com; public-lld@w3.org
> >> Subject: RE: Question about MARCXML to Models transformation
> >>
> >> I think Karen brings some nebulous issues into focus. Sorry if my
> >> thoughts are cryptic. I can try to clarify them if needed.
> >>
> >> > It's rather clear that FRBR was not designed with the open world
> >> model
> >> > in mind -- in fact, it was designed around a late 90's concept of
> >> > relational databases.
> >>
> >> The Semantic Web is also "relational", so that aspect doesn't
bother
> >> me.
> >> I agree that "relational databases" impose closed world
assumptions,
> >> but
> >> I'm not sure this limitation affects how designers go about their
> >> modeling. For example, reusable OWL can be rationalized from legacy
> >> relational databases using D2RQ:
> >>
> >> http://www4.wiwiss.fu-berlin.de/bizer/d2rq/spec/
> >>
> >> > It is very top-down in that XML-ish way and most
> >> > commonly it is assumed that each of the FRBR entities will be a
> >> > record.
> >>
> >> FRBR in general is relational, but the WEMI classes specifically
are
> >> unquestionably hierarchical. I would agree that XML Schemas warps
> our
> >> thinking, but WEMI is starting to make sense to me as a hierarchy.
> My
> >> complaint now is the lack of meaningful WEMI subclasses that could
> > make
> >> the model much easier to understand and deal with.
> >>
> >> > I say that latter because of the fact that the WEMI entities,
> >> > while having inter-dependencies, also have specific relationships
> to
> >> > other WEMI entities (as well as to the group 2 and 3 entities).
So
> > an
> >> > expression will have a relationship to a work and to one or more
> >> > manifestations -- that's what I think of as a *structural*
> >> > relationship --
> >>
> >> I agree with this interpretation and provide these RDF examples for
> >> illustration.
> >> (Beware: my "frbr" namespace elements are ad hoc.)
> >>
> >> <expression-1> a frbr:Expression ;
> >>         frbr:isARealizationOf <work-1> ;
> >>         frbr:isEmbodiedIn <manifestation-1> ;
> >>         frbr:isEmbodiedIn <manifestation-2> .
> >> <work-1> a frbr:Work .
> >> <manifestation-1> a frbr:Manifestation .
> >> <manifestation-2> a frbr:Manifestation .
> >>
> >> > but it can also have bibliographic relationships to
> >> > other expressions (like: one expression is the translation of
> > another
> >> > expression, or is an updated edition).
> >>
> >> Here's what the additional triples would look like:
> >>
> >> <expression-1>
> >>         frbr:hasATranslation <expression-2> ;
> >>         frbr:hasARevision <expression-3> .
> >> <expression-2> a frbr:Expression .
> >> <expression-3> a frbr:Expression .
> >>
> >> > The fact is that it will be very hard to have an expression
> without
> > a
> >> > work because of the way the properties are spread across the
Group
> 1
> >> > entities: an expression does not have relationship to a primary
> >> > creator (e.g. author), only a work does. Ditto subjects: only
Work
> >> > entities have the "has subject" property that links to topical
> >> > entities.
> >>
> >> I'm willing to go so far as believing it is *impossible* to have an
> >> Expression without a Work because *all* conceivable Expressions
have
> >> creator and subject relationships in theory: even the fictional
> ones.
> > I
> >> think we need to beware that FRBR doesn't strive to be a metadata
> >> exchange format, it strives to be a model of common sense reality
> > (more
> >> or less).
> >>
> >> > A Manifestation doesn't have a language of text; that
> >> > belongs to the Expression. The necessary elements to describe a
> >> > resource
> >>
> >> Riddle: When is a resource not a resource?
> >> Answer: When the modeler(s) declare it to be a property or set of
> >> properties instead.
> >>
> >> Fortunately, no modeler in history ever had the last word. :-)
> >>
> >> > are spread across the 3 (WEM) group 1 entities, making it
> >> > very difficult to treat them separately. To give you an idea of
> what
> >> > each entity "means", here are some key attributes for each:
> >> >
> >> > Work
> >> >   - work title
> >> >   - key for a musical work
> >> >   - coordinates for a cartographic work
> >> >   - with relationships to
> >> >      -- creator of the work
> >> >      -- topics of the work (subject headings and classifications)
> >>
> >> The terms "musical work", "cartographic work", and various other
> >> rationalized "foo work" qualifiers imply subclasses of FRBR Work. I
> >> think it's worth attempting.
> >>
> >> >
> >> > Expression
> >> >   - language of the expression (if text)
> >> >   - form of the expression (text, sound, image)
> >>
> >> Likewise, "text expression", "sound expression", "image
expression",
> >> and
> >> other qualifications all imply subclasses of FRBR Expression.
> >>
> >> > Manifestation
> >> >   - title of the manifestation (may be different to the work
> title)
> >> >   - edition
> >> >   - publisher, date of publication
> >> >   - physical format (size, units, other measurements)
> >> >   - ISBN, ISSN, etc.
> >>
> >> My feeling is that some of these "attributes"
(owl:DatatypeProperty)
> >> SHOULD be modeled as relationships/associations instead
> >> (owl:ObjectProperty). For example, I think "publishers" should be
> >> modeled as a frbr:CorporateBody (or a subclass thereof) and "place
> of
> >> publication" should be modeled as frbr:Place. Limiting the
> individuals
> >> in the CorporateBody and Place classes to known subjects of a Work
> >> doesn't make sense in an open world model. Most real world objects
> can
> >> be dumbed-down to literals when necessary.
> >>
> >> >
> >> > There are many more attributes, but these are the common ones and
> > the
> >> > ones that I think may help people understand the issue. The data
> >> > record that libraries create today contains data elements from
all
> > of
> >> > these entities, mixed together and usually not clearly identified
> as
> >> W
> >> > or E or M. To create library data under FRBR it will be necessary
> to
> >> > ALWAYS have Work+Expression+Manifestation entities. (I'm skipping
> >> Item
> >> > in the interest of brevity, but we should assume that it is part
> of
> >> > the picture.)
> >>
> >> For better or worse it's not that simple. As Tom Baker pointed out
> in
> >> another thread, ontologies aren't exchange formats, they are models
> in
> >> which some entities can be inferred.
> >>
> >> >
> >> > Now, it would be great to investigate the inferences that one can
> >> make
> >> > with FRBR. For example, if you say:
> >> >
> >> > resourceA / frbrer:hasSubject /
> >> > http://id.loc.gov/authorities/sh85148177
> >> >
> >> > then the inference is that resourceA is a Work. (I believe the
way
> > to
> >> > say this is that "hasSubject" has the domain "Work". Right,
> Gordon?)
> >>
> >> FRBRer coins separate "has as subject" properties for each range
> > class,
> >> but as you would expect the domain is always Work.
> >>
> >> > You cannot then say:
> >> >
> >> > resourceA / frbrer:hasPublisher / "Random House"
> >> >
> >> > because *that* statement would mean that resourceA is a
> >> Manifestation,
> >> > and Manifestation and Work are disjoint.
> >>
> >> The FRBRer OWL doesn't currently declare Work and Expression to be
> >> owl:disjointWith one another, but I think that was Gordon's plan.
> >> Here's
> >> some support for your understanding:
> >> http://www.w3.org/TR/owl2-primer/#Class_Disjointness.
> >>
> >> > So in a sense you are forced
> >> > (whether OWL forces you or not is another question), but the FRBR
> >> > logic forces you to create a new entity for the Manifestation
> >> > *portion* of your description. In addition, to connect the
> >> > Manifestation to the Work (since you need the creator and
subjects
> > to
> >> > complete your description), you may need to create an entity for
> the
> >> > Expression. (RDA allows Manifestations to "Manifest" Works, but I
> >> > think FRBR in its present state still requires M -> E -> W.)
> >>
> >> I believe it's possible to create an inferred shortcut like this in
> >> OWL,
> >> but it's just a convenience property.
> >>
> >> >
> >> > This is, of course, unless I have totally missed something in the
> >> > nature of FRBR, and if so I would love to hear that my worst
fears
> >> > about it do not come to bear.
> >>
> >> I think you've created a useful and accurate summary. :-)
> >>
> >> Jeff
> >>
> >> >
> >> > kc
> >> >
> >> > >
> >> > > It relates to Dan's point that schema designers in the new
> >> > > idiom are not actually issuing "shipping orders" for data
> >> > > integrity in the imperative style to which they are accustomed
> >> > > -- even if, as I suspect, they may sometimes _believe_ that
> >> > > this is is the effect of declarations such as the above.
> >> > >
> >> > > As Jeff has pointed out, one might conceivably use the OWL to
> >> > > construct syntactic validators to impose such data integrity,
> >> > > but these are necessarily over and above whatever the OWL
> >> > > itself actually says.
> >> > >
> >> > > Tom
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Karen Coyle
> >> > kcoyle@kcoyle.net http://kcoyle.net
> >> > ph: 1-510-540-7596
> >> > m: 1-510-435-8234
> >> > skype: kcoylenet
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> >
> >
> 
> 
> 
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>

Received on Sunday, 6 March 2011 23:49:48 UTC