Re: Options for dealing with IDs (RDF)

> So the RDF "ID" attribute was never an XML ID.

I think this was a mistake in the design of RDF.

(Of course there was and still is no way to tell an XML processor that
it's an id [that's the main subject of this thread], but it should
have been made clear that conceptually it was an XML id.  People can
and do make DTDs for limited vocabulary subsets of RDF/XML, and those
DTDs should [in a more logical universe] indicate that rdf:ID is an
XML id.)

> > Please note also, that in the case of a document with mime-type rdf+xml, ..
> .
> 
> application/rdf+xml (proposed)
> 
> > ... the fragment identifier #foo does *NOT* denote the element with ID 
> > attribute whose value is "foo".  It denotes the resource described by that 
> > element.
> 
> Yes.
> 
> Our current draft registration:
>   http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-01

This is another aspect of the same mistake, as people keep confusing
descriptive text with the subject of the descriptive text.

The RDF/XML ID should [IMHO] be used like other fragment identifiers
to point to a place in or section of some document instance (as in
HTML, XML, VRML, sound recordings, etc).  If RDF wants to talk about
the subject of the description there, it should do so explicitely.

For more details on how to do this with very little pain, see my
Disambiguating RDF Identifiers [1].

To tie this into the other two recent www-tag threads, this problem
really glares in content negotation and namespace documents.  What am
I going to fetch from some namespace address?  Maybe HTML (as in my
RDDL proposal [2]), but I'd also like to content-negotate getting the
same information in RDF/XML.  But with the currently proposed
application/rdf+xml media type, I can't do that (as the TAG recognized
[3]).  So the web architecture is broken here....

    -- sandro

[1] http://www.w3.org/2002/12/rdf-identifiers/
[2] http://lists.w3.org/Archives/Public/www-tag/2002Dec/0232.html
[3] http://www.w3.org/TR/2002/WD-webarch-20021115/#fragid

Received on Thursday, 9 January 2003 10:28:48 UTC