Re: "undefined" URI scheme

> Http URIs that will never usefully resolve do more harm than good.

This alone would be, in my opinion, a very good reason in support of a "undefined" scheme. What distinguishes linked data from any general graph database, is the "semantic" aspect or the shared meaning that data carries. "Undefined" just means "this data has a not well defined meaning" in contrast to all other data that does have a well defined meaning. Another example: if I'm importing data from a source that I don't control, I can either use a placeholder URI like example.org or mydomain.com that is deceiving and doesn't mean anything at all, or I could use a 3rd party domain like domain-of-the-source.com which is even worse because I'm declaring some unauthoritative information on behalf of somebody else.

 
 

Sent: Tuesday, November 20, 2018 at 4:11 PM
From: "David Booth" <david@dbooth.org>
To: public-lod@w3.org
Subject: Re: "undefined" URI scheme
On 11/19/18 8:19 AM, Hugh Glaser wrote:
> It sounds to me like all you need is a URI that doesn't resolve (but could at a later date if you wanted to add meaning to it).

While I agree with the advice given by Hugh (above) and others in this
thread, I think Laura has hit on a deficiency that current RDF practices
do not adequately fill. Blank nodes are second-class citizens in RDF.
They cannot be used as stable identifiers in follow-up SPARQL queries,
and as Laura pointed out, they cannot be used as predicates. And http
URIs often place too much of a burden on the RDF producer, who may not
be ready/able/willing to make the commitment to supporting a domain name
and making those URIs usefully resolvable. Http URIs that will never
usefully resolve do more harm than good.

I will have more to say as part of a much larger topic in the next few
days, but for the moment my suggestion to Laura would be in line with
what others have suggested: use a non-resolving http URI if you think
you can later make it usefully resolve; use a relative URI if it fits
your use case; or use a URN.

David Booth

Received on Sunday, 25 November 2018 16:13:12 UTC