I agree that most software probably won't do it. But the data will be
there and free and relatively easy to integrate if one wanted to.
In a lot ways, Jonathan, it's got Umlaut written all over it.
Now to get to Jonathan's point -- yes, I think the primary goal still
needs to be working towards bringing use of identifiers for a given
thing to a single variant. However, we would obviously have to know
what the options are in order to figure out what that one is -- while
we're doing that, why not enter the different options into the
registry and document them in some way (such as, who uses this
variant?). Voila, we have a "crosswalk".
Of course, the downside is that we technically also have a "new" URI
for this resource (since the skos:Concept would need to have a URI),
but we could probably hand wave that away as the id for the registry
concept, not the data format.
So -- we seem to have some agreement here?
-Ross.
On Fri, May 1, 2009 at 5:53 PM, Jonathan Rochkind <[log in to unmask]> wrote:
> From my perspective, all we're talking about is using the same URI to refer
> to the same format(s) accross the library community standards this community
> generally can control.
>
> That will make things much easier for developers, especially but not only
> when building software that interacts with more than one of these standards
> (as client or server).
>
> Now, once you've done that, you've ALSO set the stage for that kind of RDF
> scenario, among other RDF scenarios. I agree with Mike that that particular
> scenario is unlikely, but once you set the stage for RDF experimentation
> like that, if folks are interested in experimenting (and many in our
> community are), maybe something more attractively useful will come out of
> it.
>
> Or maybe not. Either way, you've made things easier and more inter-operable
> just by using the same set of URIs across multiple standards to refer to the
> same thing. So, yeah, I'd still focus on that, rather than any kind of
> 'cross walk', RDF or not. It's the actual use case in front of us, in which
> the benefit will definitely be worth the effort (if the effort is kept
> manageable by avoiding trying to solve the entire universe of problems at
> once).
>
> Jonathan
>
> Mike Taylor wrote:
>>
>> So what are we talking about here? A situation where an SRU server
>> receives a request for response records to be delivered in a
>> particular format, it doesn't recognise the format URI, so it goes and
>> looks it up in an RDF database and discovers that it's equivalent to a
>> URI that it does know? Hmm ... it's crazy, but it might just work.
>>
>> I bet no-one does it, though.
>>
>> _/|_
>> ___________________________________________________________________
>> /o ) \/ Mike Taylor <[log in to unmask]>
>> http://www.miketaylor.org.uk
>> )_v__/\ "Someday, I'll show you around monster-free Tokyo" -- dialogue
>> from "Gamera: Guardian of the Universe"
>>
>>
>>
>>
>> Peter Noerr writes:
>> > I agree with Ross wholeheartedly. Particularly in the use of an RDF
>> based mechanism to describe, and then have systems act on, the semantics of
>> these uniquely identified objects. Semantics (as in Web) has been exercising
>> my thoughts recently and the problems we have here are writ large over all
>> the SW people are trying to achieve. Perhaps we can help...
>> > > Peter > > > -----Original Message-----
>> > > From: Code for Libraries [mailto:[log in to unmask]] On Behalf
>> Of
>> > > Ross Singer
>> > > Sent: Friday, May 01, 2009 13:40
>> > > To: [log in to unmask]
>> > > Subject: Re: [CODE4LIB] One Data Format Identifier (and Registry) to
>> Rule
>> > > Them All
>> > > > > Ideally, though, if we have some buy in and extend this outside
>> our
>> > > communities, future identifiers *should* have fewer variations, since
>> > > people can find the appropriate URI for the format and use that.
>> > > > > I readily admit that this is wishful thinking, but so be it. I
>> do
>> > > think that modeling it as SKOS/RDF at least would make it attractive
>> > > to the Linked Data/Semweb crowd who are likely the sorts of people
>> > > that would be interested in seeing URIs, anyway.
>> > > > > I mean, the worst that can happen is that nobody cares, right?
>> > > > > -Ross.
>> > > > > On Fri, May 1, 2009 at 3:41 PM, Peter Noerr
>> <[log in to unmask]> wrote:
>> > > > I am pleased to disagree to various levels of 'strongly" (if we can
>> agree
>> > > on a definition for it :-).
>> > > >
>> > > > Ross earlier gave a sample of a "crossw3alk' for my MARC problem.
>> What he
>> > > supplied
>> > > >
>> > > > -----snip
>> > > > We could have something like:
>> > > > <http://purl.org/DataFormat/marcxml>
>> > > > . <skos:prefLabel> "MARC21 XML" .
>> > > > . <skos:notation> "info:srw/schema/1/marcxml-v1.1" .
>> > > > . <skos:notation> "info:ofi/fmt:xml:xsd:MARC21" .
>> > > > . <skos:notation> "http://www.loc.gov/MARC21/slim" .
>> > > > . <skos:broader> http://purl.org/DataFormat/marc .
>> > > > . <skos:description> "..." .
>> > > >
>> > > > Or maybe those skos:notations should be owl:sameAs -- anyway,
>> that's not
>> > > really the point. The point is that all of these various identifiers
>> would
>> > > be valid, but we'd have a real way of knowing what they actually
>> mean.
>> > > Maybe this is what you mean by a crosswalk.
>> > > > ------end
>> > > >
>> > > > Is exactly what I meant by a "crosswalk". Basically a translating
>> > > dictionary which allows any entity (system or person) to relate the
>> various
>> > > identifiers.
>> > > >
>> > > > I would love to see a single unified set of identifiers, my life as
>> a
>> > > wrangled of record semantics would be soooo much easier. But I don't
>> see it
>> > > happening.
>> > > >
>> > > > That does not mean we should not try. Even a unification in our
>> space
>> > > (and "if not in the library/information space, then where?" as Mike
>> said)
>> > > reduces the larger problem. However I don't believe it is a scalable
>> > > solution (which may not matter if all of a group of users agree, they
>> why
>> > > not leave them to it) as, at any time one
>> group/organisation/person/system
>> > > could introduce a new scheme, and a world view which relies on
>> unified
>> > > semantics would no longer be viable.
>> > > >
>> > > > Which means until global unification on an object (better a (large)
>> set
>> > > of objects) is achieved it will be necessary to have the translating
>> > > dictionary and systems which know how to use it. Unification reduces
>> Ray's
>> > > list of 15 alternative uris to 14 or 13 or whatever. As long as that
>> number
>> > > is >1 translation will be necessary. (I will leave aside discussions
>> of
>> > > massive record bloat, continual system re-writes, the politics of
>> whose
>> > > view prevails, the unhelpfulness of compromises for joint solutions,
>> and so
>> > > on.)
>> > > >
>> > > > Peter
>> > > >
>> > > >> -----Original Message-----
>> > > >> From: Code for Libraries [mailto:[log in to unmask]] On
>> Behalf Of
>> > > >> Mike Taylor
>> > > >> Sent: Friday, May 01, 2009 02:36
>> > > >> To: [log in to unmask]
>> > > >> Subject: Re: [CODE4LIB] One Data Format Identifier (and Registry)
>> to
>> > > Rule
>> > > >> Them All
>> > > >>
>> > > >> Jonathan Rochkind writes:
>> > > >> > Crosswalk is exactly the wrong answer for this. Two very small
>> > > >> > overlapping communities of most library developers can surely
>> agree
>> > > >> > on using the same identifiers, and then we make things easier
>> for
>> > > >> > US. We don't need to solve the entire universe of problems.
>> Solve
>> > > >> > the simple problem in front of you in the simplest way that
>> could
>> > > >> > possibly work and still leave room for future expansion and
>> > > >> > improvement. From that, we learn how to solve the big problems,
>> > > >> > when we're ready. Overreach and try to solve the huge problem
>> > > >> > including every possible use case, many of which don't apply to
>> you
>> > > >> > but SOMEDAY MIGHT... and you end up with the kind of
>> > > >> > over-abstracted over-engineered
>> > > >> > too-complicated-to-actually-catch-on solutions that... we in
>> the
>> > > >> > library community normally end up with.
>> > > >>
>> > > >> I strongly, STRONGLY agree with this. It's exactly what I was
>> about
>> > > >> to write myself, in response to Peter's message, until I saw that
>> > > >> Jonathan had saved me the trouble :-) Let's solve the problem
>> that's
>> > > >> in front of us right now: bring SRU into harmony with OpenURL in
>> this
>> > > >> respect, and the very act of doing so will lend extra legitimacy
>> to
>> > > >> the agreed-on identifiers, which will then be more strongly
>> positioned
>> > > >> as The Right Identifiers for other initiatives to use.
>> > > >>
>> > > >> _/|_
>> > > ___________________________________________________________________
>> > > >> /o ) \/ Mike Taylor <[log in to unmask]>
>> > > >> http://www.miketaylor.org.uk
>> > > >> )_v__/\ "You cannot really appreciate Dilbert unless you've read
>> it in
>> > > >> the original Klingon." -- Klingon Programming Mantra
>> > > >
>>
>>
>
|
