Re: Question on "moving" linked data sets

Hi Bernard,

Indeed there is a bit of trust from the STITCH side: we believe than whatever was at stitch:x will be found at bnf:x. And we're talking about one same concept, yes: it's not one "new" concept replacing an "old" one. It is an identity change, so to say.

If there's a change to that concepts' description (label, definition, whatever) it should not be large enough to change the concept itself. The kind of change that we could have handled in the STITCH space without changing the concept's URI. For example, if we had created ourselves an update of RAMEAU with a minor change in the concept label, we certainly would have kept the same URI (stitch:x) for that concept. We would *not* have created a new resource with URI stitch:y and asserted { stitch:y dcterms:replaces stitch.cs.vu.nl:x }.

And of course we trust BnF to behave relatively well on this. After all, they have already some form of commitment, since the "x" part of our example is an ARK identifier [1], which is *persistent*. In fact those ARK were created even before the first linked data version of RAMEAU!

Cheers,

Antoine

[1] http://en.wikipedia.org/wiki/Archival_Resource_Key


> Antoine
>
>     In fact it seems that the dcterms:replaces option considers two resources (one that replace the other).
>
>
> Indeed. The "bnf" resource replaces, by all means of the term, the "stitch" one.
>
>     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).
>
>
> There I don't follow you. Let's say I have both URIs stitch:x and bnf:y. They both identify resources, which happen to be instances of skos:Concept.
> When I read stitch:x dcterms:isReplacedBy bnf:y
> I understand : Whenever you used the resource stitch:x (in your linked data, vocabularies, index ...), please now use bnf:y.
> That does not mean only change dumbly the URI in your application, but it means also that if you want to figure the current definition of the concept, trust what you'll find when you dereference bnf:y. It might be strictly the same description as was once found at stitch:x, or it might have changed (for example this concept has been moved in the RAMEAU hierarchy, or its label or definition slightly modified etc). And since from stitch side you don't know about it, you can't assert any owl:sameAs for sure. BNF description can keep owl:sameAs links to assert that indeed for this very concept, the semantics has not changed since stitch, and get rid of this sameAs if ever the concept changes.
> Actually, quite a lot of RAMEAU concepts have changed since stitch publication. Maybe (certainly) some concepts present in stitch are not present any more in RAMEAU. In that case the bnf:y would be 404 and it's OK. It means stitch:x has been replaced by nothing in bnf namespace.
> Of course, this does not look as a good practice, but I'm afraid it justs shows the plain fact that RAMEAU has not (yet) a clean depreciation mechanism, unless I miss recent developments (Romain can correct me if I am wrong). I'm sure it will have some day soon :)
>
> Bernard
>
> --
> *Bernard Vatant
> *
> Vocabularies & Data Engineering
> Tel : + 33 (0)9 71 48 84 59
> Skype : bernard.vatant
> Linked Open Vocabularies <http://labs.mondeca.com/dataset/lov>
>
> --------------------------------------------------------
> *Mondeca** ** *
> 3 cité Nollez 75018 Paris, France
> www.mondeca.com <http://www.mondeca.com/>
> Follow us on Twitter : @mondecanews <http://twitter.com/#%21/mondecanews>
>

Received on Monday, 23 April 2012 20:37:06 UTC