RE: What is the URI of Truth?

I prefer another alternative: there is no resource that
corresponds to the abstract concept "Truth".  The fact
that RFC 2396 doesn't itself make any constraints on the
range of resources that can be identified by Uniform Resource
Identifiers doesn't mean that it is sensible to use URIs
for everything. After all, RFC 2396 doesn't stand by itself,
but in the context of other applications that use URIs, procedures
for defining URI schemes (RFC 2717), etc.

You can't make an assertion about 'Truth', you can only make
an assertion about 'Truth as defined by resource X'. It's
useful to assert that 'Truth as defined by resource X' is
the same as (or different from) 'Truth as defined by resource Y'.


> -----Original Message-----
> From: www-rdf-interest-request@w3.org
> [mailto:www-rdf-interest-request@w3.org]On Behalf Of Pierre-Antoine
> CHAMPIN
> Sent: Thursday, June 07, 2001 9:35 AM
> To: www-rdf-interest@w3.org
> Subject: 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 13:18:23 UTC