Hi David,
"Slightly modified" data are modified data (one can't be slightly pregnant
either), and that means different information that shall not have the same
URI if you want the history recorded.
We deprecate the old information and make the next version effective on that
same dateTime.
The URI for Alice's address will indeed be the same: v:SOURCE ex:alice ,
what made you think that my proposal would lead to a different URI? It will
lead to another URI for modifed information about Alice's address.
We use this method to put on record the lifecycle information of a process
plant (e.g. an oil refinery, chemical plant), with tens of thousands of
objects in changing design and configurations.
But for the same token this method can be used for Patient Records, real
estate, air planes, etc.
Just have a peek in <http://15926.org>. But I won't try to convert you. I
rest my case.
Regards,
Hans
PS We don't have blank nodes whatsoever.
Besides, to your "multiple motivations for deriving URIs from natural keys
and properties" this: an old wisdom in data modeling is that you shall not
hide information in IDs.
Hans Teijgeler,
Laanweg 28,
1871 BJ Schoorl,
Netherlands
15926.org <http://15926.org>
-----Original Message-----
From: David Booth [mailto:david@dbooth.org]
Sent: vrijdag 21 augustus 2015 21:58
To: Hans Teijgeler; 'Paul Houle'; semantic-web(a)w3.org; 'Discussion list for
the Wikidata project.'
Subject: Re: Naming Conventions for URIs
Hi Hans,
You can (with high probability) generate unique URIs that way, but part of
the reason for generating them in a predictable way is ensure that if the
same or only slightly modified data is regenerated later, the URI for
Alice's address will still be the same. This is helpful because you might
already have other data that uses that URI, and you might merge new and old
data. When merging, it is helpful if the node URIs match.
Otherwise you wind up with (effectively) duplicate triples.
Incidentally, this is also one of the reasons that blank nodes cause
problems: they also result in (effectively) duplicate triples.
In short, I think there are multiple motivations for deriving URIs from
natural keys and properties:
- They can be mnemonic and hackable, which makes them friendlier for data
browsing and debugging.
- They are predictable, which is better for data merging.
- They are SPARQL friendly (as compared with blank nodes).
David Booth
On 08/21/2015 03:18 PM, Hans Teijgeler wrote:
David,
What about using Defining N-ary Relations on the Semantic Web
<http://www.w3.org/TR/swbp-n-aryRelations/> Use Case 3 ?
@prefix : <http://example/mine/address/> .
@prefix ex: <http://example/other/> .
@prefix v: <https://tools.ietf.org/html/rfc6350#section-10.2.6>
:T78F7E2EB48C044CCB5474C072F5573DB rdf:type :SnailMailAddress,
owl:Thing; # T+GUID
v:SOURCE ex:alice ;
v:FN "Alice Doe" ;
v:ADR "45 Park St, Shadyville, USA" .
Something like that.
Regards, Hans
Hans Teijgeler,
Laanweg 28,
1871 BJ Schoorl,
Netherlands
15926.org <http://15926.org>
-----Original Message-----
From: David Booth [mailto:david@dbooth.org]
Sent: vrijdag 21 augustus 2015 17:31
To: Paul Houle; semantic-web(a)w3.org; Discussion list for the Wikidata
project.
Subject: Re: Naming Conventions for URIs
On 08/20/2015 11:36 AM, Paul Houle wrote:
[ . . . ]
The production for a QName cannot begin with a
number so it is not
correct to write something like > > dbpedia:100 > > or expect to
have the full URI squashed to that. This kind of gotcha > will drive
newbies nuts, and the realization of RDF as a universal > solvent
requires squashing many of them.
I agree. And although (as Andy pointed out) this particular issue has
been fixed in SPARQL 1.1 and Turtle 1.1, last I checked not all tools
had been upgraded to those specs, so it still remains a problem in
practice. Personally, as a workaround when converting a natural key
to a URI, I always prefix the key with an alpha string that suggests
what it is. For example instead of the above I might write:
dbpedia:dbp_100
Another place that URI creation and management causes unnecessary
headache is when you want to mint a new URI that is relative to an
existing URI that you don't control. For example, suppose someone
else gives me a URI for Alice:
<http://example/other/alice> a foaf:Person .
My software wants to add some triples about Alice's address, such as:
<http://example/other/alice> v:address _:b
_:b v:street "Park St" .
_:b v:city "Shadyville" .
For SPARQL and other reasons it would be better to use a URI like
<http://example/other/alice/address> instead of a blank node _:b for
Alice's address, such as:
<http://example/other/alice>
v:address <http://example/other/alice/address> .
<http://example/other/alice/address> v:street "Park St" .
<http://example/other/alice/address> v:city "Shadyville" .
But since I do not control Alice's URI, I cannot safely mint a URI
that is relative to Alice's URI without the consent of the original
URI's owner. (Otherwise I would be URI squatting, which is bad
practice and
risky.)
Intuitively I would like the new URI to be somehow derived from
Alice's URI. I could mint a URI from my own URI space
<http://example/mine/>, by concatenating Alice's URI (after escaping) onto
mine, such as:
<http://example/mine/address#http://example/other/alice>
but now I don't have an easy PREFIXed way to write that URI in Turtle
or SPARQL. :( Furthermore, I have to be careful to properly escape
the original URI before concatenating it, because it might contain
characters that are not allowed in a fragment identifier.
In my experience URI allocation and management is one of the most
annoying practical aspects of working with RDF, as compared with JSON,
for example, where one can just put blinders on and ignore the need
for global identification. It would be great if some PhD student or
other creative person could figure out a good solution to reduce this
pain and make RDF easier for a wider audience to use. (New
conventions? A new RDF serialization? Extend RDF?) JSON-LD is a
good step, but still doesn't solve the problem.
David Booth