See also: IRC log
jar: All you can observe are representations of that document.
<Stuart> zakim ?? is me
dbooth: If you view an IR as a function from request inputs to representations, then you can never be sure that a slightly different request input wouldn't return a rep that contains the word you were looking for. So without some other knowledge, it is not possible to definitively say that an IR does *not* contain a particular word (i.e., that it does *not* have a rep containing that word).
jar: Then what if some metadata says that the IR does NOT contain a word, but you do a GET and the rep does contain it? Which is wrong?
timbl & dbooth: The metadata is wrong. The 200 response is authoritative.
jar: So there is some info you can determine from a GET, but there's other info that is not determinable by GET experiments.
timbl: There is an HTTP VARY header that can say NONE, meaning that it is not affected by any of your headers, but not sure it also applies to time.
<jar> timbl: We can consider the Link header to be part of the protocol
<jar> timbl: We don't define what gets asserted, we only define what triples are implied. [? did scribe get this right?]
jar: when you have multiple
sources of info there is redundancy, it should be
consistent.
... So the info that is provided via the LINK header MUST be
consistent with the 200 response.
<timbl> We don't generally prescribe what agents do, we define functions and mappings and give then names so people can in terms.
jar: The AWWW had a clear answer
about authority: the URI owner gets to say the meaning of the
URI.
... But if you're the URI owner and you serve info then the
info you serve MUST not be inconsistent.
... And if it is inconsistent then it's like violating the
protocol.
dbooth: No, it's a little different from violating the protocol. The protocol is robust wrt assertions in document that are not true.
tim: It's like trying to write a philosophy of the architecture, that I think is beyond the job of defining the arch. We could discuss it over lunch though.
<jar> timbl: The protocol is something you buy into, and the RDF hall of shame is not buying into the protocol.
<timbl> Timbl: When you run a server which is a negative test case then it is not pretending to be running the protoocl, it is deliberately not running the protocl properly.
jar: There are different schools
of philos of mathematics. Three schools: intuitionist and
formalist. Had an argument w Pat Hayes about what RDF was
about. The app he had in mind for RDF was expert systems. I
would make an analogy between that and a formalist school: The
value is in the graph you built, and the relationships so fully
specify your domain that they're the whole story.
... Any connection to things in the world is either obvious or
.... , well it's unproblematic.
... Contrast this w the other school that RDF is for
communicating about real things, and even if RDF weren't there
you'd still communicate about them. The value is in the
rdf:comment properties, not in the graph itself, because the
graph itself doesn't tell you much.
<timbl> jar: Two ways of using RDF, whether the value is in a big ontology (taxonomy) , and where the ontology (schema) is very small but the vlue is in the instances.
<timbl> Timbl: i would not say one or other was more about "real things".
jar: David and I had an argument
a month ago: you can make an ont w terms like "resource",
"rep", "authoritative", whatever. And you don't have to worry
about what those terms w mean because the ontology w give them
meaning. In that sense the ont is incomplete because it hasn't
beeen tied to the real world.
... A different approach is anal to the intuitionist apprach in
math, in which ont terms have defs that are good enough that
they allow indep observers to argue about the truthe of
assertions made w those terms.
... So in a med ont, TIA (tranient ...attack), two physicians
can argue over wheather a patient has that condition. It's
grounded in reality.
... Are we talking about making an ont for phys? Or a formal
ont? I feel like the HTTP spec doesn't need to ground
everything in reality because it's a formal comm mechanism --
just says what the comm is, not what it means.
<jar> timbl: heavyweight vs. lightweight ontologies
tim: These two ways of using RDF
we've noticed before. Some call them big heavyweight versus
light.
... If you're using OWL it actually contains the value, but
that doesn't mean it's not about real things, if somebody has a
headache and it specifies somethign about it.
<jar> timbl: 'A headache is about a head' [lightweight ontology] can be about the real world
tim: Other example is bank statemnets. The ont is just the schema for tying it into the real world.
<jar> timbl: They're just ways of using RDF
tim: Thesee things connect
together, they're not different philosophies, they're just
different ways of using the tech.
... They
<jar> timbl: The large ontologies area always chaning, the small ones are stable
tim: They're both about the real world.
jar: The point about it being a matter of degree is to the point. Where do we draw the eline between an acceptable def and one that isn't good enough for an app?
tim: They're design patterns.
<jar> timbl: Large & small are two design patterns
<jar> timbl: The http headers form a lightweight ontology
tim: You can define an ont linked to HTTP headers, and hence to the standards, etc.
<jar> timbl: There is a standard process for defining what the http headers mean - system for arguing is formalized
<hhalpin> I tend to think that usually "natural language" comments, i.e. rdf:labels, are *necessary* to map the terms to the world using natural language.
<jar> dbooth: Let's ground in real artifacts, code etc
harry: How much attecntion should
be paid to the comments and labels? A lot! You need something
besides the abox data itself.
... Shadi said they haven't had any help or input from SWIG
jar: I agee w much of what Tim
said, though I'm not sure i would call it Large or Small. How
much of the meaning is determined through definition and how
much through use?
... In natural language, everything is defined through use.
Tim: It's by definition.
dbooth: I agree, it's by def, not by use.
jar: defs vary in quality and
specificity.
... e.g., "resource" and "rep" in HTTP 1.1 spec. You can sort
of figure out what they mean by reading the spec, and that's
okay, and if they're used implicitly in a large number of
places then you don't need such careful def.
... But http 1.1 is not an ont. You cannot tell indepe if
something is true or not. The RDC doesn't say how to determine
if a particular resource is an IR.
Tim: The http spec defines
messages sent, state transitions, etc. The only area in which
it's weak is in describing the philosphy and how it fits to the
AWWW, because it was taken for granted.
... Whereas the difference between a cough and a cold is much
fuzzier.
dbooth: I agree it is a relevant question. But I think we can make the most progress by looking at real code, examples, etc.
<jar> timbl: The medical area is fuzzy compared to http (e.g. resource, representation)
harry: One exmaple is the
owl:sameAs exampel. It's a clear case where the community of
web hackers doing linked data is using a term that is not
precisely in conformance w the def of the term.
... It seems that these problems w terms always happen when
different communities meet. One community has an intuitive
understanding of the term, but another community doesn't. They
don't share the same background assumptoin, more dialog is
needed.
<timbl> TimbL: Got an example of improper use of sameAs?
dbooth: should we give more concerted feedback on http://www.w3.org/TR/HTTP-in-RDF/ ?
tim: we made a wiki page last time to collect comments
<jar> http://esw.w3.org/topic/AwwswHttpVocabularyInRdfComments
dbooth: Looks like we never got our minutes out from last meeting.
<jar> ACTION on jar to recover minutes from last time
<trackbot> Sorry, couldn't find user - on
<jar> ACTION jar to recover minutes from last time
<trackbot> Created ACTION-11 - Recover minutes from last time [on Jonathan Rees - due 2008-10-21].
dbooth: Why did they use rdf collection for #MessageHeader?
<timbl> Headers ar ein fact UNordered in HTTP
<jar> http://www.w3.org/TR/HTTP-in-RDF/
dbooth: I'm looking in the RDF in http://www.w3.org/2006/http#
<jar> t = 10:00
<timbl> There are two separate levels to model a header in 2.6
<timbl> They are modeling two levels at once
tim: A MesageHeader has properties. One is that it has a name. Another is that it has a value (fieldValue), w a microformat. Also is the parse tree from the fieldValue. So HeaderElement is a ...(scribe missed)...
<timbl> Which i s not bad ... useful to be able to express either
Stuart: I won't be hear in two weeks.
<Stuart> "Parsetype=Collection" generates and ordered list... so their model is maintaining the order of headers as they were observed
<jar> 2 weeks is ISWC conflict
<jar> rrsagent. pointer
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/by experimentation/by GET experiments/ Succeeded: s/te/etc/ Succeeded: s/make/made/ Succeeded: s/observe/observed/ No ScribeNick specified. Guessing ScribeNick: dbooth Inferring Scribes: dbooth Default Present: DBooth, Jonathan_Rees, TimBL, Stuart, HarryH Present: DBooth Jonathan_Rees TimBL Stuart HarryH Got date from IRC log name: 14 Oct 2008 Guessing minutes URL: http://www.w3.org/2008/10/14-awwsw-minutes.html People with action items:[End of scribe.perl diagnostic output]