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

Bernard, the difference seems to be that I do not consider the URI to be 
dead, only the information that the URI points to. The URI no longer 
functions *also* as a URL -- it no longer locates, but it still 
identifies. [*]

It would be great to be able to tell users that the information is gone 
for good if that is known -- it would also be useful to point them to an 
archive or cache of the information if it exists, such as the Internet 
Archive Wayback machine that I cited earlier.

There has been talk of creating archives for ontologies so that there 
will always be a copy of the definitions and documentation available. 
Sometimes that discussion includes maintaining the namespace, but I'm 
not sure how feasible that is. There may need to be an alternate 
namespace so that one can archive an ontology BEFORE the original 
namespace no longer functions as it should.

"Gone for good" presumes knowledge of the future. "Gone for now" seems 
more likely.

kc

[*] While I have come to understand reasons behind the http:// URI, it 
has always made me nervous because of the confusion between URI/URL when 
you have something that *can* be both, but at certain moments, like the 
cat, is one or the other.

On 6/2/14, 7:22 AM, Bernard Vatant 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 15:03:40 UTC