RE: Question about MARCXML to Models transformation

Looking closer, my feeling is that the terms at the top of column 1 are
subclasses of Expression:

:Abridgment
	rdfs:subClassOf :Expression .
:Revision
	rdfs:subClassOf :Expression .
:Translation
	rdfs:subClassOf :Expression .
:Arrangment
	rdfs:subClassOf :Expression .

The Expression-to-Expression relationship properties listed below would
presumably have these domain/range settings:

:hasAnAbridgment
	rdfs:domain :Expression ;
	rdfs:range :Abridgment .
:hasARevision
	rdfs:domain :Expression ;
	rdfs:range :Revision .
:hasATranslation
	rdfs:domain :Expression ;
	rdfs:range :Translation .
:hasAnArrangement
	rdfs:domain :Expression ;
	rdfs:range :Arrangement .

:isAnAbridgmentOf
	owl:inverseOf :hasAnAbridgment .
:isARevisionOf
	owl:inverseOf :hasARevision .
:isATranslationOf
	owl:inverseOf :hasATranslation .
:isAnArrangementOf
	owl:inverseOf :hasAnArrangment.

You COULD capture the information in table 5.3 in property fields of the
Expression, but then we're back to our brains falling out.

The terms in column 3 appear be subclasses of those, but probably don't
justify being pulled out separately.

Jeff

> -----Original Message-----
> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
> Sent: Tuesday, March 08, 2011 5:30 PM
> To: Young,Jeff (OR)
> Cc: Ross Singer; Richard Light; public-lld@w3.org
> Subject: RE: Question about MARCXML to Models transformation
> 
> Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:
> 
> 
> > I don't know the answer, but maybe we can pull together a few clues.
> In
> > the FRBR Final Report, look at Table 5.3 Expression-to-Expression
> > Relationships. From that, it seems pretty certain that "book" +
> language
> > are factors but only secondarily. Note the column named "Autonomous
> > Expressions".
> >
> > http://archive.ifla.org/VII/s13/frbr/frbr_current5.htm
> >
> >
> > What if we thought of these as subclasses of Expression that we
could
> > then use to help draw the line?
> 
> I don't see them as subclasses of Expression but as predicates linking
> two expressions. An expression can't be an Abridgment unless it is the
> Abridgement of another expression, thus it is a relationship between
> expressions, not a sub-class. The Abridgement is an expression in its
> own right.
> 
> kc
> 
> >
> >
> >
> > Jeff
> >
> >
> >
> > From: rxs@talisplatform.com [mailto:rxs@talisplatform.com] On Behalf
> Of
> > Ross Singer
> > Sent: Tuesday, March 08, 2011 4:46 PM
> > To: Richard Light
> > Cc: Young,Jeff (OR); Karen Coyle; public-lld@w3.org
> > Subject: Re: Question about MARCXML to Models transformation
> >
> >
> >
> > One thing I want to clear up, I'm not disputing creating resources
> > without all of the information available up front.  What I am asking
> is,
> > how much is needed to accurately create an Expression?
> >
> > If what we have is a record type (BKS) and language of publication
> (en),
> > is this enough information to accurately create an Expression and
> start
> > associating Manifestations to it?  I'll table for the moment my
> > questions about whether or not this is useful, focusing instead what
> > exactly is needed to create an (accurate) Expression from legacy
MARC
> > and what else we might expect to commonly see in a typical MARC
> record
> > to help draw upon.
> >
> > The LC FRBR Display Tool
> > (http://www.loc.gov/marc/marc-functional-analysis/tool.html#table)
> only
> > mentions record type and publication language, but surely this isn't
> > enough, right?  This: http://lccn.loc.gov/74194328 isn't describing
> the
> > same expression as this: http://lccn.loc.gov/97813632, correct?
> >
> > -Ross.
> >
> > On Tue, Mar 8, 2011 at 4:06 PM, Richard Light
> > <richard@light.demon.co.uk> wrote:
> >
> > In message
> >
<52E301F960B30049ADEFBCCF1CCAEF590BBB715A@OAEXCH4SERVER.oa.oclc.org>,
> > "Young,Jeff (OR)" <jyoung@oclc.org> writes
> >
> >
> >
> >
> > 	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.)
> >
> >
> >
> > I've been meaning to contribute to this thread for a few days now
...
> >
> > I strongly agree with the thought that an entity can be given a URL,
> and
> > thereby you can finesse the need for the "concept is the sum of its
> > properties" approach. We will have many similar cases in the museum
> > world, where information about an entity of interest (person, place,
> > event, ...) will be incomplete, or uncertain, or both. This
shouldn't
> > stop us from asserting what we _do_ know (or believe).
> >
> > As a matter of interest, where does FRBRoo
> > (http://www.cidoc-crm.org/frbr_inro.html) come into this discussion?
> >
> > Richard
> > --
> > Richard Light
> >
> >
> >
> > 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
>

Received on Tuesday, 8 March 2011 23:02:40 UTC