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

Patrick:

>
> taking XML Schema '#' concatentation
>
>   <"http://foo.com/foo.html#bar", "bas"> ->
> "http://foo.com/foo.html#bar#bas"
>
> (this surely violates the HTML MIME content type fragment syntax, eh?)

You are under the mistaken impression that XML Schema directs such
concatenation. XML Schema defines a mechanism to map _only_ certain types
defined in the XML Schema namespace. These types _all_ have IDs in the
schema document. Again and again and again, XML Schema does not define a
general mapping of QName to URI, nor does XML Schema generally _use_ URIs,
rather it uses QNames to specify types.

>
> taking RDF simple concatenation
>
>   <"name:foo:aja", "varovasti"> -> "name:foo:ajavarovasti"
>   <"name:foo:ajava", "rovasti"> -> "name:foo:ajavarovasti"
>
> (oops! now which is which?)
>
> There *is* no such automatic, reliable, consistent, and standardized
> method of deriving an RDF resource URI reference from a namespace
> and name pair.

The fact that this particular mechanism doesn't work does not indicate that
_no_ reliable method can be found. What are you suggesting?

> >
> > 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)
>
> But that doesn't solve a thing! You *cannot* impose any specific
> fragment syntax on any method of creating URI references from namespace
> and name pairs because that just further confuses the matter by
> suddenly having URI references that are not valid URI references
> according to the URI scheme or the presumed MIME content type
> yet have strangeness in them.

huh? this syntax encapsulates _all known fragment identifier syntaxes_
including: HTML, XML/XPointer.

>
> E.g. if that unified "namespace" fragment syntax would parenthesize
> names, one could get e.g. "http://foo.com/foo.html#bar(boo)" from
> "http://foo.com/foo.html#bar" and "boo". How is that any better
> than any other arbitrary, imposed syntax?
>
> I think (now) it is a great mistake to try to devise *any* scheme to
> create a URI reference from the composition of the namespace
> URI reference and name (even though I've been guilty of proposing
> just such a scheme myself recently ;-)
>
> > 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!")
>
> Nor should any of us. It's very icky! (for lack of a technical term ;-)
>
> > >
> > > 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"
>
> What! How? My namespace is "http://foo.com/bar.html#boo", *NOT*
> "http://foo.com.bar.html"!!! Just how do you determine that suddenly
> the RDF identity of the resource is a fragment of some URI fragment
> which is completely unspecified by the namespace URI fragment!
> Namespace URI fragments are 100% opaque. Sorry, you can't use logic
> to try to extract a *recognizable* prefix from one with which to try
> to come up with a logical URI reference for a resource. Thirty lashes
> with a wet noodle for you!

where are your _or any other such_ rules written down? The "resource" in the
RFC 2396 sense is _always_ determined by the URI part of the URI reference.
The fragment identifier is just a thingie that gets us part of a view on a
resource. Where did some sort of mystical metaphysics get attached?

Why is this different from absolutizing a relative URI reference given a
base URI? The algorithms for doing so are written down (RFC 2396), read
them.

>
> Try doing that with the following example:
>
>    urn:partax:(foo(bar)) + "bas" -> "urn:partax:(foo(bar))#bas" ???
>
> Nope! Why? Because partax names do not resolve to MIME streams. They
> are totally and entirely abstract (and if someone maps them to e.g.
> one or more URIs that *do* resolve to MIME streams, that is unspecified
> by the partax spec and thus unknowable by any application). So, the
> URI reference "urn:partax:(foo(bar))#bas" has no valid definition.
>
> It is *not* enough that RDF achieve a unique string. Until and unless
> the spec is changed, it must be a *valid* URI reference

 What is this "valid URI reference"? A string that conforms to the
production URI reference in RFC 2396.

, and validity
> requires both that there be an explicit and knowable definition, and
> that the URI reference conform to that definition.

err RFC 2396 has EBNF grammar ... good enough?


>
> If we ignore the issue of syntactic to semantic mapping, we
> can see that the rest of RDF is doing pretty well. E.g. if one
> has serialized RDF metadata that does not employ QNames for
> any statements, resorting only to fully specified resource
> URI references or literals, then everything is fine.

Such RDF serialization looking like what? How can you write down a triple in
RDF XML syntax (as opposed to the reification of a triple) without using a
QName for the predicate?

-Jonathan

Received on Tuesday, 12 June 2001 10:47:54 UTC