[rdfweb-dev] tangle of issues (URIs and global IDs,
informationretrieval, rdfs:seeAlso, WOT...)
danny666 at virgilio.it
Mon Aug 18 09:26:07 UTC 2003
> Now what about URIs used to refer to resources? They are not
> properties in the RDF sense (somehow RDF seems to have left out the
> obvious property which takes a literal value that represents a URI,
> and equals its subject with the resource identified by that URI), but
> no matter.
I don't think it's left out, its just a bit orthogonal to the model in which
resources are represented as nodes in the graph, properties as arcs. URIs
are the labels for the resources. I can't see any problem with defining a
property something like xxx:uriAsLiteral, but the most likely use for it
(comparing for equivalence) is already taken care of. I guess the work on
metadata embedded in URIs (can't remember where I saw it, sorry) might use
something like this. I've a feeling it might get a bit twisty with OWL, with
it bridging the parallel universes of properties and datatypes.
Certainly URIs are inverse-functional: two resources
> identified by the same URI are, as far as RDF is concerned, the exact
> same resource. (In real life this may be questionable in the presence
> of, say, HTTP content negotiation, but this is not about real life.)
> The question is now: are URIs functional?
> In other words: it is sure that two different resources cannot have
> the same URI, but can the same resource have two different URIs? Now
> Dan Brickley tells us - if I understand correctly - that the W3C has
> not resolved this question ("how many angels can stand on a pinhead?")
> - and certainly it has been very discreet on the question - and that
> FOAF prefers to avoid altogether the use of URI to refer to people for
> that very reason.
I can't find a ref, but I'm pretty sure that two (or more) URIs can refer to
the same resource, e.g.
Correct me if I'm wrong, but the reasons for FOAF avoiding the use of URI
are more pragmatic, in that the unique combined of properties of name, mbox
etc are likely to be easier to deal with than the whole issue of assigning
people with URIs. (FAQ anywhere?)
The problem would be complicated by the possibility that a person has more
than one URI.
> -> For all these reasons, I think the W3C will have no other choice
> but to acknowledge clearly the fact that it is possible (though
> perhaps not desirable!) for a pin head (resource) to hold several
> angels (URIs referring to it).
I think it has already been acknowledged.
> - When writing a FOAF file, always introduce an rdf:ID attribute on
> every person which this file describes "authoritatively". Make sure
> the file itself has a fixed base URI (at which it can be fetched), or
> use xml:base to specify such a fix URI. Do not introduce rdf:ID
> attributes on people for which the RDF file is not the authoritative
> description: rather, find the authoritative description (if it
> exists), and if it has an rdf:ID attribute, then in your own
> description use rdf:about to the base URI anchored by that ID; or if
> it has an rdf:about itself, just copy that rdf:about attribute.
> - If you discover some other file that refers to you with an rdf:ID
> attribute, use the owl:sameAs and daml:equivalentTo properties to
> identify resources. Possibly demand of the file's authors that they
> replace rdf:ID by the rdf:about URI that refers to you.
Hmm, I'm not sure how well this would work out in practice - someone (else)
without any authority can say that a file is authoratative.
> After that, people are free to accept or refuse to be referred to by a
There may be benefits in using URIs - this has come up before ;-)
> I'm not sure whether this remark counts as an argument in favor of the
> use of URIs to refer to people (it might even count against it). I'm
> not claiming this. But I wish to raise the issue to point out that
> things are subtle and delicate: already the RDF semantics are not
> obvious, but when combined in a web of trust, which means heavily
> modal logic, they become yet far more complicated.
You can say that again!
> I'll certainly take the RDFSchema Editor's word on what rdfs:seeAlso
> was meant for (I mean the contents of <URL:
> http://esw.w3.org/topic/UsingSeeAlso >). But, with due respect, I
> then think that the specification is extremely unclear. I would also
> like to know why it has not been deemed opportune to introduce two
> different properties, one that would just vaguely state that the
> subject resource has some relation with the object resource, and one
> that would actually imply that the object resource is an RDF file that
> is downloadable at least in certain circumstances and machine-parsable
> and possibly contains information pertaining to the subject resource.
> Possibly even a third relation, meaning that the information found in
> the target file should be trusted (just as much as the relation itself
> is trusted, that is) would be useful. The difference between these
> might not always be important, but the only reasonalbe policy seems to
> be, "when in doubt, use separate properties", and certainly we are in
But what makes the "trust this" relation trustworthy? Presumbably this will
all chain back to some source of statements that provides the authority. As
yet, I don't think we've got the mechanisms in place for this, although
things like Digital Signatures will presumably play a role. As you say, it's
not easy, and at present I suspect an ad hoc, Google PageRank style trust
through link consensus is probably the easiest way of handling statement
> And the prudent interpretation would be to introduce a foaf:foafFile
> property (with foaf:foafFile rdfs:subPropertyOf rdfs:seeAlso) on a
> foaf:Person, supposedly pointing to an RDF file that describes the
> person in question, and recommend using that property instead of
> rdfs:seeAlso. It might not be *necessary*, but it is hardly costly,
> and it seems the best course if only to put spirits at rest. Is there
> any reason *not* to do so?
I think this is what was suggested recently on list (as foaf:foaf). I reckon
it would probably be a good idea.
> In any case, some kind of foaf:foafFileTrusted property will probably
> be needed in the future.
Perhaps, but I think a lot of other infrastructure will be needed to use it.
One little future request - you covered quite a range of points here, it
would be easier to respond to them were they in separate posts (so separate
threads could develop).
More information about the foaf-dev