Subject: [CODE4LIB] MARC/MODS and Automating Migration to Linked-Data Standards

From: Chris Frymann <[email-masked]>
Date: Tue, 11 Aug 2009 15:23:46 -0700

Hi All,

I just recently subscribed to this list and have been watching for a
few days, expecting that I would do so for a while longer before
jumping in.  However I couldn't help but take special note of recent
posts with mention of MARCXML and MODS and discussion, at least
indirectly, of how those formats "play" with "linked-data" standards.
Since that is an area close to where I have been working lately, I
thought I'd offer a comment and also ask for some friendly feedback.

First my comment:

Here at UC San Diego Libraries, where I work, we have been generating
RDF data for a couple of years now, and more recently working with
triplestores and SPARQL.  We also, no surprise, have lots of MARC
data, and have developed some local strategies for migrating MARC to
MODS to RDF with a very local conversion scheme.  In order to learn
more about OWL and ontologies, and possibly to create a more generally
useful/acceptable expression of our MARC/MODS data as RDF I launched
into a project to convert the

	Library of Congress MODS XML schema
		http://www.loc.gov/standards/mods/v3/mods-3-3.xsd

into a formal OWL ontology.  At one level this can be approached as a
rather mechanical process, on the other hand, I made some adjustments
to MODS predicate naming, with the intent of providing more meaning to
individual MODS-based RDF triples.  I won't try to explain that
further here, but if anyone has additional interest, more information
is available on my effort to produce and provide validity for a MODS
ontology on my blog, starting at a post entitled:

    Another Step Toward Lifting Library Metadata into the Cloud
	http://www.chrisfrymann.com/2009/07/22/mods-ontology-2/

and in following posts with comments and replies from and to Bruce
D'Arcus, especially regarding Bibliographic Ontology.

That's the end of my comment.  So now my question(s), or request for feedback.

Can we identify, some generally agreed on automateable strategy for
converting MARC/MODS to RDF (without having to limit to Dublin Core).
Or, in case I'm missing something, what work has already been done in
that direction?

As a corollary, I would appreciate thoughts any of you have on the
value of continuing the effort to develop a MODS ontology?  I attended
the Semantic Technology Conference recently where I was a speaker in
a:

	Session on Digital Libraries
		http://www.semantic-conference.com/session/1990/

and received quite a bit of interest at the conference, though I met
very few from the library community there.

I had hoped to provide something that could:

	* Potentially be more universal than our current local approach to
expressing MODS in RDF

	* Assign class and predicate names in an attempt to make dealing with
blank noes and SPARQL queries simpler and more natural, given the (to
me) somewhat complicated structure of MODS.

	* Provide a formal OWL base for assigning owl:sameAs relationships,
alternate rdfs:label values, etc.

However, I am very mindful of (and sympathetic to) thoughts such as
the following from Ed Summers, regarding:

"...taking a more organic approach to vocabulary selection, mixing and
matching vocabulary elements rather than imposing a particular
metadata world-view"

That would make sense to me if there was a generally accepted way to
automate the conversion.

Sorry for the somewhat long introductory comment and thanks in advance
for any helpful thoughts or suggestions.

Chris Frymann
Digital Library Architect
University of California San Diego Libraries

Email: [email-masked]
Blog: http://chrisfrymann.com

---

From: Ross Singer <[email-masked]>
Date: Wed, 12 Aug 2009 00:12:37 -0400

Chris, I've been following your blog posts for the last couple weeks
or so and have been trying to come up with a coherent and useful
reply, but I guess I'll take a stab here.

I'll kick things off with saying that I'm skeptical of what advantage
or utility a MODS ontology would bring (for many of the same reasons I
have reservations regarding the RDA vocabulary/ies) - to me it feels
like like it's just dressing up the same old library documents as LOD
resources without really investing the time and energy to model them
in the most appropriate way.  That being said, I understand that you
have this data modeled this way already (so you have an incentive) and
once I've seen that, maybe I will see the light and can be convinced
that this is not a bad way to go.

Also, you're probably aware of this, but the Simile project had an
RDFizer for MODS:  http://simile.mit.edu/wiki/MARC/MODS_RDFizer

A few of the things that have come to me are:

1) What kind of things would these resources be?
<http://example.org/ex/1> <rdf:type> <http://purl.org/MODS/Record> ?
Or would MODS have subclasses?  If so, what?  These:
http://www.loc.gov/standards/mods/mods-outline.html#typeOfResource ?
Would you actually be able to figure out anything about the resource
merely from identifying its type?  Does MODS define a formal data
model (a la http://lackoftalent.org/michael/blog/2009/08/10/is-marc-a-data-model/)?

2) MODS documents are generally containers that carry several discrete
resources:  bibliographic data regarding the primary resource (let's
say, a "book"); authors; publishers; subjects; record metadata
(source, language of the metadata, creation date, etc.) and so on.
Would a MODS ontology try to model the entirety of the graph expressed
by a document?  If so, can the components stand independently?  Can I
have just a MODS:Name?  Would I *want* just a MODS:Name (or
MODS:Subject or MODS:RecordInfo, etc.)?

3) What, specifically, is missing from DCTerms that would make a MODS
ontology needed?  What, specifically, is missing from Bibliontology or
MusicOntology or FOAF or SKOS, etc. that justifies a new and, in many
places, overlapping vocabulary?  Would time be better spent trying to
improve the existing vocabularies?

4) What is compelling about MODS that makes it desirable to serialize
as RDF?  Is it the structure?  The relationships?  Would it be
possible that a desirable outcome of an rdf-ized MODS be merely a
small set of properties (for example) that glues together a set of
external vocabularies into something that would work as an acceptable
surrogate to a MODS XML document?

My interpretation of the crux of your argument is "our stuff is either
MODS or can easily be transformed to MODS".  It just seems to me that
once you've really atomized the record data into its component parts
you will have something that will be enough of a departure from MODS
that it will be difficult to see the resemblance.

So I'll kick things off with that and see where that leads.

Thanks,
-Ross.

---

From: Grace Agnew <[email-masked]>
Date: Wed, 12 Aug 2009 07:09:30 -0400

I'll take a stab at this, also.  I was very intrigued by Chris' work
modelling MODS as an ontology.  AACR2 and MODS emerged from a business
model of standardizing descriptive practice in a way that could be readily
applied and thus shared across disparate organizations.  There are some
native relationships, particularly in topical areas, but not that many.

The real value of modelling MODS into an ontology, IMO, is the ability to
build better relationships with other metadata schemas and data models. 
Metadata mapping is still in its infancy and still relies to a large
extent on a "hard mapping" of one data element to another, without mapping
the inherent data model behind each schema, with the elements and their
relationships to one another.  MODS has fairly complex subject elements
with hierarchical relationships among temporal and topical, for example,
that don't map well to less hierarchical schema, for example.  Converting
MODS to an ontology allows the exposure of relationships and thus comes
closer at least to a model-to-model mapping.  ontologyX uses an ontology
behind the <indecs> schema to map the metadata of DOI participants.  I
don't know how well this works, since much of the work is proprietary and
closed.  Diane Hillman has done some interesting work with the NSDL
Metadata Registries project in this area, also.

Another dicey issue in metadata mapping is mapping the values within the
elements, which are often prescribed vocabularies that require use of the
controlled vocabulary to conform to the schema.  If we can get element
mapping truly working, it should be fairly easy to develop text mining
algorithms that compare vocabulary values against dictionaries to identify
and relate equivalent, broader and narrower terms.  Not trivial, but
fairly easy.

Grace Agnew
Rutgers University Libraries

> model (a la
> http://lackoftalent.org/michael/blog/2009/08/10/is-marc-a-data-model/)?
>

---

From: Karen Coyle <[email-masked]>
Date: Wed, 12 Aug 2009 07:48:44 -0700

> improve the existing vocabularies?
MARC: 182 fields, 1711 subfields, 2401 fixed field values
DC: 59 properties

Look at the sample records in MARCXML and DC at 
http://www.loc.gov/standards/marcxml and you will see how lossy it is. 
Now, you could argue that no one needs all of the detail in MARC, and 
I'm sure it could be reduced down to something more rational, plus there 
is redundancy in it, but for pity's sake, DC doesn't have a way to 
indicate the EDITION of a work. FOAF has both *surname* and *family 
name* and says: "These are not current stable or consistent..." No sh*t. 
And try to clearly code a name like "Pope John Paul II" in FOAF. Oh, and 
death dates. No death dates in FOAF because you wouldn't have DEAD 
FRIENDS. But authors die.

Best if I stop there.
kc

-- 
-----------------------------------
Karen Coyle / Digital Library Consultant
[email-masked] http://www.kcoyle.net
ph.: 510-540-7596   skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------

---

From: Ross Singer <[email-masked]>
Date: Wed, 12 Aug 2009 12:34:46 -0400

> MARC: 182 fields, 1711 subfields, 2401 fixed field values

I see where you're going with this, but I'm not sure it's a fair
critique.  It's sort of on par with saying that a Dodge Grand Caravan
is a more sophisticated vehicle than a Mini Cooper because it has more
horsepower, 3 times as many cup holders and vastly more cubic footage
in the interior.  A Caravan /may/ be a more sophisticated vehicle, but
I'm not sure a quick run over the specs can necessarily reveal that.

One of the problems here is that it doesn't begin to address the DCAM
-- these are 59 properties that can be reused among 22 classes, giving
them different semantic meaning.
> http://www.loc.gov/standards/marcxml and you will see how lossy it is.

Now I think you know you're being a little misleading here.  For one
thing, it's using DC Elements and it's not doing /anything/ vaguely
RDF-related.  Unfortunately, I think it's examples like this that have
led libraries to write DC off as next to worthless (and
understandably!).

Dublin Core is toothless and practically worthless in XML form.  It is
considerably more powerful when used in RDF, however, because they
play to their mutual strengths, namely that in RDF, you generally
don't use a schema in isolation.

>Now,
> you could argue that no one needs all of the detail in MARC, and I'm sure it
> could be reduced down to something more rational, plus there is redundancy
> in it, but for pity's sake, DC doesn't have a way to indicate the EDITION of
> a work.

This is true.  But this is also why I'm asking what is missing in
DCTerms that would be available in MODS -- The "win" of RDF is that
you aren't contrained by the limits of a particular schema.  If a
particular vocabulary gets you a fair ways towards representing your
resource, but something is missing, it's perfectly reasonable (and
expected) to plug in other vocabularies to fill in the gaps.

For example, SKOS doesn't need to add coordinate properties to
properly define locations.  Instead, you pull in a vocabulary that is
optimized for defining geographic place (say, wgs_84) and rather than
suboptimally retrofit a vocabulary designed for modeling thesauri, use
one that is explicitly intended to model the resource at hand (and,
preferably, only that).

I think it's somewhat analogous to the notion of domain-specific
languages:  there's an abstraction between the resource and the most
efficient way to access it.

> FOAF has both *surname* and *family name* and says: "These are not
> current stable or consistent..." No sh*t. And try to clearly code a name
> like "Pope John Paul II" in FOAF. Oh, and death dates. No death dates in
> FOAF because you wouldn't have DEAD FRIENDS. But authors die.
>

FOAF isn't the only vocabulary available to model people and I'm
hardly saying it's "the answer" here.  I mean, MARC is complicated in
this regard, too.  "Rodrigo Jimenez Hernandez Garcia"  "Liu Ming
Chung".  Names are hard.  I think pretty much any schema is going to
have to have rules and conventions to compensate for the variability
of how different cultures prescribe identity.

Maybe vCard would be better (maybe not).  The Bio vocabulary might be
a better option for defining biographical "events" (birth, death,
etc.).  It lacks some of the attributes that libraries use
(flourishing dates, for example) and shares the disadvantage inherent
in RDF that RDF can't express inexact dates very well.

I think a common misperception of RDF in library circles is that there
is no vocabulary that does everything we need.  Rather, I think that
this is one of RDF's strength: no vocabulary can successfully model
the universe, so, instead, focus on the specifics.  The library world
instead takes the opposite approach, which tends to cause things to
get shoehorned in to meet the shape of the model rather than be
expressed in a way more naturally suited to the resource.

-Ross.

---

From: Karen Coyle <[email-masked]>
Date: Wed, 12 Aug 2009 10:45:56 -0700

> them different semantic meaning.

Uh, no. That's the opposite of what the DC terms are about. Each term 
has a defined range -- so the defined range of creator is Agent. It can 
only be used as an Agent. You don't mix and match, and you don't assign 
different semantics to the same property under different circumstances. 
You can further *restrict* properties (which is what the application 
profile is all about) but you can't change the semantics of properties. 
The DCAM allows a property to be a member of more than one class, but I 
don't see any examples of that (will ask on the DC list) in DC terms. 
Remember that the A in DCAM is "abstract." Some of the things it makes 
possible may be unusable in real life.

> don't use a schema in isolation.

The elements in Dublin Core are the elements in Dublin Core. The 
serialization shouldn't really matter. But if you need to distinguish 
between title and subtitle, Dublin Core's http://purl.org/dc/terms/title 
doesn't work. What matters is the actual *meaning* of the term, and the 
degree of precision you need. You can't use 
http://purl.org/dc/terms/title for "Mr." or "Dr." in a name -- it has a 
particular meaning. And you can't use it for "title Proper" as defined 
in library cataloging, because it doesn't have that meaning. It all 
depends on what you are trying to say.

> expected) to plug in other vocabularies to fill in the gaps.

Exactly. But the range of available vocabularies today is quite limited. 
There are a lot of semantics that are used in libraries that I can't 
find in the available vocabularies. Eventually I think we will have what 
we need, but ... well, yesterday I was hunting all over for a data 
element for price. And the person who needed it didn't want to get into 
the complexity of ONIX. BIBO doesn't have it. DC doesn't have it. RDA 
doesn't have it. Something that simple.

Now I admit that lots of people are inventing bibliographic element 
sets. But if you look carefully at the properties they are defining, the 
overlap isn't all that great. At least, if you don't want to lose 
meaning. It's absolutely key to look at the semantics and the 
relationships. RDA is defining certain properties as having a fixed 
relationship to an FRBR entity. (I'd rather do that in an application 
profile rather than the properties, but that's not my call.) A similar 
property in DC, without making that connection, doesn't have the same 
meaning because you can't distinguish between a title for the work or a 
title for the expression. Perhaps you could create a record format that 
gives DC terms "title" that context, but used alone it does not contain 
those semantics.

What I WOULD like to see is a good vocabulary of basics -- date, time, 
place, currency, etc etc etc. One place where you know you can go and 
find all of those key building blocks, so you don't have to hunt all 
over god's little acre for something as simple as "price". That would be 
really useful.

kc

---

From: Robert Forkel <[email-masked]>
Date: Wed, 12 Aug 2009 20:20:27 +0200

On Wed, Aug 12, 2009 at 7:45 PM, Karen Coyle<[email-masked]> wrote:

> place, currency, etc etc etc. One place where you know you can go and find
> all of those key building blocks, so you don't have to hunt all over god's
> little acre for something as simple as "price". That would be really useful.

maybe currency is a good example in this regard. consider how long it
takes for units of measurement (or currencies - or languages) to
become universally accepted. i think that's what we're seeing with
linkeddata vocabularies right now. we'll have to live with the tension
of wanting to create an esperanto for everyone to use and settling for
minimal standards.
regards,
robert

---

From: "Thomale, J" <[email-masked]>
Date: Wed, 12 Aug 2009 14:27:25 -0500

> possible may be unusable in real life.

I think what Ross is getting at isn't exactly what he said: you're right of course that the semantics of a DC property don't change when you use it in various circumstances. What happens is that you use the same DC property to describe the same type of attribute for different entities within your data set. So, you use a dc:creator property to describe the creator of a digital image file, a dc:creator property to describe the creator of the thing in your image, and a dc:creator property to describe the creator of the metadata record. The properties point to different things, but it's still the same property--you don't need to define three separate and distinct properties in your schema. This is one of the things that makes MARC (and so many other metadata standards) unwieldy, because you've got the same essential type of property (like a "creator" property) that is defined separately depending on what it is supposed to be describing (when it doesn't necessarily have to be tha!
 t way).

> serialization shouldn't really matter. 

I think the reason it matters--and the reason that Ross mentioned it--is because the commonly-used XML serialization is just a flat DC record describing a single resource (isn't it?). Using a data model like RDF (or the DCAM), DC becomes a lot more powerful because of the ability to reuse the DC metadata properties to describe different entities/resources easily.

Your later point that some DC properties aren't specific enough (e.g., title) still stands, although I wonder if it would be kosher (as far as DC is concerned) to do something like this:

<http://example.org/resource-uri>	dc:title	<http://example.org/resource-uri/title>.
<http://example.org/resource-uri/title>	mods:title	"The Title of a Book".
<http://example.org/resource-uri/title>	mods:subtitle	"The Subtitle".

Similarly with names:

<http://example.org/resource-uri>	dc:creator	<http://example.org/johndoe>.
<http://example.org/johndoe>	awesomenamevocab:firstname	"John".
<http://example.org/johndoe>	awesomenamevocab:lastname	"Doe".

So that way you're making use DC elements that are already defined and adding specificity where necessary instead of reinventing new metadata elements where you really don't need to.

Jason Thomale
Metadata Librarian
Texas Tech University Libraries

---

From: Ross Singer <[email-masked]>
Date: Wed, 12 Aug 2009 16:35:43 -0400

On Wed, Aug 12, 2009 at 1:45 PM, Karen Coyle<[email-masked]> wrote:
> Uh, no. That's the opposite of what the DC terms are about. Each term has a
> defined range -- so the defined range of creator is Agent. It can only be
> used as an Agent. You don't mix and match, and you don't assign different
> semantics to the same property under different circumstances.

Jason clarified what I meant much better than I did, but I will take
this a step further -- the DC properties have ranges, but only 5 have
a constraint on their domain.  So while dct:creator has to point at a
dct:Agent (or some equivalent), where the dct:creator property lives
can be anything.

<dct:Location about="#RhodeIsland">
  <dct:title>Rhode Island</dct:title>
  <dct:creator>
    <dct:Agent about="#RogerWilliams">
     <dct:title>Roger Williams</dct:title>
     <dct:creator>
       <dct:Agent about="#JamesWilliams">
         <dct:title>James Williams</dct:title>
        </dct:Agent>
       <dct:Agent about="#AliceWilliams">
         <dct:title>Alice Williams</dct:title>
        </dct:Agent>
      </dct:creator>
    </dct:Agent>
  </dct:creator>
</dct:Location>

The definition of dct:title is:  A name given to the resource.  So
dct:title could be "re: [CODE4LIB] MARC/MODS and Automating Migration
to Linked-Data Standards", "Ross Singer" or "Chattanooga, TN"
depending on what resource we're talking about.  Maybe "semantics" is
a poor word choice, but I think "Ross Singer" as a "title of an Agent
resource" or "Chattanooga, TN" as the title of a Location resource
have some conceptual distinctions to "For Whom the Bell Tolls".

The "creation" of Rhode Island also carries a different mental image
than the "creation" of Roger Williams.

It seems like context influences semantics, at least somewhat.

> degree of precision you need. You can't use http://purl.org/dc/terms/title
> for "Mr." or "Dr." in a name -- it has a particular meaning. And you can't
> use it for "title Proper" as defined in library cataloging, because it
> doesn't have that meaning. It all depends on what you are trying to say.
>

Again, Jason did a good job at explaining the difference.  Dublin Core
in XML (at least in every example I've ever seen) consists solely of
literals.  The values are text, not resources -- so in XML DC, not
only would you be unable to attach, say, birth and death date
properties to Roger Williams, you also wouldn't be able to say who his
creators are.

Going back to "context defining semantics", I don't think it's
unreasonable to say that dct:title does mean "title distinct from
subtitle" if that's the expectation of how dct:title is to work within
your vocabulary/class.

<ex:Book about="http://example.org/ex/1234">
  <dct:title>Zen and the Art of Motorcycle Maintenance</dct:title>
  <ex:subTitle>An Inquiry into Values</ex:subTitle>
</ex:Book>

The definition of dct:title is pretty ambiguous -- alternately, you
might choose to use dct:title to contain the full title and define
some other property for main title.

Just because title doesn't have a clear definition doesn't mean rules
can't be applied towards it when used in a particular domain (assuming
they conform to 'the name of the resource').

> There are a lot of semantics that are used in libraries that I can't find in
> the available vocabularies. Eventually I think we will have what we need,
> but ... well, yesterday I was hunting all over for a data element for price.
> And the person who needed it didn't want to get into the complexity of ONIX.
> BIBO doesn't have it. DC doesn't have it. RDA doesn't have it. Something
> that simple.
>
Well, Bibo doesn't have it because it has nothing to do with citations.

GoodRelations (http://www.heppnetz.de/projects/goodrelations/) does,
but I admit that it's usage seems rather baroque:

http://www4.wiwiss.fu-berlin.de/bookmashup/doc/offers/0596000278googleOffer6997796095130913016

I'm not sure how you'd do this in MODS, though, either.

> Now I admit that lots of people are inventing bibliographic element sets.
> But if you look carefully at the properties they are defining, the overlap
> isn't all that great. At least, if you don't want to lose meaning. It's
> absolutely key to look at the semantics and the relationships. RDA is
> defining certain properties as having a fixed relationship to an FRBR
> entity. (I'd rather do that in an application profile rather than the
> properties, but that's not my call.) A similar property in DC, without
> making that connection, doesn't have the same meaning because you can't
> distinguish between a title for the work or a title for the expression.

Sure you can.

<frbr:Expression about="http://example.org/e/1234">
  <dct:title>Romeo + Juliet</dct:title>
  <frbr:realizationOf resource="http://example.org/w/1234" />
  <dct:creator resource="http://example.org/i/craig-pearce" />
  <dct:creator resource="http://example.org/i/baz-luhrmann" />
</frbr:Expression>
<frbr:Work about="http://example.org/w/1234">
  <dct:title>Romeo and Juliet</dct:title>
  <dct:creator resource="http://example.org/i/william-shakespeare" />
  <frbr:realization resource="http://example.org/e/1234" />
</frbr:Work>

> Perhaps you could create a record format that gives DC terms "title" that
> context, but used alone it does not contain those semantics.
>
But nothing is going to make sense out of context.

> little acre for something as simple as "price". That would be really useful.
+1 to that.  I completely agree this is far too difficult.

-Ross.

---

From: Karen Coyle <[email-masked]>
Date: Wed, 12 Aug 2009 14:14:48 -0700

Jason, it seems that what you are suggesting is the DC terms can be 
re-used in lots of different contexts, and that is true and that is a 
Good Thing. You have to create the context to use them in, but the 
"coreness" of DC is quite deliberate in that way. Library data is much 
more about control than sharing, and for that reason it emphasizes 
precise definitions and doesn't let users get "creative" with the 
metadata. It depends on what you are trying to do, and it all boils down 
to: the right tool for the job.

> So that way you're making use DC elements that are already defined and adding specificity where necessary instead of reinventing new metadata elements where you really don't need to.
The idea of a core that is extended is appealing. In a sense, that's 
what you do with classes in RDF. DC has "Agent" as a class, and all of 
the various agents are members of that class. What you have above, 
however, is not "is a type of" but "is a part of" and that violates the 
DC rule for extensions, which is that they must be able to be 
represented by the Core value (the "dumb-down" rule). So "subtitle" is 
not a type of title, it's a part of a title, and can't be represented by 
"title". You can't refer to "lastname" as "creator."

As a counter example, RDA has "title" and it has "title Proper", 
"parallel title", "translated title" -- each of those is wholly a title, 
so if you wanted to lose the detail you could refer to them as "title".

Now, I think you could, for the purposes of your metadata, re-define 
dc:creator to be of type foaf. So then in your metadata dc:creator can 
only accept values as defined by foaf. But you lose the ability to use 
dc:creator with a simple string. At this point, I see only a small 
advantage to the use of dc:creator. But it would be interesting to 
experiment with a DC application profile that leans on the DC core but 
extends the core in the way you indicate above. I think there would be 
problems extending some of the elements (e.g. "date" which is defined as 
an RDF literal). At this point it gets over my head because of the 
subtleties of the DCAM and how properties are defined within its bounds.

kc

---

From: Karen Coyle <[email-masked]>
Date: Wed, 12 Aug 2009 15:07:27 -0700

>          <dct:title>Alice Williams</dct:title>

The above looks really odd to me -- I'm not at all sure that you can use 
the class Agent in that way.... I was of the impression that classes are 
used in metadata definitions, but not in instances. Am I wrong?

> It seems like context influences semantics, at least somewhat.

Right. It can be used for all of those things. But it can't represent 
"subtitle" and it can't represent "parallel title" without further 
metadata definitions. You seem to be saying that title as defined in DC 
is very broad and can be used in lots of contexts. That's true, but 
that's the opposite of the issue that I'm having. The issue I'm having 
is that it is imprecise. So if I want precision, I've got to go beyond 
DC -- create a new definition, maybe extending DC, or maybe creating 
something new. And that's why you find people all over the place 
creating bibliographic metadata -- because they need more precision than DC.

> properties to Roger Williams, you also wouldn't be able to say who his

uh.... http://dublincore.org/documents/2008/09/01/dc-ds-xml/

I think you've been looking at the pre-DCAM DC XML.

>   <ex:subTitle>An Inquiry into Values</ex:subTitle>

Well, I can say that, but lots of other people will give me:

<ex:Book about="http://example.org/ex/1234">
  <dct:title>Zen and the Art of Motorcycle Maintenance: An Inquiry into Values
   </dct:title>
</ex:Book>

and they'll be just as correct. Because title can be anything I want it 
to be, but if we're trying to communicate clearly, that broadness of 
definition can be a problem.

> some other property for main title.

Great. Redefine it another 6 or 8 ways.... that's exactly my point.

> they conform to 'the name of the resource').

Which is what the DCAP is about. With an application profile, you 
*re-define* terms for your domain. Your definition, however, cannot 
negate the original definition, it can only extend it. So it wouldn't do 
for me to redefine title as the date of issuance of the resource (or 
redefine "issued" as the name the resource is known by). And the main 
thing about a DCAP is that you have to create a machine-readable 
definition that conforms to certain rules so that others can understand 
what you have decided to do with *your* data elements.

>>  A similar property in DC, without

Um, no "realization" is defined in FRBR. And Work and Expression are 
classes, not properties. I admit I'm pretty unsure how FRBR itself is 
going to be "realized" but I have my doubts that we'll have distinct 
structures like Work and Expression. This is an area I would like to see 
explored, but I'm not sure we have the information we need at this point 
-- no, more than that, I don't think we have the networks we need at 
this point. (BTW, this is all we have defined so far for FRBR, but this 
has been approved by the FRBR IFLA working group: 
http://metadataregistry.org/schemaprop/list/schema_id/14.html)

> But nothing is going to make sense out of context.

Ah, this is a key point where we disagree. Context helps, but we have to 
be able to move our metadata across contexts and have it still have 
meaning. To me, that's what RDF and the Semantic Web are all about. 
Freeing our metadata from the need for human interpretation, so it can 
be better used by machines. And for me that means precision, precision, 
precision. Which will fail at some points, because data is dirty and 
messy, but where it succeeds we will make great strides forward.

kc

---

From: Karen Coyle <[email-masked]>
Date: Wed, 12 Aug 2009 18:07:53 -0700

Karen Coyle wrote:
>
> The above looks really odd to me -- I'm not at all sure that you can 
> use the class Agent in that way.... I was of the impression that 
> classes are used in metadata definitions, but not in instances. Am I 
> wrong?

I'll answer my own question: yes, I'm wrong. Here's an example from the 
RDF primer:

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:ex="http://example.org/schemas/vehicles#"
            xml:base="http://example.org/things">

  <ex:PassengerVehicle rdf:ID="johnSmithsCar">
       <ex:registeredTo rdf:resource="http://www.example.org/staffid/85740"/>
       <ex:rearSeatLegRoom 
           rdf:datatype="&xsd;integer">127</ex:rearSeatLegRoom>
       <ex:primaryDriver rdf:resource="http://www.example.org/staffid/85740"/>
  </ex:PassengerVehicle>
</rdf:RDF>

So <frbr:Work> and <frbr:Expression> also appear to work as classes, if 
that's what you intend. I still can't wrap my head around what they are 
*functionally.* As far as I can tell, classes give you categories, but 
don't themselves have properties, so they don't function like the class 
in OOP. At best, it seems that you get:

A is of class X
B is of class X
C is of class X
therefore: class X = A, B, C

But if someone else states that
B is of class Y

then my question is: has B changed? In other words, is B of class X the 
same as B of class Y? (Assuming that both B's have the same URI.). Again 
this seems to get back to flexible v. specific. The more flexible you 
want to be, the more you depend on context. The more specific you are, 
the more your metadata is independent of context. So for me it comes 
down to functionality, which is how much context do I want to carry 
around in order to make sense of my metadata? I think for the purposes 
of open data exchange, context adds overhead.

kc

---

From: Ross Singer <[email-masked]>
Date: Wed, 12 Aug 2009 22:14:06 -0400

Whew -- just hit discard on my last message.

> then my question is: has B changed? In other words, is B of class X the
same
> as B of class Y? (Assuming that both B's have the same URI.).

"B" (for our purposes we'll say it's "http://example.org/ex/B") can claim
it's of as many types as the assertor is willing to predicate (making up
words all over this place) as long as none of the classes anywhere assert
that they owl:disjointWith (or some similar != assertion) another adopted
type.

So:
<rdf:Description about="http://example.org/ex/B">
 <rdf:type resource="http://vocab.org/frbr/core#Manifestation" />
 <dct:title>Zen and the Art of the Motorcycle Maintenance</dct:title>
 <rdf:type resource="http://purl.org/ontology/bibo/Book />
 <bibo:isbn10>0553277472</bibo:isbn10>
</rdf:Description>

Ok -- everything's still in the clear.  We've asserted that this resource is
a book and that, in FRBR terms, it's also a manifestation.  Both of these
assertions are true but they're talking about the same resource in different
vocabularies -- basically they describe the same thing in different world
views:  the FRBR model has no knowledge (nor need for knowledge) of
bibliographic metadata and vice versa.

Now, should you append to this graph something like:
 <rdf:type resource="http://vocab.org/frbr/core#Text" />

you've run aground.  The FRBR schema claims that by being a Text (of course
it makes no mention of what exactly that means) it implies also being an
Expression but it also defines that <frbr:Expression> <owl:disjointWith>
<frbr:Manifestation>  (and vice-versa):  that is, your resource can't be
both an Expression and Manifestation, which makes sense.

Now, this doesn't mean that Books and Manifestations are the same thing,
it's just that /this/ book also happens to be a manifestation.

As far your point about context goes, I think this comes down to trust,
credibility and provenance.  Even if you define special properties to
contain specific parts of your data, there is no way to enforce it.  For
example, let's say our new RDA vocabulary has:
  rda:titleProper
  rda:remainderofTitle

and all ILMSes move to an RDA/RDF model (I mean, yes, we're wandering into
fantasyland, just bear with me) and begin to store our resources using this
as the main data model.

Now let's say we have a stash of data we'd like to add to our collection:
maybe it's an e-book collection or a set of aggregated OA e-journals, a la
DOAJ.  The providers of this data are told we need it in our new RDA format
and they comply.  Let's say, though, that they weren't discriminate enough
to distinguish the titleProper from the remainderOfTitle internally but in
an effort to comply with our request, put their string in rda:titleProper
(it's got to go somewhere, after all) and call it a day.  Uncertainty has
crept into the mix.

After all, there's nothing, technically, stopping me from entering "Zen and
the art of motorcycle maintenance: an inquiry into values" all in the 245$a.

I think that replacing dct:title with rda:titleProper (rather than declaring
that when used in RDA, dct:title should be the proper title) won't
drastically help the purity of our data (especially if one of the
motivations of RDA and RDF is the promise of externally supplied data) and
will have the consequence of being in a vocabulary off the radar for anybody
not in a library (and therefore ignored).

It's a tough call, though.

-Ross.

---

From: "Thomale, J" <[email-masked]>
Date: Wed, 12 Aug 2009 21:26:45 -0500

> metadata. 

True. However, I would argue (based on my perhaps bizarre understanding) that the linked data world is just as much about control--in a different sense. Library data--and really any traditionally-designed data--is controlled from the top down. With linked data, control emerges from the bottom up. Getting "creative" with linked data is just as problematic as it is with library data. If you're using data elements differently than the rest of the world, then your data won't make sense in the context of the data that links to/from it.

> "title". You can't refer to "lastname" as "creator."

Let's just ignore my title/subtitle example--it's a bad one. What I intended to express isn't what I actually expressed, I don't think.

Focusing on the creator example, what I wrote above are 3 completely separate triples. The first says that <http://example.org/johndoe> is the dc:creator of <http://example.org/resource-uri>. The next two further define the resource <http://example.org/johndoe> by saying that it has an awesomenamevocab:firstname property of "John" and an awesomenamevocab:lastname property of "Doe". Those aren't supposed to be DC extensions; they're properties taken from a totally external data schema that I assert describe the <http://example.org/johndoe> resource (which just happens to be a dc:creator of <http://example.org/resource-uri>). I'm not trying to build new DC elements, nor am I asserting that those properties are somehow connected to DC, so the DC extension rules don't apply. I could say:

<http://example.org/resource-uri> dc:creator <http://example.org/johndoe>.
<http://example.org/johndoe> foaf:firstName "John".
<http://example.org/johndoe> foaf:surname "Doe".

And there would be no implication that the foaf data elements were somehow qualifiers or extensions of dc:creator. At the end of the triple with the dc:creator property is where the DC "jurisdiction" (so to speak) also ends.

> only accept values as defined by foaf. 

A better way might be to express an equivalency between foaf:Agent and dc:Agent and then assert explicitly that your resource is a foaf:Agent (or a foaf:Person), although I don't think there's really a need to do that. An RDF application would be able to make the appropriate inferences about your data just based on the properties you use, no matter where those properties come from. So, in my example above--assuming that I used namespaces appropriately--an RDF application could infer that my johndoe resource belongs to the dc:Agent class no matter what additional properties (inside or outside the dc namespace) I tie to that resource. Further, where I use foaf properties to describe the johndoe resource, an RDF browser would infer that the resource also belongs to the class foaf:Person. And that's okay--resources can belong to multiple classes at once.

This is an example of the "bottom up" control that linked data--in an ideal world--promises. Given enough inferences, an application might be able to draw some different equivalencies between dc:Agent and foaf:Agent, and therefore members of those classes, even though the two classes were created by two completely different communities. That's one reason that it's a good thing, in the linked data world, to use metadata languages from different communities to describe the same set of resources. It provides a basis for making all different kinds of inferences and making data between multiple communities more interoperable.

Jason