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

RE: A proposed solution to the RDF syntactic/semantic mapping problem (long)

From: Jonathan Borden <jborden@mediaone.net>
Date: Tue, 12 Jun 2001 08:21:16 -0400
To: <Patrick.Stickler@nokia.com>, <www-rdf-interest@w3.org>
Message-ID: <001d01c0f33a$2db9d4e0$0201a8c0@ne.mediaone.net>


> It is unlikely that we wish to restrict the set of URIs which can
> act as signs of concepts to only those URIs which can be constructed
> by the concatenation of namespace URI and name -- simply because
> we use XML as our serialization mechanism.

Fair enough. Syntactically one might create a special form for the QName

{ns-urireference}localname where localname is null. Perhaps:


where the "_" localname is reserved for the null localname (and hence the
entire URI reference is represented by the namespace URI reference).

> I don't see how you interpret the use of QNames as not being
> the use of "namespace#name" forms, as that is the interpretation
> imposed upon QNames by XML Schema.

Not generally by XML Schema _only_ for the predefined builtin types whose
XML Schema definitions have an id="decimal" to assign the URI #decimal to
the type xsd:decimal.

The problem _in general_ is that the same QName may refer to:

an element def
an attribute def
a complex type def

at the _same time_ i.e.

<element name="foo"...
<attribute name="foo" ...
<complexType name="foo" ...

are all legal and refered to by "bar:foo" in the _same schema_ ... the URI

http://example.org/bar#foo doesn't refer to a particular definition ...

> Furthermore, QName prefixes only have meaning within a single
> instance (or within the scope of a single element if defined
> for that element) and therefore cannot serve as identifiers
> beyond such syntactic boundaries.

RDF uses QNames differently than XML Schema, agreed. I am just saying that
RDF uses URIs primarily (with the QName being a syntactic shorthand) but the
XML Schema uses QNames _primarily_ (with a URI only sometimes available)

> Thus any given namespace plus name pair in any given
> serialization does not
> constitute the common meaning that that syntactic form serves to
> represent, but must be mapped to that common "sign" associated with
> the abstract concept.

to me qname := <URIref,name> and on that basis is equally able to identify
'concepts'. The "name" _is_ somewhat redundant when one has a fragment
identifier, but one can compose a URI reference

<URIreference,fragmentid> -> URIreference

in a similar fashion to when

<absoluteURI,relativeURI> -> absoluteURI

The RDDL Java API handles such resolution.

> > >
> > > Claim 2: A name within a given namespace does not equate to a URI
> > > reference of that name within any content dereferencable from the
> > > namespace URI reference.
> > >
> > > I.e. "namespace" + "name" != "namespace#name".
> >
> > I suppose it depends on what you expect the "name" to reference.
> >
> > I consider this a bug not a feature.
> Eh? A fragment in a URI reference is specific to the MIME content
> type of the data that is accessible from the URI.

I strongly consider _that_ a bug. There very much needs to be a MIME type
_independent_ fragment identifier syntax (e.g.

That means that
> any ontology defined using signs which are URI references constructed
> by the combination of namespace URI and name with intervening #
> are bound to the syntax of a given MIME content type.

ugh, ugh, ugh (that's gorilla speak for "i really don't like that!")

> Furthermore, just how do you handle clearly broken URI refs such as
> the following:
> "http://foo.com/bar.html#boo" + "bas" -> "http://foo.com/bar.html#boo#bas"
> Eh?
> I again assert: "namespace" + "name" != "namespace#name"

assuming XML and fragment ids identify IDs within the document, the
composition works as such:

"http://foo.com/bar.html#boo" + "bas" -> "http://foo.com/bar.html#bas"

> >
> > This is a mess.
> And the mess is because, due to the fact that most folks equate URI to
> URL and URL to HTTP URL and furthermore sincerely wanting and needing
> that namespace URIs actually dereference to something recognizable and
> concrete, they assumed that "namespace" + "name" == "namespace#name"
> and that "namespace" is a URL and *not* a URL reference.
> And to make RDF work, added the hack "{URL}#" suffixing the '#' on the
> end so that the concatenation would create (presumably but unreliably)
> a URL reference that might be dereferencable.

but concat _still_ doesn't work see above.
> Yes. The real situation is a mess -- but only because the presumed
> automatic mapping of namespace and name to some combined URI does
> not in fact work for arbitrary namespace URI references and arbitrary
> URI scheme and MIME content type fragment syntaxes.
> We just need to add the explicit mapping mechanism that *does* work.

I completely agree.

> I don't think abandonment of URIs for RDF resource identity
> would be a good think (I actually think it would be catastrophic).

which "resource" are we discussing? the one identified by a URI, or the one
identified by a URI reference ... the same URI reference whose syntax is
MIME type dependent ... but the resource is not identified by dereferencing.
so where is it written down exactly _what is_ a "resource" as defined and
used by RDF ... certainly not the same resource as defined by RFC 2396 ...
what is this 'thing' we have placed on a pedestal?

> >
> > Why not "daml:equivalentTo" or "rdfs:isDefinedBy"?
> Firstly, the syntactic to semantic mapping (i.e. serialization
> to triples) is IMO the domain of RDF, not RDF Schema or DAML
> and therefore should be fundamental to the RDF spec and the
> solution embodied in every compliant RDF parser.

then the RDF spec needs alot of work, beyond simple mapping.

> One needs a construct such as the proposed rdf:Map element
> that binds the multiple syntactic components to a single
> resource identity. Until that is done, RDF Schema and
> DAML (or any other valid RDF ontology) are useless. Eh?

if you mean to say that a function rdf:Map(qname) is provided which gives us
a URI reference from a QName, then I agree, and as you suggest it is a very
nice idea to provide a case by case override of the default behavior.

Received on Tuesday, 12 June 2001 08:23:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:36 UTC