 |
 |
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 >> > > > >> >> >