W3C home > Mailing lists > Public > www-rdf-comments@w3.org > January to March 2004

Re: Media types and assertions

From: Pat Hayes <phayes@ihmc.us>
Date: Thu, 11 Mar 2004 11:07:11 -0600
Message-Id: <p06001f4dbc7646a14a03@[]>
To: Mark Baker <distobj@acm.org>
Cc: www-rdf-comments@w3.org

>  > Under the circumstances, I feel this is as far as the current consensus
>>  extends, and that we really don't want to delay registration of the MIME
>>  type any further.
>Thanks Graham, I wasn't aware of much of that history.
>I'm a bit confused about why there couldn't be concensus on this though,
>since in the recent discussions on this topic it seems that most folks
>are resigned to the fact that application/rdf+xml documents *do* assert
>the triples they encapsulate.

The problem is that asserting is an act, that has do be done by 
someone or something. It really does not make sense to say that a 
document asserts anything: rather, one has to say that the act of 
publishing a document (or some such locution) represents a commitment 
by the publisher or owner of the document to be regarded as asserting 
the content of the RDF in the document (or some such locution). This 
gets squarely into issues of 'social meaning' and Webetiquette and 
similar topics. We could not reach consensus even on whether or not 
to venture into this area, let alone to say anything authoritative in 

The resignation you speak of is real, and represents a kind of blurry 
emerging early social consensus that deployed RDF is usually being 
used to assert things, mostly. But there are some obvious 
counterexamples, such as test case files, and there are already 
proposed usage styles for RDF which depend critically on *not* making 
this assumption, such as the way that Euler encodes complex logical 
expressions using rdf graphs as expression fragments. Whether or not 
this early vague consensus will survive when RDF is widely used to 
handle web information in the real world, with all its consequences 
for security and possibilities for fraud and failure, remains to be 

>Would it help if those on the WG who didn't agree with this view were
>given the opportunity to create another RDF/XML media type which didn't
>assert triples?

Speaking for myself, I would be opposed to using media type to deal 
with this matter: media type is too blunt a tool to handle these 
issues. Even if it could be done, it would be a hack, and would 
pretty quickly cause harm. Right now, we can muddle along without 
needing to 'solve' this problem, which I think is the best thing to 
do until the issues become clearer and we all get more experience 
with deployed RDF/OWL applications.

>I think this is pretty important, and more important than getting the
>registration out (since people are using it, and I haven't observed any
>interop problems with it

Just wait. There will be.

>).  Ambiguity in media types is not a nice

There is no ambiguity.  The media type identifies the XML as being 
RDF, which determines how it is to be semantically interpreted and 
enables engines to handle it appropriately (parse it, draw valid 
conclusions from it, check it for consistency, etc. - all determined 
by the specs as they stand). This seems entirely appropriate for a 
media type: its like identifying HTML as being HTML. The content of 
some RDF - the proposition it expresses - is the same whether it is 
being asserted or not, and it is this content that the semantics in 
the spec determines.

Media type hasnt got anything to do with social contracts between 
sender and receiver. I can use HTML as wallpaper, and it is still 
HTML; similarly with RDF.  Whether it is being asserted or denied or 
quoted or whatever is another set of issues altogether, which has 
more to do with how people behave than with what RDF means.

Pat Hayes


IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes
Received on Thursday, 11 March 2004 12:07:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:15:22 UTC