Re: Self-descriptive assertions

On Mar 29, 2004, at 11:01 PM, Mark Baker wrote:

> On Sun, Mar 28, 2004 at 06:59:51PM -0500, Bijan Parsia wrote:
>> 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.
>
> It's critical to distinguish between what a recipient might *do* with
> a message, versus what a sender intends for the message to mean.

I so critically distinguish.

The main problem with media types is that they are insufficiently rich 
to provide much evidence of what a sender intends it to *mean*, 
depending on what it means for the sender to mean something with it.

Types usually constrain the possible operations you can do on data. I 
don't see where the current media type declarations specify *any* set 
of operations. They *may* enable some. But, as a sender, that I 
specifically enable some...well, it's probably not *enabling* rather 
than "encouraging", at best. Maybe "suggesting". I don't know.

>   The
> TAG media type document talks about "is" vs. "processing" for this
> reason, I believe; it's up to the sender to prescribe the "is", and
> the recipient to prescribe the processing.

There is no is, only do.

:)

>   The media type is what the
> Web currently uses to make this distinction, and I'm interested in
> trying to do things as currently-Web-friendly as possible.  If we
> determine that the drawbacks of the current approach are too great, 
> then
> we can look at trying to deploy something new.

As long as we don't think that this is prescribing that the sender is 
making the assertions possibly encoded in the document, I guess I don't 
care much. application/rdf+xml seems to allow a whole slew of possible 
operations, so I don't know what else you're expecting to infer from 
that type declarations. They look like hints to me.

>> 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.
>
> Hey, media types are already specified in the header! 8-)

Heh. Ok, that was weakly formulated.

At some point, the receiving agent must make a judgment as to the 
assertional status and provenance of *some* claims. The trick is how to 
do this and on what grounds. Media types are too pervasive and too 
weak. (Also, the current set do not allow for the distinctions we'd 
want to make, currently, and I don't see a lot of momentum in pushing 
things that way.)

>> [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
>
> If enforcing a constraint breaks anything, then it shouldn't have been
> a constraint in the first place! 8-O

I could buy that :) However, there are looser and tighter constraints.

>>> 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)
>
> I agree that the specs could do a better job at explaining the how and
> why of all this.  So without good guidance from the specs, I always
> think it's best to study the architecture of the system itself.  What
> you're hearing from me is the result of several years of study by yours
> truly, into self-description and the Web.

Great. Please point me to your papers describing your theoretical, or 
better yet, empirical results. I've been dying for some simulation 
experiments confirming or even just supporting various architectural 
claims about the Web.

I'm no snob, either. They need not be published or peer reviewed. I'm 
just interested in actual results, not handwaves, anecdotes (alone), 
mere assertions, or arguments from authority or wishful thinking.

I mean, most of your interlocuters (here) have been engaged in the same 
or related studies, even the ones with different conclusions. Hence, 
someone, somewhere is screwing up (maybe all of us). There's so much we 
just don't understand about complex systems, even the relatively simple 
systems like, oh, programs with thousands of lines of code, that it's a 
bit absurd to be too confident about strong and sweeping claims, 
particularly about a system that is more like an economy than a 
program.

To be crystal clear, when you make such an appeal to your own 
authority, I stop taking what you say seriously until such time as you 
supply some evidence and substantive argument for your positions.

>> 	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)
>
> Well, there is harm done anytime an architectural constraint
> (self-description, in this case) is relaxed, even if there's a very
> good reason for doing so.

Really? Wow. *every* time? *Any* constraint? No matter what the reason?

In any case, I deny that the constraint ever existed. I think the 
"constraints" you see are in fact emergent properties of the system, 
rather than imposed restrictions. Thus, the exceptions are critically 
worth preserving, rather than errors to be crushed. (I have no strong 
evidence for this, of course, but given how underconstrained the Web is 
by the specifications, it seems at least plausible.)

>  In this case, for whatever the gain (which
> I don't see, BTW), we're sacrificing some security, reliability,
> and visibility ... just off the top of my head.

The question is how much and whether there are compensators.

We are talking trade-offs, yes? So we always, well, trade *something* 
off.

> Anyhow, I think that pretty much wraps up everything I wanted to say,
> at least until there's a proposal on the table for how "assertions"
> will be handled.

Ok. Fine to wrap this up.

Cheers,
Bijan Parsia.

Received on Tuesday, 30 March 2004 09:04:06 UTC