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

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

> And we have to make this observation and declaration from outside : the
> resource we are speaking about used to live at this URI, but for some
> non documented reason it's not there anymore.
>
>
> 2014-06-02 14:45 GMT+02:00 Quentin Reul <Quentin.H.Reul@gmail.com
> <mailto:Quentin.H.Reul@gmail.com>>:
>
>     Hi all,
>
>     It may be a bit too simplistic, but OWL2 defines a property
>     (owl:deprecated [1]) to mark any entities (classes, properties and
>     instances) as deprecated. The range of the property is xsd:boolean.
>     Would this not be sufficient for your needs?
>
>     Kind regards,
>
>     Quentin Reul
>
>     [1] http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#a_deprecated
>
>
>     On 2 June 2014 03:17, Bernard Vatant <bernard.vatant@mondeca.com
>     <mailto:bernard.vatant@mondeca.com>> wrote:
>
>         Simon
>
>         Thanks for the reference, not yet looked into it in details, but
>         as answered to Ed, we're not looking for an overkill solution :)
>
>
>         2014-05-30 23:13 GMT+02:00 Simon Spero <sesuncedu@gmail.com
>         <mailto:sesuncedu@gmail.com>>:
>
>             This paper is generally relevant to the semantics, though it
>             doesn't solve the specific problem:
>
>             Representing and Querying Validity Time in RDF and OWL: A
>             Logic-Based Approach✩
>             Boris Motik, Oxford University Computing Laboratory, Oxford, UK
>
>             http://www.cs.ox.ac.uk/boris.motik/pubs/m12validity-time.pdf
>
>             PROV-O can handle the use case, but has the downside of
>             being PROV-O, and requiring a few blank nodes (validity is a
>             bit fuzzy).
>
>             http://www.w3.org/TR/2013/REC-prov-o-20130430/#invalidatedAtTime
>             http://www.w3.org/TR/2013/REC-prov-o-20130430/#Revision
>
>             Also, note that the ontology named by a version IRI is
>             fixed;  if the IRI becomes impossible to dereference, the
>             cached content should always be valid;  however, this may
>             not be the case if the base IRI is used.
>
>
>         Indeed! But the use of versionIRI in LOV vocabularies is not a
>         general practice, far from it : See http://bit.ly/1nH1vlq
>         Less than 10% of vocabularies have a owl:versionIRI declaration,
>         and those who use it don't always do it correctly :(
>         More generally the versioning policy is globally a mess ... See
>         http://bit.ly/RWoZUu
>         Very often there is no version number or date whatsoever, or
>         they are not consistent between the documentation and RDF files
>         (you can have one date in the html, another in the RDF/XML file,
>         and yet another one in the Turtle ...
>
>             The contents of the LOV-back-machine is as valid as it ever
>             was.
>               It is possible that an unversioned ontology  might have
>             changed between the last capture and the 404
>
>
>         This should not happen if the LOV-Bot, which is tracking changes
>         on a daily basis, does its job properly. But due to content
>         negotiation issues and dozens of other reasons, it is not always
>         the case. And very small changes like corrections of typos can
>         induce the LOV-Bot into uploading of a new version, althogh the
>         formal version information has not changed.
>
>         But those are known issues that I would not want to blur the
>         simple question at hand : simply providing the information that
>         this URI used to be dereferenceable, but is currently no more,
>         so if you use this vocabulary in your data, the semantics will
>         not be found through the vocabulary URI, but through some
>         version backup etc. We are in terra incognita there ...
>
>         Bernard
>
>
>             On Fri, May 30, 2014 at 5:09 AM, Bernard Vatant
>             <bernard.vatant@mondeca.com
>             <mailto:bernard.vatant@mondeca.com>> wrote:
>
>                 Hi vocabulers
>
>                 We have more and more records in LOV of which URIs are
>                 404, unfortunately, with no replacing resource whatsoever.
>                 See e.g.,
>                 http://lov.okfn.org/dataset/lov/details/vocabulary_dir.html
>                 etc
>                 We want to keep the record in LOV, along with backup
>                 versions, such as
>                 http://lov.okfn.org/dataset/lov/agg/archives/dir_dir/file_dir_2006-06-27.n3
>
>                 We want to flag the URI some way, such as some
>                 "offlineSince" or "validUntil" property, with value a
>                 xsd:date. This property would be added to the VOAF
>                 vocabulary, unless someone knows about an existing
>                 property to express that. There are various "valid"
>                 properties in DC terms and other vocabularies, but not
>                 sure they capture the expected semantics.
>
>                 Thanks for any suggestion.
>
>                 --
>                 *Bernard Vatant
>                 *
>                 Vocabularies & Data Engineering
>                 Tel : + 33 (0)9 71 48 84 59
>                 Skype : bernard.vatant
>                 http://google.com/+BernardVatant
>                 --------------------------------------------------------
>                 *Mondeca*****
>                 35 boulevard de Strasbourg 75010 Paris*
>                 *
>                 www.mondeca.com <http://www.mondeca.com/>
>                 Follow us on Twitter : @mondecanews
>                 <http://twitter.com/#%21/mondecanews>
>                 ----------------------------------------------------------
>
>
>
>
>
>         --
>         *Bernard Vatant
>         *
>         Vocabularies & Data Engineering
>         Tel : + 33 (0)9 71 48 84 59
>         Skype : bernard.vatant
>         http://google.com/+BernardVatant
>         --------------------------------------------------------
>         *Mondeca*****
>         35 boulevard de Strasbourg 75010 Paris*
>         *
>         www.mondeca.com <http://www.mondeca.com/>
>         Follow us on Twitter : @mondecanews
>         <http://twitter.com/#%21/mondecanews>
>         ----------------------------------------------------------
>
>
>
>
>
> --
> *Bernard Vatant
> *
> Vocabularies & Data Engineering
> Tel : + 33 (0)9 71 48 84 59
> Skype : bernard.vatant
> http://google.com/+BernardVatant
> --------------------------------------------------------
> *Mondeca*****
> 35 boulevard de Strasbourg 75010 Paris*
> *
> www.mondeca.com <http://www.mondeca.com/>
> Follow us on Twitter : @mondecanews <http://twitter.com/#%21/mondecanews>
> ----------------------------------------------------------

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

Received on Monday, 2 June 2014 13:49:04 UTC