The new URI may be unavoidable to resolve the present situation, especially
realizing that current attempted solutions do not deal with verioning
succesfully, as Jenn Riley notes through experience.
What is the current state of the art for dealing with versioning in URIs, with
having URIs that specify a particular version of the thing-identified, but also
allow you to easily tell that any of those URIs represents the thing at some
version, when you don't care about what version in particular.
Sure, conceptually and theoretically you could use ANY arbitrary URIs to refer
to a specific version. http://something.org/mods refers to mods 3.0, and
http://else.org/mods refers to 3.1, and http://foo.com/bar refers to mods 3.2.
And then I guess you could theoretically have RDF that asserts the
same-thing-different-version relationship between them? I think? I'm no RDF
expert, is why I ask.
But even if that's conceptually possible, it wouldn't be a good idea. Too
confusing to humans (and being un-confusing to humans is part of what we do to
try and encourage consistency and consensus in use); also too much trouble to
discover that two URIs represent different versions of the same thing when you
don't really care about version, you've got to actually follow the RDF
spiderweb. We've got to build URIs that work for fantasy where all systems
really DO understand RDF (and for the present few that do), AND that still work
for the majority of present day cases where systems don't.
http://something.info/mods/3.0?
http://something.info/mods#3.0 ?
Naturally, either of those could give you RDF representations of the OTHER
existing URIs that represent that particular version of MODS.
Could http://something.info/mods then give you RDF representations of the other
existing URIs that represent MODS regardless of version?
Are other people in linked data and URIs in general doing anything that makes
sense in these areas?
Jonathan
From: Code for Libraries [code4...@listserv.nd.edu] On Behalf Of Ross Singer
[rossfsin...@gmail.com]
Sent: Friday, May 01, 2009 9:16 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] One Data Format Identifier (and Registry) to Rule Them
All
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 rochk...@jhu.edu 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
