W3C home > Mailing lists > Public > www-rdf-interest@w3.org > June 2001

Re: rdfms-resource-semantics

From: Aaron Swartz <aswartz@swartzfam.com>
Date: Fri, 08 Jun 2001 11:39:08 -0500
To: Lee Jonas <lee.jonas@cakehouse.co.uk>, Brian McBride <bwm@hplb.hpl.hp.com>
CC: RDF Interest <www-rdf-interest@w3.org>
Message-ID: <B74669DB.D7F0%aswartz@swartzfam.com>
Lee Jonas <lee.jonas@cakehouse.co.uk> wrote:

>> Err, that thousands of RDF documents refer to URIs with fragment
>> identifiers. Not to mention the tons of deployed namespaces that use them.
> Oh, that kind of backward compatibility ;-)  I was only thinking of RDF
> processors, not RDF data.

Yeah, well... Perhaps we can invent some script to convert this "legacy"
data in a backwards compatible way... Aha:

http://blogspace.com/rdf/quickfix/?uri=(uri-here)&fragment=(fragment-here)

Now we just get someone to write an XSLT to convert RDF files and we're good
to go!

> This does not rule out making this kind of change... please here me out:

But seriously, I really do want to make this change.

> Their use for describing non-RDF 'resources' could be deprecated.  RDF
> 'resources' would still have to be fragments because of the
> 'schema-follows-data' style syntax (i.e. mapping qname -> URI reference in
> the PropertyElt & TypedNode productions).

I don't see why they have to be fragments. Dublin Core deals with this just
fine doing:

    xmlns:dc="http://purl.org/dc/elements/1.1/"

and with my fix, we can do:

xmlns:rdf="http://blogspace.com/rdf/quickfix/?uri=http://www.w3.org/1999/02/
22-rdf-syntax-ns&fragment="

> Now, RDF resources only occur in RDF documents, so the application/rdf+xml
> mime type could define rdf fragments for this mime type accordingly.

That's an interesting point -- we can define the meaning of fragments as a
mapping into URIs like the one I show above. That could work quite nicely...
Thanks for the idea!

-- 
[ Aaron Swartz | me@aaronsw.com | http://www.aaronsw.com ]
Received on Friday, 8 June 2001 12:40:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:49 GMT