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

Re: Media types and assertions

From: Mark Baker <distobj@acm.org>
Date: Fri, 12 Mar 2004 11:55:03 -0500
To: Pat Hayes <phayes@ihmc.us>
Cc: www-rdf-comments@w3.org
Message-ID: <20040312115503.U2194@www.markbaker.ca>

On Fri, Mar 12, 2004 at 09:42:50AM -0600, Pat Hayes wrote:
> >So in those terms, I claim that whether or not an RDF document is
> >asserted is something the publisher of that document needs to make
> >clear via the messages they send.
> 
> But why do you claim this?

Because it's part of the meaning to be communicated.

I think we need to agree on that, or else we're just going to be
spinning our wheels here.

> That isnt part of the logical syntax, and 
> it seems to belong at a  layer above the propositional content.

Perhaps.  But no matter the layer, I claim that it still has to be in
the message.

> >  The RDF specs don't help you with
> >that, therefore, IMO, the media type registration(s) should.
> 
> Well, eventually I am sure that something will do it. I reserve 
> judgement about whether media types are the best way to handle it, 
> though. I think it will require something more complicated and 
> nuanced. It almost certainly will have to be involved with trust and 
> policy reasoning, for example.

Perhaps.  But until we have that new mechanism, I still need my messages
to communicate their assertedness, and the media type seems like the most
straightforward way to do that, since it doesn't require tweaking any
Recs.  We seem to disagree about whether media types are a long term
viable solution to this problem, but that's ok, since all that matters,
IMO, is that it's a solution today.

> >But my requirement (for my needs, at work) is simply that the
> >"assertedness" of a document be indicated somewhere in the message.
> 
> Can you say why you need this?

I just meant that we've adopted an architectural style that requires
self-descriptive messaging since we have requirements that deal with
future-proofing and multi party integration on a *very* large scale.

> Suppose you go with the flow and just 
> assume that any deployed RDF you find is being asserted. What will go 
> wrong?

How's that saying about "ass-u-me" go? 8-)

But seriously, it would be something like that.  If we write software
today which assumes assertedness, and a customer of ours deploys it,
but then five years from now that assumption doesn't hold and unasserted
data is published as application/rdf+xml, all sorts of hell could break
loose; asserted graphs would be merged with unasserted graphs (that's got
to be the geekiest definition of "hell breaking loose" ever 8-).  See
the next paragraph for a simple example of that.

> Even if your software believes things like the test cases you 
> are unlikely to get into serious trouble if you can legally parse the 
> RDF, since they all use fake namespaces so will not interact with 
> anything else.

What if the test case data is indistinguishable from real data?  My
customers are seismographic network operators, and the last thing they
want is to have their simulated earthquake data be interpreted as real
earthquakes by the rest of the network. 8-O

In short, I'm not claiming that I have all the answers to how all this
should best be done.  But I feel strongly that we need to avoid making
assumptions.  If everybody can assume that the triples in an RDF/XML
document are asserted today, then let's put that in the media type
registration, since that seems easiest.  If later on we want to make it
so that RDF/XML documents are not necessarily asserted in whole or in
part, then we'll just have to register a new media type.  That's far
better, IMO, than the alternative of retroactively changing the meaning
of legacy application/rdf+xml documents because an assumption changed.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Received on Friday, 12 March 2004 11:53:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 18 February 2014 13:20:08 UTC