Minutes for 18-Jan-2011

http://www.w3.org/2011/01/18-awwsw-minutes.html

and in plain text below.

--------------------------------------

[1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                                 AWWSW

18 Jan 2011

   See also: [2]IRC log

      [2] http://www.w3.org/2011/01/18-awwsw-irc

Attendees

   Present
          Jonathan_Rees, David_Booth, Nathan

   Regrets
   Chair
          Jonathan Rees

   Scribe
          dbooth

Contents

     * [3]Topics
         1. [4]Adminsrative/Organizational
         2. [5]http://lists.w3.org/Archives/Public/public-awwsw/2010Nov
            /0000.html
         3. [6]Other task forces
     * [7]Summary of Action Items
     _________________________________________________________

   <jar> 'project outline'
   [8]http://lists.w3.org/Archives/Public/public-awwsw/2010Nov/0000.htm
   l

      [8] 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'
   [9]http://lists.w3.org/Archives/Public/public-awwsw/2010Nov/0000.htm
   l

      [9] 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.

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

     [10] 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
   [11]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

Summary of Action Items

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

   [End of minutes]
     _________________________________________________________


    Minutes formatted by David Booth's [13]scribe.perl version 1.135
    ([14]CVS log)
    $Date: 2011/01/18 15:15:33 $
     _________________________________________________________

     [13] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [14] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20
Check for newer version at [15]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

     [15] 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
"
Found Scribe: dbooth
Inferring ScribeNick: dbooth
Default Present: jar, DBooth, webr3
Present: Jonathan_Rees David_Booth Nathan
Got date from IRC log name: 18 Jan 2011
Guessing minutes URL: [16]http://www.w3.org/2011/01/18-awwsw-minutes.ht
ml
People with action items: dbooth

     [16] http://www.w3.org/2011/01/18-awwsw-minutes.html

   End of [17]scribe.perl diagnostic output]

     [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm


-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Tuesday, 18 January 2011 15:32:32 UTC