See also: IRC log
<jar> 'project outline' http://lists.w3.org/Archives/Public/public-awwsw/2010Nov/0000.html
<scribe> Scribe: dbooth
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.
- 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].
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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Quality /Quasi-/ Succeeded: i/in GOFHTW/jar: GOFHTW == "Good Old Fashined Hyper Text Web" Succeeded: s/Present: Jonathan Rees, David Booth, Nathan/Present: Jonathan Rees, David Booth, Nathan Rixham/ Found Scribe: dbooth Inferring ScribeNick: dbooth Default Present: jar, DBooth, webr3 Present: Jonathan_Rees David_Booth Nathan_Rixham Got date from IRC log name: 18 Jan 2011 Guessing minutes URL: http://www.w3.org/2011/01/18-awwsw-minutes.html People with action items: dbooth[End of scribe.perl diagnostic output]