RE: Question about MARCXML to Models transformation

Like Ross and Karen, I wish WEMI was modeled on a higher level of
abstraction. (rdfs:Resource and owl:Thing are too abstract.) I suggested
once that "Group1" seems like a good name, but the argument was that
this isn't a subclass relationship. The fact that there are NO
subclasses in FRBR leaves me wondering what the concern is.

 

I would be willing to believe any number of names for this class like
BibliographicEntity or BibliographicResource or BibliographicThing.

 

Jeff

 

From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
Behalf Of Ross Singer
Sent: Tuesday, March 08, 2011 11:45 AM
To: Karen Coyle
Cc: public-lld@w3.org
Subject: Re: Question about MARCXML to Models transformation

 

On Tue, Mar 8, 2011 at 11:01 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:

	 

	And I thank you, Ross, for that and for your clarity in this
discussion.


Hey, whenever you need somebody to come in and punt on the hard
problems, I'm your man. 

	
	I still think it should be possible to model bibliographic data
using the FRBR or RDA attributes but without the division into WEMI for
Group 1 data. (e.g. the RDA generalized attributes) If you have a work
title, well, you have a work title. You don't need a work entity to have
a work title. (I realize fully that I may be wrong about this, but this
is what I *want* to be right.) The predicates and objects should stand
on their own without the separation (and separate identifiers) that WEMI
entities require. Where this falls apart is in the WEMI-to-WEMI
relationships, but I just figure there must be a way to solve that as a
practical problem so that we don't have to shoe-horn everything into
WEMI as separate entities.


I absolutely agree with this.  One of the really nice things about SKOS
(imo) is that it only defines domains and ranges on the properties that
are kos-specific (broader/narrower/inScheme/etc.) and not to the things
that are generally useful even outside the context of SKOS (prefLabel,
altLabel, notes, etc.).   This way we now have a consistent means of
defining a preferred and alternate labels, for any resource, without
entailing that the resource is also a concept.

The same definitely needs to apply to (some) RDA terms.  We should be
able to model resources in BIBO or DC Terms (or whatever), enhance with
the more domain-specific properties RDA brings to the table, without
muddying things up semantically by dragging in FRBR along with it.

As far as the WEMI-to-WEMI relationships (and by this, I think you mean
relationships like adaptations, translations, derivative works, etc.,
right?), you're right, this gets a bit more complicated.  I still think
you can abstract a lot of this away through unconstrained properties:
hasTranslation/isTranslationOf, hasAdaptation/isAdaptationOf, etc. where
the first is, say, a play modeled in RDA or BIBO or DC Terms and the
latter a film, ballet or score modeled in something else (perhaps
oblivious to FRBR).  Let's say "Romeo and Juliet".  We can assume that
something in the WEM chain is adapted here, but we don't have to know
(or care!) what it is, exactly, to say that Tchaikovsky, Berlioz,
Prokofiev, or Zeffirelli's works are related and how.  That is, we
should be able to say that Berlioz's "Romeo and Juliet", modeled in the
Music Ontology is an adaption of (or inspired by, or whatever is most
appropriate) Shakespeare's play, /without/ the W-E-M-I model necessarily
needing to be explicitly invoked.  If and when W-E-M-I and their
relationships for these two endeavors are created, that makes the
relationship even richer, but should not be required simply to link two
citations.

This doesn't diminish the value of FRBR in any way, it just lowers the
overhead.

	
	Hmmm. I wonder what else I can be frustrated about before 8
a.m.? :-)


Oh, we can find things... 

-Ross.