Sergio:
do we want to create this (artificial) URIs?
Richard:
> You don't state any reasons against using URIs, you just say that you
> prefer not to use them. So please clarify: What do you gain by not
> introducing your own URI?
There are a few considerations...
One reason to be avoid creating artificial URIs is when we do not want
to raise expectations about longevity, maintainance, for them.
Another is when we don't want to confuse others about the 'real' / main
/ official URI, ie. we suspect the things have well known identifiers,
we just don't know what they are. Or perhaps have other reasons
(business, IP etc.) for not yet publishing the real identifiers.
These two cases can be addressed by providing some more minimal metadata
about the identifiers. For example, that everything beginning
http://tmpid.danbri.org/ is transient and may not be dereferenceable
after 2 weeks. Some pieces of POWDER might be re-usable here.
A third case (not directly Void-related), is where the entity being
identified is a Person or other entity that has associated social or
business sensitivities.
If I convince the world that http://ids.danbri.org/richard_cyganiak is a
fine identifier for the person whose personal mailbox is
[email protected], then I put myself in some position of advantage
(and responsibility) with respect to online information-linking
regarding that person. My webserver sees every de-referencing of the
URI. I see timing information, HTTP REFERER, HTTP USER AGENT, and more.
I also probably have some responsibility to publish accurate (non
libelous etc.) information. This covers both the nature of RDF claims I
intentionally publish (eg. there have been various cases like
http://news.cnet.com/2100-1025_3-5984880.html w.r.t. Wikipedia accuracy;
DBpedia re-users should bear this in mind). But it also covers things
like server security. If the server is hacked or otherwise compromised,
the descriptions served at the URI are at risk.
Also If the URIs are http: rather than https: because someone didn't
want to run SSL or pay an admin fee for a certificate check, the data
service is less reliable (faked wifi access could substitute bad data,
for eg.). For many cases on the Web, this is not a big deal. But when
you are claiming that some URI serves as a reliable "identifier" for the
thing it describes, there are extra layers of care and expectation to
consider.
The authenticity aspects of this 3rd case can probably be addressed, at
least partially, with digital signature. I have been poking around XML
Signature lately. The privacy aspect is harder. Parties who claim to be
publishing URI identifiers for entities such as people, businesses, or
content owned by others, should at least have very clear
terms-of-service and privacy policy documents. This is easier said than
done, particularly in large or legally cautious organizations. Or with
informal opensource-style projects for that matter.
In such scenarios, uuid:, tag: or description-by-reference
identification practices still have some value. But I agree, everything
goes much more smoothly when we have the luxury of a nice URI to join
the data with!
cheers,
Dan
--
http://danbri.org/
