David,
What about using Defining N-ary Relations on the Semantic
Web 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
-----Original Message-----
From:
David Booth [mailto:david@dbooth.org]
Sent: vrijdag 21
augustus 2015 17:31
To: Paul Houle; semantic-web@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