Architecture of the World Wide Semantic Web -- 05 Feb 2008

Representations

<jar> http://esw.w3.org/topic/AwwswAnalysis

<jar> http://w3.org/mid/0539149A-F4E6-4B34-88FE-E7E711CD2F07@creativecommons.org

jar: Last mtg there was discussion about whether a representation could be a resouce.

That discussion was on the list.

timbl: Alan asked what happens what happens if I save a rep in a file. I don't think we should be distracted by that.

jar: We're dealing with a lot of things that are not IR's, so it's important to get boundary cases. We need to identify diseases and chemicals.

timbl: When you look a the relatinoship between Moby Dick and a physical copy of it, you can get a distinction. You'll always find corner cases, like is 2 an IR?
... You can always push until it's uncomfortable, and that's pedantic and picky. But it's useful if you have a general idea.

dbooth thinks the email discussion was helpful in resolving that question: a rep is a relationship.

jar: but we run into real questions of whether a number is an IR.

timbl: Does google tell you about 3?
... I think we should make an ontology.

<scribe> Scribe: dbooth

<timbl> {x a Thing} is tautolgical

jar: Is a resource anything? You can put any URI on the left and it is a resource.

<timbl> I think th word "resourdce"in english is a terrible fit.

timbl: The word "resouce" was a historical choice. Much better to use "thing" in discussions.

noah: the tricky stuff: given that I have a URI, and I'm accessing it w HTTP and get a 200, how close does the rep have to be to whatever the resource was?
... I think the part that we're discussing now is the easy part.

timbl: Everything is a resource, everything is a thing.

noah: Everything can be a resource ....

timbl: No, everything *is* a resource.

<jar> it's a resource even if it doesn't have a URI!

<jar> "Can be" is what raised a red flag for me.

I was trying to point out that there is no need to differentiate between "is" and "can be" if you never try to talk about a particular resource, i.e., the difference does not matter.

jar: On the list, there was discussion about rep can be a class.

timbl: the relationship has a well-defined range. It's a well defined pair of metadata + octet stream.

<jar> Tim proposes a class Representation = metadata + content

timbl: That comes from Roy's thesis.

jar: If it is RFC2616 it does not include the response headers, but does include the entity headers.
... There's a wiki page listing the entity headers.
... IT's a small difference.

timbl: So it doesn't include all the http headers.

<jar> The email thread has some tag members saying they don't want to use 'representation' as a category...

timbl: awww talks about reps as classes. When you say "this is the rep of..." then y0ou cannot avoid using the nown as a class.

<jar> but Tim says this is fine?

My point in that email thread is that there is no rep without an IR: it only exists in relation to an IR.

noah: Somebody does a GET and i want to file a bug report, so I create a URI for that rep, using a checksum. I want to be able to do that.

<jar> distinction: representation = an entity that represents an IR.

<timbl> dbooth: a rep'n exists only in rpresnttaion in relation o a resource./

<jar> so representation is a subclass of entity, yes?

<timbl> NM: I craeted a URI and I said that this URI i s the URI of a Represntauo which happened at aparticular time, i want to say things about them.

<timbl> .. therefore Reprtesntaion is a class

noah: I'm not necessarily copying the bits. Therefore rep is a class.

y, it's useful in RDF to have a class of rep, but no rep exists in isolation.

jar: an entity is a grammar producttion.

<jar> tim: not all reps are going to be from http

timbl: when an http transaction occurs, we have a rep, but not all reps are goign to be http. In the case of http i find it useful to think that the entity is a rep.

jar: in a 404, the entity is not a rep.

<jar> Tim: rule: if 200, then the entity is a representation.

timbl: a rule says if http get occurs, and the status is 200, then the entity is a rep of the resource, (dbooth adds: and the resource is an IR)
... that's httpRange-14

jar: any reason to have reps that are not entities?

noah: timbl wants rep to be broader than http. SOAp has add-ons that talk about reps that are in the spirit of http. I don't think it uses the word entity.

<timbl> Ifthe status is 200, then the entity is a representation of the resource identified b the URI

<jar> noah: there are representations that are not entities because we want to cover more than just HTTP

<timbl> 'entity' is a terrible fit with things like XML usage as well, so using that term

jar: What is common among reps? metadata and octects?

timbl: metadata tells you the meaning of the bits. you read the protocol spec, and the metadata tells you how to interpret the bits to understand the meaning of IR.

noah: I'm tempted to say that it's the relationship that is common. If the rel is close to the spirit of what we mean, then ou can use the word rep.

dbooth: do we reallky understand the http case? how about if we focus on that before we broaden?

timbl: there is aother stufff out there -- gopher, ftp, etc.
... but ftp doesn't give you enough metadata, that's an existing tag issue.
... the awww isn't restricted to http, though it talks about http 99% of the time.

<jar> propose to table discussion of 'representation' outside of http?

<jar> tim proposes the class awww:representation

jar: What class should we use?

timbl: in http, the metadata is an unorderd set of pairs, followed by ordered set of octets. But an entity is serialized on the wire.

<jar> awww:representation as ADT? = unordered set of headers + ordered octets? abstract version

<Zakim> dbooth, you wanted to vote for first focusing on http

<noah> In case it's of any help, the text from RFC 2616 defining "Representation" is:

<noah> representation

<noah> An entity included with a response that is subject to content

<noah> negotiation, as described in section 12. There may exist multiple

<noah> representations associated with a particular response status.

<timbl> awww:represntation rdfs:Range awww:Represntation

<jar> dbooth thinks progress will be faster if we use rfc2616:Representation instead of awww:Representation

jar: Easier to generalize later than earlier.

timbl: Arch is at the general level. Talks about URIs, but not restricted to http.

noah: to do the http case and hope that it generalizes, . . . i don't think so.

<timbl> Can we just say that rfc2616:Representation rdfs:subClassOf awwwRepresenttaion.

<jar> noah: disagrees. harder to generalize later, better to get definitions right at beginning

timbl: http is not even https!
... I'm also concerned that if we talk about http we'll get stuck at the bit level instead of the abstract level.

<noah> RFC 2616 says:

<noah> "An entity

<noah> consists of entity-header fields and an entity-body, although some

<noah> responses will only include the entity-headers.

<noah> "

<noah> When you look at header fields, it's clear that they have ":" characters in them, so the HTTP concept of entity is no more general than that.

timbl: When you call something to retrieve something, it can do more than http. There's a kludge for file: that if it ends in .txt then the metadata is deemed to be plain/text.

jar: We need a model of the things that can be reps.

<jar> tim: of all the rep's metadata, the prime thing is the content-type, which is a mime type.

timbl: In the arch, of all that metadata the content type is the prime thing. The IANA registry has issues, the mime type should be a URI, and that's a longstanding issue.

<jar> (jar asked what more concretely we can say about what a rep is. does it have headers that have header-names and header-values?)

timbl: So I can make my own private mime type and dispatch on it. Which level are we goign to talk? I'm happy to do it in terms of mime types -- treat them as identifiers.

ack

<Zakim> dbooth, you wanted to again ask for RDF on the table

<jar> entity is-get-of resource

<inserted> I have some mostly done RDF. Here's a snippet:

########## Classes

http:Reply a rdfs:Class ;

rdf: comment "An HTTP 1.1 reply, as defined in http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6 ." .

http:StatusCode a rdfs:Class ;

rdf: comment "An HTTP 1.1 status code, as defined in http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1 ." .

http:EntityBody a rdfs:Class ;

rdf: comment "An HTTP 1.1 Entity Body, as defined in http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2 ." .

<jar> jar proposes that first triple is domain or range constraint of the http "GET" relationship

<jar> http:Reply = http2:ResponseMessage (@prefix http2: the one used by tabulator)

<jar> ?

<noah> Section 7.2 talks about colon (:) chars in the entity

<timbl> ikeXML document string vs DOM

<timbl> Like

<jar> tim: production for entity as string must be distinguished from the ADT/parse tree which is the representation [and maybe the entity]

<inserted> dbooth: It tries to accurately model HTTP, but there are a few things I had to gloss over. For example, I did not yet find an appropriate xsd data type for "octet stream", so at the momemnt I'm treating it as an xsd:string.

<jar> need to wind up folks... homework?

<noah> I suspect that the value space of the XML binary formats is closer to what you want than xsd:string, though the serialization in HTTP over TCP is certainly not Hexbinary or Base64 in the typical case.

timbl: If you get some bits, and you run an RDF/XML parser on it, then you get a formula.
... I need to run to AB event. Amy didn't have this mtg as a recurring event.

<jar> cwm has relationship between bits and formula... similar

jar: noah, y9ou've ben silent. What do you think?

<jar> noah: we need to decide what we're going to do carefully & what not. need to be careful about abstractions like 'resource'

noah: I think we need to make a cleaner decision about which things we're going to do carefully, and for core concepts like rep we don't want to be a little bit pregnant. media type fills a position in the arch for http, but suppose we're using p-p protocol?
... My intuition would be for core concepts like rep, embodiment on the wire, need for typing info to let us interpret it, we should do it cleanly and then specialize to http.

<jar> talk about restful protocols generally

noah: Or second choice, let's not do the gen case at all, except maybe https.

jar: If people are familiar about OBO, there are lots of people trying to be very careful about issues llike this. I asume they'll coord w the lib community. They're trying to make general enough defs.

<scribe> ACTION: jar to send out pointer to OBO work [recorded in http://www.w3.org/2008/02/05-awwsw-minutes.html#action01]

<trackbot-ng> Sorry, couldn't find user - jar

jar: There are thorny philosoophical differences though. They're goign to use a particular method of making ontologies. But it's worth looking at the method as opposed to software eng methods. Interesting differences.

<scribe> ACTION: dbooth and jar to get together at least once before next mtg [recorded in http://www.w3.org/2008/02/05-awwsw-minutes.html#action02]

<trackbot-ng> Created ACTION-4 - And jar to get together to discuss RDF at least once before next mtg [on David Booth - due 2008-02-12].

<jar> thanks again dboot

<jar> h

- DRAFT -

Architecture of the World Wide Semantic Web

05 Feb 2008

Attendees

Contents

Representations

Summary of Action Items

Scribe.perl diagnostic output