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

Right (last time I looked :)

If a 410 is returned, then we may deduce the resource is gone for good, but
with a 404 or dns/network error, a resource may return. Repeated, failed
probes may give empirical grounds for believing that the resource is gone
for good, but this is weaker justification.

OTOH, caching headers may give positive reasons to believe in cached
contents for an unresolvable name; vary headers may also be useful.

A property or class marking a permanent 410 is definitely needed.
It may be that caching info - validUntil - , together with some history of
failed probes needs to be captured. The first known date a resource wasn't
retrievable plus the last known date it was may be enough to get started.

Simon
On Jun 2, 2014 10:25 AM, "Bernard Vatant" <bernard.vatant@mondeca.com>
wrote:

> 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
>>
>>