- From: <Patrick.Stickler@nokia.com>
- Date: Thu, 7 Jun 2001 11:17:17 +0300
- To: sean@mysterylights.com, seth@robustai.net, Patrick.Stickler@nokia.com, www-rdf-interest@w3.org
- Cc: Ora.Lassila@nokia.com
> -----Original Message----- > From: ext Sean B. Palmer [mailto:sean@mysterylights.com] > Sent: 06 June, 2001 23:07 > To: Seth Russell; Patrick.Stickler@nokia.com; www-rdf-interest@w3.org > Cc: Ora.Lassila@nokia.com > Subject: Re: What to do about namespace derived URI refs... (long) > > > > [1] http://robustai.net/~seth/index.htm > > [2] http://robustai.net/~seth/index.htm#Truth > > O.K., TimBL has actually argued against using URLs as in [1] for > concepts, because they do represent retrievable entities according to > the HTTP specification. However, you *can't* say that about [2] > because it's a URI reference, and they just give a representation of > something that is defined in that URI based upon the content. It is a > part or view of the concept to which you are referring to. The "upon > the content" bit is annoying, and hence Jonathan Borden's nice little > proposal. > > So I'll give a "don't care" on the usage of [1], and an all O.K. on > the usage of [2]. Note that:- But, does the fragment URI ref [2] represent the concept of "Truth" or some definition or other expression of it, and is then the reference rather to some stream of bytes beginning at some anchor point named "Truth" within that HTML document instance. I.e. do we rather have something like: rdf:about="urn:name:robustai.net/myConcepts/Truth" rdfs:isDefinedBy="http://robustai.net/~seth/index.htm#Truth" or rdfs:seeAlso="http://robustai.net/~seth/index.htm#Truth" Why use a URL ref to define the identity of an abstract concept? If someone wants to make a statement about your statement about Truth, and you have not reified it yourself with a URN, then of course, all they can do is reference the statement using the URL ref, but that's a different matter. They are still just referencing the statement, not the abstract concept. I.e., the meaning of a URL ref should be consistently defined as "the content identified by the URL ref" and not as "some abstract concept that might be the topic of the content identified by the URL ref". This distinction is very, very important. Using URLs for namespaces or URI refs intended for abstract concepts misses this distinction entirely. > [[[ > The fragment identifier on an RDF (or N3) document identifies not a > part of the document, but whatever thing, abstract or concrete, > animate or innanimate, the document describes as having that > identifier. > ]]] - http://www.w3.org/DesignIssues/Fragment > > Which will hopefully be encoded in the MIME type specification for > RDF. Well that's all good and well for serialized RDF instances but says nothing about other serialization mechanisms. And furthermore, just how do we reconcile multi-schema instances which might have an RDF instance as the root document element but e.g. custom schema defined properties and values? E.g. given <rdf:RDF ...> <country>fi</country> </rdf:RDF> Where there is a schema (not necessarily XML Schema) that defines that all values of the 'country' property must be valid ISO 3166-1 two-letter codes. How is that information then syndicated into a knowledge base which is comprised of information for numerous sources, all of which agree on the use of ISO 3166-1 codes for country identity but all of which have different serializations and schemas? How do we achive unity in the identity of those ISO defined country codes. It goes far beyond the mechanisms of fragment identifiers for particular MIME content types. It should be that the schema which defines the serialization of "<country>fi</country>" provides all of the information necessary to map that literal value to the reification of the ISO defined country "Finland", but how do we define it in a way that ensures that we have consistency within our knowledge base? Either there must be a mapping from serialization to triples that is based on a fusion of knowledge of the instance and schema, with the schema providing scope and interpretation of instance content, or else RDF should provide a complete and total serialization solution that ensures consistent interpretation of instance content by use of RDF Schema statements -- which of course means that it must provide similar mechanisms for strong data typing and validation as per XML Schema if it is ever to be adopted widely for "real world" use. Cheers, Patrick
Received on Thursday, 7 June 2001 04:17:34 UTC