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

On 6/2/14, 10:19 AM, Simon Spero wrote:
> 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.

Yes, something like this. But I agree that in the absence of an 
owner-assigned 410, signaling an intention, a declaration that the 
resource is "gone for good" will need some hedge.

What is worse in the situation Bernard describes is that the domain name 
may be resold and re-used, but unrelated to the original vocabulary. 
Although unlikely, some vocabulary items may resolve in the future, but 
to something entirely unrelated. In that case, part of the message needs 
to be something like: this has been determined to be unresolvable; do 
not attempt resolution.

kc


>
> Simon
>
> On Jun 2, 2014 10:25 AM, "Bernard Vatant" <bernard.vatant@mondeca.com
> <mailto: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
>     <mailto: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 <http://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
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet

Received on Monday, 2 June 2014 18:47:45 UTC