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

Re: Question about MARCXML to Models transformation

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Sun, 06 Mar 2011 09:35:22 -0800
Message-ID: <20110306093522.22405o2xio349ryy@kcoyle.net>
To: "Diane I. Hillmann" <dih1@cornell.edu>
Cc: "public-lld@w3.org" <public-lld@w3.org>
Riffing off of Diane's post a bit, let's say that you decide that  
there are "works" and there are "cartographic works".

  - has creator
  - has subject
  - has work title

  - Cartographic work
    - has longitude/latitude/azimuth/scale, etc.

However, you will have works that are mixed -- some text, some images,  
some maps. You may want to include the full cartographic details, but  
not call it primarily a cartographic work. Yet you have defined  
longitude/etc. as properties of cartographic works only. You're now  

It's very hard to come up with neat divisions of works. A movie of  
Swan Lake has film, music and choreography aspects that are all very  
import. A film archive would see it as a film, a dance archive might  
see it as a dance performance.

As soon as you put something in a pigeonhole you are locking it into a  
particular point of view. The lovely thing about DC terms is their  
(oftentimes frustrating) neutrality in terms of resource type.

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*. It seems to me that if we put our  
resources into detailed classes we greatly limit the amount of  
inferencing that we can do.


Quoting "Diane I. Hillmann" <dih1@cornell.edu>:

>  All,
> I had a bit of a flashback reading this section of Jeff's post:
> On 3/6/11 4:15 AM, Young,Jeff (OR) wrote:
>> 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.
> What I see happening here is a repetition of the development  
> trajectory of MARC, where the attempt to separate description by the  
> 'format' of the resource eventually developed into 8 or so separate  
> element sets (for lack of a better word).  This turned out not to be  
> particularly workable because so many multimedia resources started  
> to come down the pike that weren't easily described under this  
> separate regime, where one had to determine what the 'primary'  
> format was before beginning to describe.  During the 1980s, MARBI  
> spent many hours re-integrating MARC into a single set of  
> descriptive elements that could be applied across a wide variety of  
> resources. I would hate to see us go around that particular track  
> again.
> I think, too, that there's something a bit presumptuous about this  
> particular group of folks (including me) determining for the  
> specialists what it is they need to use to describe their stuff.   
> This is one reason I really think that the notion of application  
> profiles is so attractive, because it puts the tools for developing  
> a model and making decisions on the selection of properties into the  
> hands of the people who really know what they're talking about.
> Diane

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 17:35:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:27:43 UTC