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

RE: Question about MARCXML to Models transformation

From: Young,Jeff (OR) <jyoung@oclc.org>
Date: Wed, 9 Mar 2011 12:21:15 -0500
Message-ID: <52E301F960B30049ADEFBCCF1CCAEF590BBB766F@OAEXCH4SERVER.oa.oclc.org>
To: "Ross Singer" <ross.singer@talis.com>
Cc: "Karen Coyle" <kcoyle@kcoyle.net>, <public-lld@w3.org>
I agree it's worrisome. I don't see any alternatives, though, because
information is currently scattered all over hell. :-(

 

Jeff

 

From: Ross Singer [mailto:ross.singer@talis.com] 
Sent: Wednesday, March 09, 2011 11:55 AM
To: Young,Jeff (OR)
Cc: Karen Coyle; public-lld@w3.org
Subject: Re: Question about MARCXML to Models transformation

 

On Wed, Mar 9, 2011 at 11:20 AM, Young,Jeff (OR) <jyoung@oclc.org>
wrote:

	One way to punt on this problem would be to treat the
relationship between W&M as 1-to-1 for now (80/20 rule). This would
create some alias URIs for Expressions and possibly conflate a few, but
we could always come in later and use owl:sameAs to reconcile the
aliases and improve the data mining to split those we conflate.


I'll probably be outnumbered on this, but I begin to feel somewhat
uncomfortable to assigning massive amounts of URIs for things in the
absence of knowing what they are.  This is further compounded by the
fact that they're being created because we have so little data to work
with.

I can't help but feel there are lots of hidden costs here (persistence
of the deprecated "stub" URIs, being one, but even just the general fact
that you need to dereference -- and store -- an extra,
not-terribly-valuable, URI simply to get a CBD of the Manifestation),
but I also, personally, feel it's significantly easier to add data
later, when we know with some more confidence what it is we're
describing, than it is to edit.  Especially at scale.

Do others perceive this to be an issue?

-Ross.
Received on Wednesday, 9 March 2011 17:22:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 March 2011 17:22:03 GMT