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

> -----Original Message-----
> From: ext Sean B. Palmer [mailto:sean@mysterylights.com]
> Sent: 07 June, 2001 18:43
> To: Patrick.Stickler@nokia.com; seth@robustai.net;
> www-rdf-interest@w3.org
> Cc: Ora.Lassila@nokia.com
> Subject: Re: What to do about namespace derived URI refs... (long)
> 
> 
> > > [..] for as long as URLs are around and people can use
> > > them in RDF, they will be used - you can't stop that from
> > > happening, and rightfully so.
> >
> > Well, I'll agree that it's going to be darn hard if not impossible
> > to stop, [...]
> 
> It's going to be impossible. How are you going to stop people? By
> issuing a decree? The only way to get people to stop is if the entire
> world (or a good percentage of it at least) agree that using a URI
> reference who's base just happens to be a URL is wrong for identifying
> arbitrary concepts, and as that is clearly not the case, it isn't
> going to happen.

The "fix" will come when folks realize that a location and a name
are two different things, and though you can use a location as a name,
unless a significant intersection of common names exists, then there
is no interoperability between SW agents.

> > But will they work for everything they have to work for
> > in the SW?
> 
> It depends what you mean by "the SW". If you mean a machine
> processable environment built on top of RDF and URIs that identify RDF
> resources, then yes, I think that is a fair assumption to make.

The crux of the problem is not whether URLs and URL refs can be made
to work as names -- obviously they can -- but whether those names
are sufficiently persistent and universal to be used in all contexts
and for all methods of interchange, particularly and especially in
the case of namespaces.

> > But references to concepts cross-media is essential to the SW!
> 
> Only if those concepts are grounded in the media themselves, and if
> so, then you should be able to model that quite well. Here is a model
> of an XHTML <title> element, by DanC on the RDF IG IRC channel:-
> 
>    { :r1 a http:Reply; :from :r2; :content :bytes.
>       :bytes :xmlParseAs :dom;
>      :dom [ :xpath "html/head/title" ] :t }
>    log:implies { :r xhtml:title :t }.
> 
> You can do this sort of thing because RDF can say anything about
> anything. The power comes from the lack of bottleneck contraint rules.

Sorry, I don't yet grok the new (unofficial) syntax. Can you give that 
in the XML syntax? Thanks.

> > How do folks expect intellegent agents to trully communicate
> > if there are no reliable mechanisms for cross-media references
> > to shared concepts?!
> 
> Use a URN if you want. Just don't (attempt) to force people who have
> build software that can grok any type of URI/URI-Reference as an
> identifier for an RDF resource to grok some subset of URIs. That's
> just rediculous.

Well, as RDF does not dereference its URI refs, but only uses them
as unique strings -- trusting the definition of and mechanisms
relating to URIs to ensure that uniqueness, then SW apps need not
grok any kind of URI whatsoever, eh?

Just because there is e.g. a rdfs:seeAlso or rdfs:isDefinedBy
property that points to a URI doesn't mean that any SW application
has to either be able to dereference that URI or understand its
content (presuming its a URL).

> > Furthermore, who says what the "official" standard URI ref
> > for the ISO 3166-1 language "Finland" is? The only official
> > ISO specification is in print only. All online (URL referencable)
> > definitions are unofficial -- and they vary from HTML to text
> > to CSV, etc.
> 
> I fail to see your point here.

See my discussion and example in my recent reply to Sandro on this.

> [...]
> > > Does this mean that the RDF, RDF Schema, DAML,
> > > Dublin Core, FOAF, DCTypes, EARL, Annotea and
> > > so on namespaces are broken?
> >
> > IMHO, yes.
> 
> Maybe you should try using the tools, and then reply again. Has the
> Annotea annotations server "broken" just because you say using URLs
> with FragId is wrong?

As I mentioned above, so long as all of your rdf:about strings are
unique in a given context, regardless of what they are, then there
are no problems.

The problem does not exist once you have complete URIs.

The problems are in mapping from various serialization schemas
to RDF triples in a manner that does not require custom programming
at ever interface. E.g. precisely how does one relate xml:lang="en"
to the ISO 639 language "English"? Or the value in <format>text/xml</format>
to the IETF RFC 2045 "text/xml"? 

This original discussion arose from the fact that there are no
explicit and reliable mechanisms in XML Schema (or DTDs) for
defining user-palatable serializations of metadata which would
be parsed by an RDF parser into a consistent unified representation
for names. This applies not only the mapping of PCDATA controlled
values (such as "en" or "text/xml") to abstract resources reified
by a URI rather than a Literal in the RDF knowledge base, but also
to the mapping of "namespace" + "name" to the same URI irregardless
of serialization encoding (as each serialization/schema solution may
apply different methods for constructing complete URIs from QNames.

This then flowed into the general discussion about should a URL identify
a namespace, as that then imposes a particular MIME content type
fragment syntax on the URIs identifying the concepts within that namespace
*because* any given schema processor/parser, etc. is going to attempt
to construct sub-names within a namespace by joining the namespace URI
to the name in some fashion.

So, if I decide that the namespace for my ontology is a URN (a *real*
URN that never resolves to a data stream), then it is in fact completely
undefined how e.g. an XML Schema or RDF parser should map the element 'foo'
<foo xmlns="urn:foobar:1.0">bar</foo> to its proper URI in the RDF
knowledge space. It could be "urn:foobar:1.0/foo", or "urn:foobar:1.0#foo"
or "urn:foobar:1.0@foo" or "urn:foobar:1.0(foo)" because the syntax
for sub-elements of an ontology defined for a namespace is *not* consistent.

The pervasive use of HTML URL refs for names and the fact that tricks such
as xmlns="http://foo.com/foobar#" to get "http://foo.com/foobar#foo" which
just happens to be (lucky us) the actual name of the abstract resource
does not mean that there is not a significant and critical problem with
how names for abstract resources and their common representation with
regards to namespaces are defined, or the use of locations/addresses as
names for abstract resources confuses an essential distinction between
identity and location! Eh?

Patrick

--
Patrick Stickler                      Phone:  +358 3 356 0209
Senior Research Scientist             Mobile: +358 50 483 9453
Software Technology Laboratory        Fax:    +358 7180 35409
Nokia Research Center                 Video:  +358 3 356 0209 / 4227
Visiokatu 1, 33720 Tampere, Finland   Email:  patrick.stickler@nokia.com

Received on Friday, 8 June 2001 04:26:32 UTC