W3C home > Mailing lists > Public > www-rdf-interest@w3.org > June 2001

RE: What to do about namespace derived URI refs... (long)

From: <Patrick.Stickler@nokia.com>
Date: Thu, 7 Jun 2001 11:17:17 +0300
Message-ID: <6D1A8E7871B9D211B3B00008C7490AA507958739@treis03nok>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:49 GMT