W3C home > Mailing lists > Public > public-sw-meaning@w3.org > March 2004

Re: Self-descriptive assertions

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Sun, 28 Mar 2004 18:59:51 -0500
Message-Id: <009AD992-8114-11D8-AEC8-0003939E0B44@isr.umd.edu>
Cc: public-sw-meaning@w3.org
To: Mark Baker <distobj@acm.org>

On Mar 26, 2004, at 3:59 PM, Mark Baker wrote:

> On Fri, Mar 26, 2004 at 01:05:00PM -0500, Bijan Parsia wrote:
>>>  AFAIK, it isn't.
>>> So you don't need a new media type.  I fully agree with DanC's
>>> assessment here;
>>>
>>> http://lists.w3.org/Archives/Public/www-webont-wg/2002Oct/0162.html
>>
>> Don't see how that helps with OWL. Quite the contrary.
>
> Sorry, I don't follow.

I don't agree with Dan's reasoning.

>  Dan concludes there that OWL doesn't need it's
> own media, and he does based on reasoning identical to my own (AFAICT).

Or rather, I don't agree with further conclusions you draw from it :)

> Anyhow, I should add that I don't know OWL; my agreement with Dan was
> purely a result of my agreement with the mechanism he used to come to
> his conclusion.  More in the response to Peter ...

To add a bit a fuel, there is no such thing as an inconsistent RDF (or 
RDFS) document (no negation). But there is such thing as an 
inconsistent OWL document. And yet, every OWL document is an RDF 
document.

>>> I understood "possibilities" to mean possibilities for processing.
>>> If he meant possibilities for interpretation of semantics,
>>
>> How can you separate the two?
>
> Here's an example ...
>
> A message sender might send some XHTML as application/xhtml+xml to a
> service, and that service could, say, print the number of lines in the
> file to a printer.  So even though the intended semantics of the sender
> was "Here's some content to interpret per the XHTML 1.0 spec",

I don't believe that is the intended semantics of the sender. Or 
rather, I don't believe it is *required* of the sender to so intend.

Part of this might stem from the extreme weakness of the mime *type* 
system.

> the
> recipient is free to treat it as plain text in order to count the
> lines.

And the sender might be sending it knowing that it is sending it to a 
line counting service.

Maybe this isn't even a matter of the weakness of the type system, but 
the fact that our examples (except my image one) all revolve around 
fairly simple type coercions.

Though, I don't see *why* I, qua sender, should be so sanguine that a 
gif of an rdf/xml document is "safe" from communicating a graph. After 
all, OCR is a legal operation on an image.

MIME Types, afaict, just *don't* provide the propositional attitudes 
you think they do. And I think that's a good thing. Headers seems a 
better place.

[snip]
>> So we disagree.
>>
>> There's also an Always/Usually issue. I think that Usually is fine, 
>> but
>> once you say Always then you've made your system way way way too 
>> rigid.
>> It's very hard to capture all the different implicit and explicit
>> agreements and understandings people come up with (sanely) and encode
>> in their programs. Hamfisting it just makes people either ignore your
>> restrictions or not use your system.
>
> I agree with your general point, though I'd opt for something a lot
> stronger than "usually" in this case since the value of the
> architectural properties obtained by adopting such a constraint is so
> great.

It's one of those trade off things, yes? If you push a constraint too 
hard, it sometimes breaks the system

>  But if you believe that what we've been discussing is one of
> those cases where out of band agreement is valuable, I couldn't
> disagree more.

Well, I believe a few things:
	1) the current set of specs don't mandate your constraint (in so far 
as I understand them)
	2) that fact doesn't bother me
	3) it's easy to impose variants of your constraint which I think 
aren't a good idea and hard to impose a good one
	4) there's no substantive harm in the current lack (this is sorta a 2 
prime)

Cheers,
Bijan Parsia.
Received on Monday, 29 March 2004 08:13:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:42:16 GMT