- From: Pierre-Antoine CHAMPIN <champin@bat710.univ-lyon1.fr>
- Date: 07 Jun 2001 18:34:54 +0200
- To: www-rdf-interest@w3.org
...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