Re: Media types and assertions

>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.

Maybe. I don't agree on that. That is, at least, there is a clear 
sense of 'meaning' in which its not part of the meaning being 
communicated. And I don't think that ANY web protocols have ever 
attempted to deal with communication of any sense of 'meaning' which 
does encompass intent. What's the media type for making a promise in 
HTML? Or for being sarcastic?

>
>>  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.

First we have to agree there is a problem today that needs solving.

>
>>  >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 harmless (as long as you can still refer to the unmerged ones, 
which you could if they had names and were in documents with URIs)

>  (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?

But it is distinguishable, because all the URIs in the triples are 
fake, and don't refer to anything except the test examples themselves.

>  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

Well, OK, then I agree in cases like this its important to 
distinguish real data from fake or sample data. Moral: find a way to 
reliably distinguish them, and agree on it. That's not the same as 
the asserted/nonasserted distinction. I can make asssertions about 
fake data just as easily as about real data. I might, for example, 
want to positively assert that it is not real data.

BTW, publishing fake data is always a risky business on an open 
network. I'd advise your clients to just not do it at all, or to use 
a distinctive data format to do it in, so as to remove the very 
possibility of confusing fake with real data.

>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.

But we wouldn't be changing the *meaning*. The meaning is determined 
by the model theory semantics in the specs.  Nobody is suggesting 
changing that.

Pat

>
>Mark.
>--
>Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca


-- 
---------------------------------------------------------------------
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 Friday, 12 March 2004 14:27:12 UTC