W3C home > Mailing lists > Public > www-rdf-interest@w3.org > November 2003

RE: RDF query and Rules - my two cents

From: Danny Ayers <danny666@virgilio.it>
Date: Thu, 20 Nov 2003 19:39:26 +0100
To: "Patrick Stickler" <patrick.stickler@nokia.com>
Cc: <www-rdf-interest-request@w3.org>, "Graham Klyne" <GK@ninebynine.org>, "Jim Hendler" <hendler@cs.umd.edu>, "Dan Brickley" <danbri@w3.org>, <www-rdf-rules@w3.org>, <www-rdf-interest@w3.org>
Message-ID: <BKELLDAGKABIOCHDFDBPCEKEEIAA.danny666@virgilio.it>

> Well, what happens when that description is available in RDF/XML,
> N3, N-Triples, XTM, HTML, etc.???
> Do we have a parallel set of mime types, such that for any mime type
> x/y we have x/y-description?
> Or do we just forbid any other encoding than RDF/XML?
> I don't find either option the least bit appealing.

It would only be needed for the description in RDF, so that only means
around 3 extra mime types. This has to be weighed against reconfiguring the

> It's really just a variant of the URI-suffix approach. E.g. append
> _META or such to the end of any URI to get the URI that denotes its
> metadata description.

Yes, as is MGET, except there the switch is shunted even further back into
the machinery. I agree this looks on the surface a more elegant approach,
but if the current web can be used without breaking anything, then I think
that should be the preferred approach. (I don't think anything gets broken
with the mimetype approach, the description can be considered just another
representation of the identified resource).

> > I'd be grateful for an example of how this is different with MGET, it
> > sounds
> > like there's something I'm not grokking here.
> >
> See above. I.e. a description can have multiple representations...

Ok, so perhaps the mimetype approach isn't the best, but I still hold out
hope for an approach that doesn't need lowish-level rewiring.

> Maybe the above comments, then, were useful to that end.

I'm certainly clearer about the issues, so thanks for that.

Received on Thursday, 20 November 2003 13:47:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:45 UTC