Re: Re[2]: Summary: Section 2: What does a URI identify?

> >
> >(Request for clarification - the rdf:ID attribute is of type ID in the
> >DTD or Schema?)
>
> No.  There is no DTD or XML schema for RDF.
> [...]

Think of rdf:ID as if

xml:idatts="rdf:ID"

One _can_ create a RELAXNG grammar for RDF in which case

rdfIDattr = attribute rdf:ID{xsd:ID}


>
>
> >Its clear that any situation where something works online but a
> >local(y accessed) copy suddenly breaks is a problem. The XML MIME type
> >RFC, by introducing a precedence of headers over the XML encoding
> >declaration, has a similar problem.

Right, which is why it would be good practice to qualify such RDF documents
with an xml:base if this works as currently suggested by RDFCore.

>
> I should be clear.  It is possible to write RDF/XML such that it does not
> have this problem.  Instead of rdf:ID, one can write:
>
>    <rdf:Description rdf:about="http://....">
>
> where the contents of the attribute is the full URL.  One can also use
> entities to reduce the amount of typing.  The problem we have is:
>
>    o some folks depricate the use of entities
>    o typing out the full URI is pretty tedious and unfriendly
>    o the rdf:ID idiom is common and used in other specs such as  daml+oil,
> PRISM and cc/pp.
>
> Thus the use of the rdf:ID idiom is preferred.

And likewise the <rdf:Description rdf:about="#foo"> idiom, e.g. see
http://www.daml.org/2001/03/daml+oil

>
> [...]
>
> >Lets not restrict this to "HTML vs RDF" but try to see a wider picture.

Right, one is an example of an application that tends to dereference URIs
and divides processing of the URI part and the fragment id part to
server/client respectively. The other is an example of an application that
tends not to dereference URIs and treats URIreferences as opaque names. From
where I sit, the two applications can coexist, and coexist well, as long as
we allow some flexibility.

Jonathan

Received on Tuesday, 19 March 2002 12:57:28 UTC