AWWSW -- 18 Jan 2011

<jar> 'project outline' http://lists.w3.org/Archives/Public/public-awwsw/2010Nov/0000.html

<scribe> Scribe: dbooth

Adminsrative/Organizational

jar: Recruit more people? Suggest to the TAG to spin out nose following?

<jar> can anyone hear me?

<jar> for agendum on reviewing writings, consider 'project outline' http://lists.w3.org/Archives/Public/public-awwsw/2010Nov/0000.html

jar: Under review/recent writings there is just the plan
... I've been thiking a lot, and have a draft 16 page doc, but it's such a mess i don't want to show it to anyone.

dbooth: show it! better to get the mess on the table.

http://lists.w3.org/Archives/Public/public-awwsw/2010Nov/0000.html

- The work product is to be a set of logical predicates (classes and

properties), expressed in OWL, together with explanation and

rationale.

dbooth: ok w me.

[[

- Decide that we are documenting the design of web architecture, not

reality. So this is not an ontology project, really, as it is not

empirically based. Call it a 'quasi-ontology' (QO). It can be

applied to reality only to the extent that reality adheres to the design.

]]

dbooth: drop that part? if we're writign classes in owl, it is an ontology.

jar: I meant "ontology" in the philosophical sense -- what is.

[[

- Deal with 'representations': content, media type, language.

]]

jar: If we're talking in owl, then there would be a class of representations, and the members of that class would have properties.

dbooth: sounds reasonable to me.

nathan: i still don't see a distinction between a resource and a representation.

jar: Then we could take it as a success criterion.

[[

- Introduce 'information resource' as something that 'has

representations' (different ones at different times) and pretty much

nothing else. (maybe some 'phlogiston')

]]

jar: unsure of what to label these terms.

dbooth: as long as we use something to clearly lable them we should be ok

jar: We need a relation that connects representations to the things that have them. In HTTP it has something to do w authorization.
... But relation of representation to anything else is funny. In http the URI identiffies something, and certain responses are authorized.

nathan: http is inconsistent w itself in that respect. One resource can have two names, two different servers, but his idea is that they must be entirely consistent in every way -- exactly the same in every way. So there's a big difference in what is in http and the design of http.

dbooth: So you're saying that it isn't possible in http to have one resource identified by two different URIs?

nathan: yes.

jar: we dont' want to be in the business of standardization or design. if we come across a new definition we should give it a new name. So if Roy talks about a theory soomewhere, then we just write down that term.

nathan: agreed

<jar> 'representation' - ok label

jar: want to avoid the label 'information resource"

<jar> label for: relationship, according to http, between the target resource and an authorized representation

jar: we want a label for the relationship according to http between the target resource and authorized representation.

<scribe> New text: [[ Introduce a term for the relationship according to http between the target resource and authorized representation. ]]

dbooth: sounds good.

jar: Plus more text: [[ And another term for the domain of that relationship. ]]

[[

- Talk about properties of IRs as a way of explaining purpose.

Purpose of IR idea = saying things about them. Content invariants

(e.g. author, title, publisher, date, subject, media type, language,

scribe: ). Lawful variation (weather in Oaxaca, news.google.com, blogs).

]]

nathan: Only one ont being made?

dbooth: let's start w one.

jar: if it ends up being inconsistent, that's a bug.
... e.g., random page from wikipedia. Any theory we come up with must allow 200 responses for that, so our ont must handle that.

dbooth: I'd leave that paragraph in, though we may not end up saying much about the properties.

jar: what's the identity of the random page resource? what can you say about it? it's main property is serving random pages.

dbooth: But they're all from the wikipedia site, rather than from anywhere on the web.

jar: So that's one interesting property. another is that it's random.
... Maybe rephrase without the word "purpose".
... You could say that purpose and content invariant are two ways to say things about the resource.

nathan: Is this saying that the random wikipedia page would be an information resource?

jar: i think we need to stay away from the term "information resoruce"

nathan: agreed

jar: let's use our numeric terms.
... I want to have a rel btwn the http target resource and the representation.

nathan: I think the random wikipedia page redirects.
... If it does redirect, could it just use 200?

jar: there is the whole topic of the semantics of redirects -- TAG issue 57.
... we need to take a cafeteria approach: 'here are ways people interpret redirect. pick what you like'

<jar> "purpose" and "invariant" are two attempts to get at the properties of the HTTP target

dbooth: i suggest we just put the word 'purpose' in quotes:

[[

- Talk about properties of IRs as a way of explaining "purpose".

"Purpose" of IR idea = saying things about them. Content invariants

(e.g. author, title, publisher, date, subject, media type, language,

scribe: ). Lawful variation (weather in Oaxaca, news.google.com, blogs).

]]

jar: fine.

<jar> what motivates content invariants?

jar: "Content invariants": what motivates them?
... a lot of people don't differentiate between resource and rep in the good old fashioned hypertext web.

<inserted> jar: GOFHTW == "Good Old Fashined Hyper Text Web"

<jar> in GOFHTW, representation ~= resource

dbooth: people want to know what to expect on dereferencing the URI.

jar: Also if you GET a rep, that tells you somethign about the resoruce.
... e.g., if the rep has a particular title, then that's the title of the resource.
... But the random wikipedia page doesn't do that.

<jar> on GOFHTW, title of representation is what the title of resource is.

dbooth: So we have a spectrum of things that obey that or don't obey that to varying degrees.

jar: And on the GOFHTW, they are the same.
... And I believe that's the reason for the httpRange-14 rule.
... And content invariant is a way to bridge the GOFHTW with the modern web.

[[

- Optional topic: Versions and stability (e.g. as practiced at w3.org).

]]

dbooth: This paragraph is very closely related to content invariants.

jar: But variation is arbitrary: the uri owner can change anything.

<jar> versioning is just one kind of variability

<jar> versioning: content evolves over time...

dbooth: I think this paragraph needs to stay, perhaps in the same bucket as content invariant.

<webr3> "Versioning and promised stability" ?

suggest: [[ Also consider: Versions and stability (e.g. as practiced at w3.org). ]]

jar: timbl talks about dimensions of variability, but there's an unlimited number of dimensions.

dbooth: right, timbl is talking about the comon ones.

nathan: I think there's a link missing. If you add in that link, then these things share the same properties.

dbooth: Great if you can write up your thoughts.

[[

- Suggest ways to interpret various situations in terms of the QO.

Files as IRs. HTTP as revealing information about IRs (their

representations). Expires: , Content-location: , and so on.

Status codes.

]]

jar: QO = Quasi-Ontology

<jar> quasi

<jar> change 'QO' to 'vocabulary' or 'ontology'

[[

- Suggest ways to interpret various situations in terms of this ontology.

Files as IRs. HTTP as revealing information about IRs (their

representations). Expires: , Content-location: , and so on.

Status codes.

]]

[[

- What HTTP redirects tell us (in terms of the QO). Additional

predicates, if needed. "Cafeteria" approach, meaning offer a choice

of ways to interpret redirects in the QO.

]]

dbooth: I suggest treat redirects as a separate work item.

nathan: Seems related to content invariant.

jar: But content invariant is relevant to 200 responses. But different people have interpreted redirects in different ways.

<jar> Redirects as a separate work item?

dbooth: I think we have enough to bite off without addressing redirects.

nathan: would redirect be relation between resources?

dbooth: that's part of what would need to be figured out.

AGREED: Separate off redirects as a separate work item.

[[

- The 'describes' relation. Interpreting 303 and RDF-based fragid

definitions.

]]

dbooth: That belongs with redirects.

jar: But semantically it is not a redirect.
... We could separate out "follow your nose" as a separate work item.

dbooth: I think we should.

AGREED: Leave 303 to either nose following or redirects.

[[

- Optional: Fragid semantics in general.

]]

dbooth: If we get the basic ont without fragid's it will be a substantial step forward. So leave fragids for a separate section.

jar: yes.

[[

- Optional: Link relations (Link: and /.well-known/host-meta)

]]

jar: Put link relations with 303.

nathan: why?

jar: Because it is used operationally similarly.

nathan: the spec says its a rep header, but people use it as a resource header -- about the resource.

AGREED: Put link relations with 303 for the moment.

[[

- Check against use cases (which we'll have to re-collect, I think

they're scattered)

]]

dbooth: yes, keep that.

nathan: *in scope* use cases, yes.

[[

- Disclaimers (when this breaks down)

]]

dbooth: what did you mean by this?

jar: not sure.

dbooth: Let's take it out then.

jar: ok.

[[

- Comparison with other work (IRW, IAO, etc)

]]

dbooth: I wouldn't want to be too belabored by it, but where we know about relationships to other work it should be mentioned.

jar: yes

[[

- Choose class and property URIs and prepare OWL file and report.

]]

dbooth: yes.

jar: That was a reminder not to pick labels for the URIs until late in the process.

dbooth: Anything that should have been included but wasn't?

jar: I have a doc on URIs and nose following that relate to this, but we don't have to treat in depth. Lot of gen discussion that needs to happen before vocab makes sense.

<scribe> ACTION: dbooth to resend the project outline edited per this discussion [recorded in http://www.w3.org/2011/01/18-awwsw-minutes.html#action01]

<trackbot> Created ACTION-39 - Resend the project outline edited per this discussion [on David Booth - due 2011-01-25].

Other task forces

jar: think about whether we should recommend other task forces

dbooth: maybe recommended task forces should be another output of this group?

<jar> 'task forces' would be the link between TAG and semweb/LOD - if there is to be any.

dbooth: I think recommending task forces for specific items is a very good idea.

<jar> without them the two will just drift further and further apart

ADJOURNED

- DRAFT -

AWWSW

18 Jan 2011

Attendees

Contents

Adminsrative/Organizational

http://lists.w3.org/Archives/Public/public-awwsw/2010Nov/0000.html

Other task forces

Summary of Action Items

Scribe.perl diagnostic output