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>
