Hi Hugh, Thanks for taking the time to answer with examples! It's interesting that sameAs.org would become a kind of "buffer"/archive for URIs which are no longer de-referenceable on their original domain.
By the way this seems to me a quite similar pattern to what Nature.com does, which you've
just questioned ("I am wondering whether the use of owl:sameAs to a non-http URI is
best practice" [1]). owl:sameAs can be used to publish data on URIs that are not
de-referencable and non-http URIs can be just seen as such URIs, imho.
I should mention that we can "deprecate" the old URIs - this means that they can still be used for look up, but are not returned as part of the result set. (Neither the ECS nor Freebase ones are deprecated yet.)
Is there some explicit "signal" (some specific result code, or statement in the RDF data you serve) in that case, which warns the client that the URI it asked for is deprecated? That was in fact what we wanted to convey by using a 301 "moved permanently" redirection from the stitch.cs.vu.nl/rameau prototype to data.bnf.fr.... Cheers, Antoine [1] http://lists.w3.org/Archives/Public/public-lod/2012May/0032.html
Hi Antoine, On 23 Apr 2012, at 21:41, Antoine Isaac wrote:Hi Hugh, It seems that http://sameas.org/store/kelle/?uri=http://stitch.cs.vu.nl/vocabularies/rameau/ark:/12148/cb14521343b already has the owl:sameAs to http://data.bnf.fr/ark:/12148/cb14521343b so all is already taken care of! Great job :-)Excellent - thanks.That being said I'm curious about your experience on the matter: did you have once a case where a linked dataset was "moved", and the publisher and/or yourself asserted RDF statements to handle the transition? Either with owl:sameAs, dcterms:replaces or anything else…Good question. Quite a few times. Only last month, ECS Eprints (http://eprints.ecs.soton.ac.uk/) moved all its records (>100K, c. 500K triples) to the institutional repository (http://eprints.soton.ac.uk/). So we have currently got the two sets of records aligned in a sameAs store (as well as the http://sameas.org/), prior to the presumed forth-coming switch off of the ECS one. But the ECS URIs will continue to work in our system, as they will be linked to the new ones. Freebase has also changed its URIs. They have moved from using long guid ones to shorter ns ones (I think that is the way round). They gave us the pairings, which we have put at http://sameas.org/store/freebase/, e.g. http://sameas.org/store/freebase/?uri=http://rdf.freebase.com/ns/m.086qd The suggestion is that they then will not need to support the old ones, but can just point their users at http://sameas.org/store/freebase/ With our own RKB data we have frequently had the need to stop using URIs, and sometimes whole LD stores. When this happens, it is often the case that the URIs are still somewhere in our system, often in caches etc.. But because everything is mediated through sameAs stores, we just look up to select the current "canon". I should mention that we can "deprecate" the old URIs - this means that they can still be used for look up, but are not returned as part of the result set. (Neither the ECS nor Freebase ones are deprecated yet.) So essentially, rather than touch either of the stores (the source one where the RDF comes from or the target one where it moves to), the only place the owl:sameAs links go is in the sameAs store. And because the target one does not have the old source URIs in it, which are also deprecated in the sameAs store, then the old URIs slowly (or hopefully quickly) become things of the past, because they can only be found if something else remembers them. I hope that makes some sense. Best HughBest, AntoineHi 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, AntoineDear 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.
