[rdfweb-dev] advocating use of rdf:ID / rdf:about attributes
david.madore at ens.fr
Sun Aug 17 06:24:29 UTC 2003
On Sun, Aug 17, 2003 at 03:36:12AM -0000, Jim Ley wrote:
> My problem with using URI's for people, especially ones you expect to
> de-reference is that you need to keep track of URI's and people need to
> undertake to keep that URI resolvable, or at least uniquely identifying
> themselves for ever, that's not really practical, and it isn't a problem we
> have mbox/mbox_sha1sum etc. Then there's the problem that people will soon
> end up with lots of different URI's defining themselves, which complicates
> smushing, in that case which is the "official" uri, and should other people
Unfortunately, people also change email or have several mailboxes.
And, while they rarely change their name, they tend not to have a
"canonical" version of their name's spelling any more than they have a
canonical URI of their Web page.
We have several tangled issues here. One is how to find a common
namespace to refer to all possible people (and more generally, as far
as the semantic Web is concerned, all poassible RDF resources) without
centralized reservation and yet avoid collision. Another is how to
collect and gather (and possibly assign trust values to) information
The W3C never seems to have entirely made its mind as to these two
uses of URIs: acting as globally unique identifiers for resources, and
serving to locate said resources. In the real world we have different
kinds of labels for one or the other purpose (say, social security
numbers on the one hand and snail mail addresses on the other). In
the virtual world, the relation between the two uses of URIs is
obscure, it seems.
> I don't want to have a URI that denotes me (I am not a number, and I ain't
> going to Portmeiron whatever you do to me) and we certainly don't need one,
> I don't feel it helps much either to have one (because if we have one, we'll
> have many which doesn't help us any, we'll still have to smush on IFPs like
> now, it's just more data for people to get wrong.)
Maybe some people don't want to become RDF resources, either, but then
they'll just have to do without the RDF framework. But in that
framework, resources are identified using URIs: it is so much a basic
principle of the system that it is one of the very first sentences of
the W3C's *RDF Primer*, "RDF is based on the idea of identifying
things using Web identifiers (URIs)".
[Reading through the RDF semantics specification (<URL:
http://www.w3.org/TR/rdf-mt/ >) I actually find that it nowhere says
that two different URIrefs cannot be interpreted as the same resource
(section 1.3, condition 4 on interpretations does not restrict IS to
If you do not like identifying yourself by a URL, you can use a URN
instead (nothing prevents you from taking urn:x-people:joesmith or
some such). If there is a problem with RDF files being mirrored in
the wrong places, the xml:base attribute can be used to force
resolution of fragment identifiers (as per rdf:ID) from some base URI.
But insisting on using blank nodes to refer to people is only a way of
removing one equality constraint that could be used, and which is
precisely what RDF expects one to use, viz. referring to things by a
URIref. I really can't imagine what's better with using mbox_sha1sum
than with using some URIref.
Now I'll grant you that I was wrong to suggest automatically trying to
download the URIs in question, but that is not a reason not to use
them (indeed, URNs can be used, which certainly don't risk being
On Sun, Aug 17, 2003 at 03:55:26AM -0000, Jim Ley wrote:
> "David Madore" <david.madore at ens.fr>
> > This seems far less clumsy than using
> > foaf:name and/or foaf:mbox_sha1sum and misusing rdfs:seeAlso.
> Could you explain how you see rdfs:seeAlso is being misused?
I'm not claiming it is being misused in writing FOAF files. I'm
claiming it is being misused in reading FOAF files: it is wrong to
assume that the target of the rdfs:seeAlso property of any RDF
resource having rdf:type foaf:Person is automatically some
downloadable RDF file which will provide some description or some
information on said resource.
What is wrong is that FOAF puts some extra semantics on rdfs:seeAlso,
which is not in its namespace, so it (the FOAF specification) does not
have power to define it.
Imagine I wanted to be part of another project, say POAP (Pal Of A
Pal), with very similar goals and principles as FOAF, except that POAP
uses rdfs:seeAlso to point to a human-readable resource on a given
person. Now there should be no reason why I couldn't use POAP and
FOAF simultaneously, in the same RDF files - that's what RDF is all
about. And I'll be writing resources which simultaneously have type
foaf:Person and poap:Person - there's nothing wrong with that.
However, if rdfs:seeAlso is used in different ways by the two
projects, the crawlers will encounter problems, broken links, attempts
to parse HTML as RDF and whatnot. This is bad.
The rdfs:seeAlso property is basically mean to be used as target of
rdfs:subPropertyOf - and foaf should not use it directly, as it adds
semantics to it, but should create a new property in its vocabulary,
say foaf:seeRDFFile, with the semantics applied to it by the robots
and other FOAF tools.
> > If people wants to know more about Joe Smith starting
> > from Jane Doe's FOAF file, they should simply follow the rdf:about
> > link, which is the URI that uniquely identifies Joe Smith, globally.
> However that requires that the URI that identifies Joe will always be
> available to be de-referenced to get that more data, when Joe moves his foaf
> file to a new place, he'll also have to move his URI there, and changing the
> identifier for Joe is a lot more expensive an operation for everyone than
> changing a link to more information about Joe.
There's no escaping the fact that everyone who knows Joe has to keep
track of *some* property, or properties, that uniquely identifie(s)
Joe. And just about anything I can think of is liable to change.
> > so it is dubious for a robot, FOAF crawler of any kind, to
> > attempt to follow rdfs:seeAlso links systematically. Whereas if the
> > target has been identified by its own URI, as per an rdf:about
> > attribute, it is the obvious course of action to follow that link.
> I'd say it's currently a lot more dubious to assume resources in RDF are
> de-refrenceable to an RDF description, than it is to say rdfs:seeAlso is not
> worth following, if you want to help scutter developers narrow their search
> here, you can simply type the rdfs:seeAlso'd url to an appropriate type.
I'll grant you that it is dubious to assume that RDF
resource-describing (rdf:about) URIrefs are downloadable to an RDF
file (but <URL: http://www.w3.org/TR/rdf-concepts/#section-fragID >,
especially the first item in the enumeration, seems to imply that this
is not entirely crazy, though).
But then I claim that it is even more dubious to follow rdfs:seeAlso
and try to download it: after all, writing <rdfs:seeAlso
rdf:resource="http://www.somesite.tld/whatever/" /> is exacly
equivalent, as far as RDF is concerned, to <rdfs:seeAlso>
</rdfs:seeAlso>, so the URI is after all the rdf:about URIref of some
You are trying to tell me that if I write "the resource <URL
http://www.asite.tld/blah/ > has some vague relation (rdfs:seeAlso) to
the resource <URL: http://www.somesite.tld/whatever/ >" then it is
more reasonable to try to download http://www.somesite.tld/whatever/
than http://www.asite.tld/blah/ to get some information as to the
_first_ resource in question? Come now!
So the only way which makes sense is for FOAF to define a more
specific property than rdfs:seeAlso, that unambiguously specifies that
the target resource is a downloadable RDF description that should be
incorporated in the FOAF framework. But rdfs:seeAlso is too vague for
that. <URL: http://www.w3.org/TR/rdf-schema/#ch_seealso > clearly
states, "It may be possible to retrieve representations of O from the
Web, but this is not required. When such representations may be
retrieved, no constraints are placed on the format of those
David A. Madore
<URL: http://www.eleves.ens.fr:8080/home/madore/meta.rdf#dmadore >
More information about the foaf-dev