Re: non opaque primary topics

On 2013-05-08, Tim Berners-Lee wrote:

> The point about this is that all kinds of languages can talk about the 
> same thing in different ways. To get interopabiliity, though, you have 
> to stick to a limited set of local identifiers which will work in any 
> language.

Why use local identifiers at all?

The semweb works on the assumption that whatever URI is being talked 
about is globally unique. It doesn't say how you make it unique, but 
that's the basic invariant it expects.

What is being done here is that a) structure is being ascribed to a 
particularly common form of URI, and that structure is being taken 
advantage of, instead of the reference remaining an opaque (surrogate) 
key (in my own relational parlance). Then, b) once you have that 
structure, people are being asked to agree upon the particulars of that 
format, and to utilize it. Finally, c) it is being suggested that this 
should become a standard which lets you deduce programmatically and 
locally from a person's URI where to find hir "stuff". Essentially to 
derive some sort of URL from the corresponding URI.

I find this idea highly doubtful, and as long as I've known about RDF 
and the various forms of URIs, I've battled against them. Given that I 
happened to have access to a globally unique, guaranteed, naming 
hierarchy, I sidestepped the process from the start and went with 
calling myself by a legitimate URN, under the ISO OID tree. I've 
formally been called <urn:oid:1.3.6.1.4.1.12798.1.2049.1.497> within the 
semweb for some time now. You never need to worry about the XML syntax 
that way, including the qname hassle.

I think everybody who wants to name themself ought to do the same: latch 
onto some guaranteed to be unique branch of the full URI hierarchy and 
stick with their choice, or if they don't happen to have access to such 
a naming hierarchy even at the leaf level, then go with a randomly 
generated one within it (the random version of UUID will do the job) or 
perhaps a tag URI (Internet Law as of RFC 4151).

Then use some other, independent mechanism to show where your data is. 
Plain and simple, separate form from functionality. Maybe the mechanism 
could be just the :seeAlso one I used when I put up my files "ages ago". 
Maybe use so other, whipped-up predicate like "canonicalSource" and deal 
with the temporal implications elsewhere. Maybe do both, and if you're 
worried about security, sign your stuff.

But whatever you do, don't inpute structure into your URI's, or overload 
locators and identifiers. That's just bad practice, at least from my own 
relational DB perspective, not to mention the work of the IETF in 
finally generalizing URLs into URIs.

Not to mention that you'd cut me out of semweb if you did that, since I 
*am* an URN. :)

> Ooops! facebook's empty localid isn't allowed as a localid.

Those can be dealt with via :sameAs or some like mechanism. Sure, use 
these funky names as much as you like, but don't make it into a standard 
that they are expected, or that they should have any particular format 
which can be utilized. (Or if you do, at the very least make it sure 
that they work with the kind of architecture I was talking about above, 
too.)
-- 
Sampo Syreeni, aka decoy - decoy@iki.fi, http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

Received on Thursday, 9 May 2013 02:04:27 UTC