A page upon which to get

I'd like to get us onto the same page with regard to basic approach.
Here is my attempt, which is about as neutral as I know how to make
it, to articulate just what that same page should be. I know that if you
substantially disagree you will speak up...

   - We're having a hard time getting past terminology and philosophy
     and toward making RDF statements.  This was expected; the
     discussion was stimulated by efforts to write RDF and inference
     rules.  A bit of time on foundations seems to be in order.  We
     should attempt to agree to disagree when necessary, so that we can
     move away from preliminaries and forward to RDF.

   - 'Resource' is not a category
     . TAG members seem to disagree on the meaning of 'resource'...
     . but what it means, or whether it's a category, doesn't matter for
       AWWSW since the question does not bear on AWWSW's goal of
       producing RDF
     . 'thing' = rdfs:Resource is proposed as the uninformative
       'anything' category.  rdfs:Resource is not (necessarily)
       the same as 'resource' sensu AWWW, RFC2616, or Fielding
     . Other classes will be harvested or synthesized as needed for
       AWWSW purposes

   - 'Representation' is not a category
     . We will not attempt a 'representation' class for use in RDF
     . Can we agree that there should be RDF-expressible relationships
       (including perhaps 'something:represents' and 'log:uri') among  
URIs,
       the things we retrieve upon doing GETs, and the
       things named by the URIs, without immediately going into the
       details of what the relationships are?
     . If so, it will be useful to have a category (maybe more than
       one) for the things we retrieve, the things that potentially play
       the role of "representation".  Tim has proposed
       http:ResponseMessage.  JAR has proposed rfc2616:Entity.
       This distinction is not important and consideration of the
       choice can be postponed.

   - Recording the 'facts' of an HTTP interaction (e.g. what the status
     code was) (a) is not very interesting, (b) does not qualify as
     "inference", (c) is necessary for the expression of  
prerequisites to
     rules of the sort to be explored by AWWSW.  When we write down
     these 'facts' we may give URIs to things that we need to talk  
about,
     such as messages and entities. Ordinarily these things wouldn't  
have
     URIs. It doesn't matter much whether these
     things are "information resources", except insofar as this bears
     on the issue of defining "information resource", which is a  
different
     question.

   - Substantial inferences from HTTP interactions are subject to the
     agent's trust filter.  (JAR says: Some questions of interest to
     such filters are: Is the site I'm talking to following RFC2616? Is
     it following web architecture (AWWW)?  It is important to
     understand what fallacies could arise if the agent thought "yes"
     when the reality was "no".)

Some of the major issues hanging.  Punt if (and only if) possible.

   - What class is the range of "represents" and how should it be  
defined
   - What is the role and import of contradictions in the AWWSW project

Proposed path forward

   - Activities in progress and to be continued: (TimBL & David Booth
     have contributed)
     . Inferences & contradictions from headers.  (To what extent is
       trust required in order to make these inferences?)
     . Inferences & contradictions from content.  (Factual statements
       about content are uncontroversial; belief in interpretations of
       what the content "says" are necessarily subject to trust policy.)
     . Specification of what it means to be a well-behaved
       (trustworthy) server

Received on Sunday, 3 February 2008 15:49:28 UTC