W3C home > Mailing lists > Public > www-rdf-interest@w3.org > September 2004

MGET Again [was: web proper names]

From: Jon Hanna <jon@hackcraft.net>
Date: Tue, 21 Sep 2004 15:40:52 +0100
To: <Patrick.Stickler@nokia.com>, <zednenem@psualum.com>, <daniel.oconnor@gmail.com>
Cc: <www-rdf-interest@w3.org>
Message-ID: <002701c49fe9$01c60ed0$0201a8c0@Lugh>

> But that doesn't mean that the representation you
> get back is a *description* of the thing denoted.
> The resource denoted could be, e.g., a particular
> ontology, and the RDF/XML returned is an expression
> of (representation of) that ontology, *not* a description
> of that ontology.
> Eh?

The RDF/XML is a representation of that ontology, and as such a
description of the terms it defines. There is no reason why the ontology
should contain a description of the ontology itself in the RDF/XML,
indeed this is both common practice and IMHO good practice. Indeed an
OWL ontology would at least describe itself as far as type goes.

For example the FOAF ontology contains the following triples:

<http://www.w3.org/2002/07/owl#Ontology> .
<http://xmlns.com/foaf/0.1/> <http://purl.org/dc/elements/1.1/title>
"Friend of a Friend (FOAF) vocabulary" .
<http://purl.org/dc/elements/1.1/description> "The Friend of a Friend
(FOAF) RDF vocabulary, described using W3C RDF Schema and the Web
Ontology Language." .
<http://xmlns.com/foaf/0.1/> <http://purl.org/dc/elements/1.1/date>
"$Date: 2004/09/01 15:37:56 $" .
<http://www.w3.org/2001/08/rdfweb/foaf> .
<http://xmlns.com/foaf/0.1/> <http://www.w3.org/2002/07/owl#imports>
<http://www.w3.org/2000/01/rdf-schema> .
<http://xmlns.com/foaf/0.1/> <http://www.w3.org/2002/07/owl#imports>
<http://www.w3.org/2002/07/owl> .
<http://xmlns.com/foaf/0.1/> <http://xmlns.com/wot/0.1/assurance>
<http://xmlns.com/foaf/foafsig> .
<http://xmlns.com/foaf/0.1/> <http://xmlns.com/wot/0.1/src_assurance>
<http://xmlns.com/foaf/htmlfoafsig> .

The only reason I can see for not including triples with the URI of the
ontology itself in
the ontology is that you don't care to describe it. If you don't care to
describe it in the RDF/XML that is the most important representation in
this case why would you bother to do so by supporting MGET?

As a more general best-practice issue, what does it mean to have an
RDF/XML representation?

I think there are two reasonable cases:

1. The RDF/XML represents the resource by describing it. This is how we
represent any non-document resource in any case; by returning a document
that describes it. After all, what else would the RDF/XML representation

2. The RDF/XML is a document that exists to describe something(s) else.
It is a document qua document. In this case we can simply make it
contain triples about itself, as in the FOAF ontology (and a large
number of FOAF files for that matter), if we care to describe it.

So in either case we can describe the resource in the RDF/XML
representation without doing anything unreasonable. The only case where
this causes trouble is if:

1. A representation is an RDF/XML document as in the example above (that
is, GET with Accept: application/rdf+xml will return a document about
other things).
2. The document cannot be edited (say, if doing so would break a
3. The admin/author actually cares about the document itself enough to
provide a description of it).
4. Someone else actually cares about the document itself to receive such
a description.
5. There is no other source of the information (in particular it isn't
duplicating the information in HTTP headers)

This combination seems like a rather narrow edge-case to me.

> Content negotation *cannot* be used to reliably
> accomplish what URIQA seeks to provide.
> And when you want a description in N-Triples, XTM,
> TriX, N3, etc. how will you ask for it, if conneg
> is already (improperly) busy doing something else?

The parenthecal "(improperly)" is where we disagree I think. Still, I
thank you for the CBD I think it's a very useful concept in deciding
what goes into an RDF/XML document (put in the CBD first, then think
about what else, if anything, is justified).
Received on Tuesday, 21 September 2004 14:41:03 UTC

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