W3C home > Mailing lists > Public > public-vocabs@w3.org > June 2014

Re: How do you flag a resource which is not available anymore?

From: Bernard Vatant <bernard.vatant@mondeca.com>
Date: Mon, 2 Jun 2014 16:22:27 +0200
Message-ID: <CAK4ZFVH8G-2tMSvimo5Sxxwc1v0xiXEzEYO8ZY0-75-BJ4xz3A@mail.gmail.com>
To: Karen Coyle <kcoyle@kcoyle.net>
Cc: "public-vocabs@w3.org" <public-vocabs@w3.org>
Karen

Your proposal provides indeed the lowest ontological commitment. You have
this good ol' Schrödinger's box with "Herin lyes ye olde cat" posted on it.
The variant with Schrödinger's original is that your opening of the box
does not either kill the cat or make it alive, but makes him either indeed
present in the box (making the post on the box consistent with the content)
or not. You can open the box as many times as you want finding the cat in
and infer (falsely) that he is here to stay. The other way round you can
find the box empty so many times and infer (falsely) the cat is gone for
good, because you always open the box at maintenance time.

But users of a vocabulary would like to know more, namely if the cat is
gone *for good*, and they can't know it for sure by simply opening the box
again and again and saying "at times T1, T2, ..., Tn the cat was out". You
need another resource to say : we know that the cat is gone for good
because the box has been sold from X to Y, and Y does not care about cats,
he's selling rabbits, or we have met a hunter who killed the cat for good,
whatever. IOW, the information that a URI is dead for good cannot come from
a GET on this URI.


2014-06-02 15:48 GMT+02:00 Karen Coyle <kcoyle@kcoyle.net>:

>
>
> On 6/2/14, 6:22 AM, Bernard Vatant wrote:
>
>> Hi Quentin
>>
>> The way I understood it, owl:deprecated is more designed to mark
>> elements in a vocabulary as deprecated, but not the entire vocabulary.
>> Moreover, owl:deprecated should be used in a controlled versioning
>> workflow, by the vocabulary publisher herself, and in the best of
>> worlds, it goes with a dcterms:isReplacedBy (but as said above, this is
>> not unfortunately a very frequent practice).
>> Here we deal with URIs which just disappear "puff" in a smoke like URIs
>> do, by neglect of their owner, hosting not paid, site reorganization
>> whatever.
>>
>
> To my mind, the key here is that the URI does not resolve to more
> information about the resource (as per TimBL), but the URI itself continues
> to exist (in data) and continues to identify what it always identified.
> It's just now harder to learn what it means, and what are its semantics.
>
> While it is a best practice to provide information that is retrievable
> with the URI, it is not a requirement. Also, as we see with purl.org,
> lack of resolution services can be temporary. We keep on using dcterms in
> spite of that.
>
> A property representing the message "did not resolve on {date}" therefore
> seems to be what is needed.
>
> kc
>
>
Received on Monday, 2 June 2014 14:23:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:42 UTC