RE: Uniform access to descriptions

David Booth writes:

> That sounds more like the choices that a particular application
> might make -- not what the archiecture should say.

Fine.  I have no need to head deeply into this rathole.  I made the 
comment because the concern had been raised that even if the architecture 
is as clear as you suggest:

        If HTTP(x)=200 then x is an IR,

in practice there will be particular resources deployed that fail to 
conform to the architecture as carefully as they should.

I understood the concern to be that the Semantic Web is a rather formal 
reasoning system, and that there was concern about such mis-deployed 
resources leading to inconsistencies in the graphs of inferred triples. It 
seems to me that there are two (or at least two) ways of handling this: 

1) Have the definitions of the predicates account explicitly for the 
possibility that resources are misdeployed, as I suggested in my email.
 
-or-

2) Keep the definitions of the predicates simple, but deal with the fact 
that inconsistent inferences may be drawn when reasoning from triples that 
are inferred from status codes that have been used inappropriately.

You all are far more expert in the nuances of the Semantic Web than I am. 
If (2) is a practical option, then I'm all for it.  I thought I read 
earlier communications as suggesting that (2) would be impracticle, due to 
the inconsistences, and therefore I suggested (1) as a possible other line 
of investigation.

In any case, we both seem to agree completely that the >architecture< 
should say just:  "If HTTP(x)=200 then x is an IR";  the question is 
whether the triples we infer from HTTP interactions need to explicitly 
account for the possibility that the architecture is likely to be violated 
from time to time in practice.  Sorry for any confusion caused.

Noah


--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Booth, David (HP Software - Boston)" <dbooth@hp.com>
Sent by: www-tag-request@w3.org
04/11/2008 05:28 PM
 
        To:     "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>, 
"wangxiao@musc.edu" <wangxiao@musc.edu>
        cc:     Jonathan Rees <jar@creativecommons.org>, Phil Archer 
<parcher@icra.org>, Pat Hayes <phayes@ihmc.us>, "Williams, Stuart (HP 
Labs, Bristol)" <skw@hp.com>, "www-tag@w3.org WG" <www-tag@w3.org>
        Subject:        RE: Uniform access to descriptions



> From: noah_mendelsohn@us.ibm.com
> [ . . . ]
> So, I think the best we can do is to make a statement that says:
>
>         If HTTP(x)=200 then either
>        (a) x=IR
>          - or -
>        (b) the resource has been
>            deployed incorrectly
>          - or -
>        (c) x falls into an edge
>            case about which users
>            of the Web disagree

That sounds more like the choices that a particular application might make 
-- not what the archiecture should say.  The *architecture* can and should 
be clear:

        If HTTP(x)=200 then x is an IR.

However, a given application may choose to recognize that the architecture 
is sometimes violated, and hence may choose to assume that case b is a 
possibility, perhaps because of c.  But from an architectural perspective, 
the rule above can and should be absolute.

If indeed the URI owner erred, and meant to use the URI to denote a 
non-IR, and even published a URI declaration or other statements saying 
that the URI denotes a non-IR, then from an architectural perspective all 
that has happened is that the URI owner has published conflicting 
information:

 - as evidenced from the HTTP 200 response; and
 - as evidenced from the URI declaration or other statements.

>From an architectural perspective, it would be considered a URI 
collision:
http://www.w3.org/TR/webarch/#URI-collision


David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent the 
official views of HP unless explicitly stated otherwise.

Received on Friday, 11 April 2008 22:01:48 UTC