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

Patrick,

>
> 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
pair

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

foo:_

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 ...
sigh.

>
> 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.
http://www.openhealth.org/RDDL/fragment-syntax)

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.

-Jonathan

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