Hi Antoine, Apart from all the internal stuff, you (or rather your users) can of course use http://sameas.org (in fact, this is part of its raison d'ĂȘtre, to use an English phrase). E.g. http://sameas.org/?uri=http://stitch.cs.vu.nl/vocabularies/rameau/ark:/12148/cb14521343b is the main one, but there is a specialist library one at http://sameas.org/store/kelle e.g. http://sameas.org/store/kelle/?uri=http://stitch.cs.vu.nl/vocabularies/rameau/ark:/12148/cb14521343b
If you wanted your own store to only have the mappings you care about and carrying your own trust to your users, then please email me and I will create it. Best Hugh On 20 Apr 2012, at 14:11, Antoine Isaac wrote: > Thanks a lot for your feedback! That's really precious. > > @Richard, Jon: yes, we'll try to have the 301 working for a while. But not > forever, so it would be good if something could function as a more stable > solution. Though I'm not sure the requirement is too strong, in our case. > It's not as if we were dbPedia ;-) > > @Kevin: yes, the sameAs statement is served on the data.bnf.fr side. > > > @Bernard, Ed, on using dcterms:replaces instead of owl:sameAs between the > stitch and bnf URIs for our SKOS concepts: > > For once, I have quite a good feeling about using owl:sameAs. It seems to > really match the case at hand: the URIs are really about the same resource. > And with the new situation, all the 'official' statements on the stitch URIs > comes from the data.bnf.fr site. And there's just one such statement: the > sameAs one! > So that limits the risk of dangerous inferences that people are usually > afraid of, I'd say. > > We could still use dcterms:replaces *next* to owl:sameAs. But there's a > conflict: one resource would replace itself... > > In fact it seems that the dcterms:replaces option considers two resources > (one that replace the other). Which in turns hints that you're considering > that the URIs denote the URI themselves (or a 'concept-with-a-URI'), and not > the resource (concept). I'm quite reluctant to this... > > Best, > > Antoine > > >> Dear all, >> >> We have a question on an what to do when a linked data set is "moved" from >> one namespace to the other. We searched for recipes to apply, but did not >> really find anything 'official' around... >> >> The VU university of Amsterdam has published a Linked Data SKOS >> representation of RAMEAU [1] as a prototype, several years ago. For example >> we have >> http://stitch.cs.vu.nl/vocabularies/rameau/ark:/12148/cb14521343b >> >> Recently, BnF implemented its own production service for RAMEAU. The >> previous concept is at: >> http://data.bnf.fr/ark:/12148/cb14521343b >> (see RDF at http://data.bnf.fr/14521343/web_semantique/rdf.xml) >> >> The production services makes the prototype obsolete. Our issue is how to >> properly "transition" from one to the other. Several services are using the >> URIs of the prototype. For example at the Library of Congress: >> http://id.loc.gov/authorities/subjects/sh2002000569 >> >> We can ask for the people we know to change their links. But identifying the >> users of URIs seems too manual, error-prone a process. And of course in >> general we do not want links to be broken. >> >> Currently we have done the following: >> >> - a 301 "moved permanently" redirection from the stitch.cs.vu.nl/rameau >> prototype to data.bnf.fr. >> >> - an owl:sameAs statement between the prototype URIs and the production >> ones, so that a client searching for data on the old URI gets data that >> enables it to make the connection with the original resource (URI) it was >> seeking data about. >> >> Does that seem ok? What should we do, otherwise? >> >> Thanks for any feedback you could have, >> >> Antoine Isaac (VU Amsterdam side) >> Romain Wenz (BnF side) >> >> [1] RAMEAU is a vocabulary (thesaurus) used by the National Library of >> France (BnF) for describing books. >> > > -- Hugh Glaser, Web and Internet Science Electronics and Computer Science, University of Southampton, Southampton SO17 1BJ Work: +44 23 8059 3670, Fax: +44 23 8059 3045 Mobile: +44 75 9533 4155 , Home: +44 23 8061 5652 http://www.ecs.soton.ac.uk/~hg/
