What is the URI of Truth?

...so we can check for some RDF triple linking our writings to it ;->>>

I've been reading with interest both threads "rdfms-resource-semantics"
and "What to do about namespace derived URI refs...",
and I would like to focus on a problem common to both,
which I could sum up with the following questions

- What is the URI of an abstract thing like Truth?
- Is such a thing a resource or "something else" (may be an RDF
resource)?
- Is such a thing identified by a URI or a URI reference?

There are 3 common proposition for identifying Truth
 (a) http://mydomain.com/path/Truth
 (b) http://mydomain.com/path#Truth
 (c) other_scheme:path/Truth

According to [1], "An http: URI (without fragment identifier)
necessarily identifies a generic document".
Hence this makes proposition (a) incompatible with the semantics of
http: URIs.


However, the assertion quoted above does *not* apply to proposition (b)
: fragment IDs can identify things outside the range of the base URI.
E.g. : RDF fragment IDs can be used to identify anything with an
identity.
There is a problem though : fragments IDs are dependant on the retrieved
mime type, i.e. on a *specific instance* of the resource identified by
the URI.
Note that this problem is not proper to RDF but to URI references :
URI references are by essence valid relatively to a given context,
but that context is not only a base URI, as suggested by RFC 2396,
that context is a specific instance of the resource identitied by the
base URI
(at least, when there is a fragment identifier).

A solution to that would be to improve the syntax of URI reference,
so as to be able to constrain the resource. E.g. (just an instant
suggestion)
 
 (b') http://mydomain.com/path#[type=text/rdf]Truth

Note that this works well with RDF fragments *only*.
An HTML fragment does not, AFAIK, identifies an abstract thing, but a
point in an HTML document.
An XPATH fragment identifies, AFAIK, a well-formed piece of an XML
document.
(if I'm wrong about those two, please let me know).


We still have proposition (c) which still seems the cleanest one :
why bother with http: URIs and fragments when RFC 2396 provides us
with an extensible mechanism for URIs? Let's design a specific URI
scheme.

Many people in the RDF community are not fond of proposition (c).
Their point is : it is very convenient to put some data on the HTTP
space,
and people willing to publish a new URI will rather use http: URIs --
hence proposition (b).
That does not bother me to much... as long as 
- the fragment bug is solved, and they do use an *RDF fragment* to do so
- there is a way to distinguish between the concept Truth in the RDF
version *and*
   the paragraph about Truth in the HTML version, using the constraining
mechanism sketched above.


So my beliefs are:
- Truth is definitely a resource (any thing with identity is)
- both a URI (like (c)) or a URI-reference (like (b')) can identify it

My questions are:
- does the constraining mechanism of (b') look good?
- do we need the constraining mechanism to be able to constrain
something else than the mime-type ?
   (I can not stop thinking of the language, the version, etc...
    looks like we will need something like RDF to describe that... my
head aches)

  Pierre-Antoine

[1] http://www.w3.org/DesignIssues/Fragment.html

Received on Thursday, 7 June 2001 12:33:35 UTC