W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > June 2001

Re: Issue #rdfms-difference-between-ID-and-about

From: Aaron Swartz <aswartz@upclink.com>
Date: Wed, 06 Jun 2001 00:12:11 -0500
To: Dan Connolly <connolly@w3.org>
CC: w3c rdfcore wg <w3c-rdfcore-wg@w3.org>
Message-ID: <B74325D9.D3EC%aswartz@upclink.com>
Dan Connolly <connolly@w3.org> wrote:

>>  - ID claims to define an anchor ID, but it is not defined as an XML ID (and
>> possibly cannot, because of interaction with bagID[2]) and the editor of the
>> spec feels that it is not usable as such[3].
>> 
>>  - While ID is in the syntax, it is not specified in the model, which means
>> that an RDF document cannot be properly "round-tripped" which I feel is an
>> important goal.
> 
> I don't understand why any of these is a problem that
> needs solving. How about a test case to show why it matters?

For the first one is related to fragment issues, and referring to concepts
inside of RDF documents. Since RDF chooses a non-standard definition of
resource, its unclear how important this is.

> At what level do you expect to "round-trip" RDF?
> I expect it at the level of n-triples. rdf:ID
> is indistinguishable from rdf:about at that level.

Yes, that's my point. My argument is that if it has meaning, it should be
distinguishable in the n-triples -- i.e. n-triples should not lose any
meaning in the document. Thus, I want to clear up the meaning of rdf:id.

> re anchor ID: how is XML ID-ness relevant? anchor IDs
> are a MIME type thingy, not an XML thingy.

See my first point.

>> 1) Remove/Deprecate ID from the syntax.
>> 
>>    The Working Group could decide to remove ID from the syntax due to
>>    incompatibility/mistaken compatibility with XML IDs.
> What incompatibility?

URIs pointing to fragments of RDF documents (which can be sent as
application/xml) refer to an XML element. RDF wants to have them refer to a
concept.

>> 2) Allow ID to create triples in the model.
>> 
>>    Sergey Melnik has suggested[4] that ID create an isDefinedBy triple.
>> 
>>    Cons: Requires processors to change their interpretation.
>> 
>> I am willing to hear other proposals, but personally, I currently agree with
>> proposal 2.
> 
> I'm not against proposal 2, but I find it hard to justify
> as a correction to the spec. It also creates a dependency
> from RDF M&S to RDFS, where there is none now.

I justify the correction as such:

The spec talks about the "creation of a new resource". This is confused, and
what they really mean is x (creation of a resource's official description or
some such). X must be represented in the model to be useful to RDF
developers and we have chosen this triple to represent it.

-- 
Aaron Swartz <me@aaronsw.com>|           my.info
  <http://www.aaronsw.com>   |   <http://my.theinfo.org>
AIM: JediOfPi | ICQ: 33158237|  the future of news, today
Received on Wednesday, 6 June 2001 01:12:25 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:37:02 EDT