See also: IRC log
<Chris> scribe: Noah
Start of Noah Scribing
Attendees: Roy, Noah, Stuart,Chris, Paul, Norm
Tim expected 2PM Basel time
Dan we think probably later this morning.
Discuss meeting dates?
Sorry that was: Stuart: discuss meeting dates?
PC: We have Nov 29 & 30
<Chris> 29th-30th November 2004
<Chris> Boston, MA, USA.
NM: No problem
SW: Regrets, I could travel on Monday, but no earlier.
<Chris> Possible meeting opportunities:
<Chris> 1. 28th Feb- 4th March 2005
<Chris> W3C Technical Plenary, Boston, MA, USA.
<Chris> 2. 10-14th May 2005.
<Chris> WWW2005 Chiba, Japan.
<Chris> 3. 6-7 June 2005
<Chris> W3C AC Meeting, Cannes, France.
<Chris> 4. Summer 2005 in Kanas (a break with a Canadian tradition)?
<Chris> 5. October 2005?
Notes from pre-start of formal scribing discussion: we have received email with outline of comments from Dan. http://lists.w3.org/Archives/Public/www-tag/2004Oct/0003.html
CL: Tech plenary good for meeting other groups, bad for our own meetings.
<Chris> TP is great for meeting with others but poor for advancing our own work
PC: That was good last time. But where will web arch 1 be in March?
NM: What's plan for 2nd edition
PC: We drew line: 1st edition is retrospective, 2nd Ed looks forward.
NM: Good. I have some
issues, some serious, but the serious ones are basically in the
looking forward pile.
... If we can clarify what looks backward and what's universal
(e.g. naming everything with URIs). Then I'm happy with no new last
call.
SW: we owe heartbeat in Nov.
CL: One option: can publish cleaned up post-last call draft, with indication we think all issues closed on the way to Proposed Rec.
PC: Should aim to have something like PR done at tech plenary. Could discuss forward looking issues at tech plenary. That would be ideal.
SW: who is planning committee this year?
PC: When? I think
they're busy planning AC meeting.
... I don't see any showstoppers in our issues except maybe http
range and xlink.
... Xlink worries me a bit if we pull it? With what do you replace
it?
NM: Maybe see how this week's discussion goes?
SW starts must discuss list on whiteboard:
MUST DISCUSS
------------
Information resource/Web Resource/HTTP Range-14"
------------
Paul and Norm report conflicts
SW: Last year, we had
1/2 day meeting as tag with observers
... we got good feedback
... had 1/2 day with core, and then liaison sessions with best
effort participation by other tag members
PC: We should focus on
forward looking issues.
... what is status of D. Orchard versioning work?
NM: Schema is working on this.
PC: Right, it's Noah's
headache now. He's on schema.
... When are election results?
SW: End of Jan.
PC: Should give info to
those who run so they know about meeting scheds.
... What about meeting first Week of Feb to bring new members up to
speed? Good idea but I can't make it.
SW, NW, NM: Two commitments in Feb is tought. We're leaning against.
Typo: tought -> tough
NM: what about 1/2 day meeting at Plenary with new members instead of early Feb.
SW: yes, could do that. If first half of week, we can plan Wed. session.
NW: every 3 months is good. How about early March, early June, early Sept?
NM: +1, skip July, Aug
SW: Dan offers Kansas city.
NM & NW: makes sense if we do it in Sept. Let's do with AC meeting in Cannes for June. So we meet June 8-10 in France, maybe Kansas City, in Sept.
PC: doing this without Tim BL is arguably mistake.
-----Net of Meeting discussion----------
Firm proposal, 1/2 day day first of Tech plenary, Feb 28 or March 1
Firm proposal: June 8,9, 10 following AC meeting in France.
Suggestion: Kansas in Sept., date to be confirmed
Probably: AC meeting late fall 2005, dates TBD
-------
-------
<DanC_lap> like this: /op foo
RESUMING AFTER BREAK
-------
SW: Norm: preference on what to do?
NM: No.
Sorry that's:
NW: No
Discussing http://lists.w3.org/Archives/Public/www-tag/2004Oct/0003.html, Dan's comments.
Dan proposes in abstract:
"The World Wide Web is the result of relatively simple technologies with sufficient scalability, efficiency and utility that they have resulted in a remarkable information space of interrelated resources, growing across languages, cultures, and media. In an effort to preserve these properties of the information space as the technologies evolve, this architecture document discusses the core design components of the Web (identification of resources, rep
PC: Split into 3 sentences.
<Chris> Split at Web (identification and at space) as well
NM: suggest replacing "is the result of" with "uses"
DC + NW: agree
Dan comment:
"The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used in the principles, constraints, and good practice notes in accordance with RFC 2119 [RFC2119]. However, this document does not include conformance provisions for these reasons
* ? that's contradictory; RFC2119 says MUST/MAY/SHOULD are all about conformance.
RF: Lowercase them all. We don't need to capitalize them.
Debate about our use of these.
PC: commonly misused
RF: agree
<Chris> remove gratuitous RFC2119 reference
NM: it's not "resource MUST be named with URIs"?
RF: Nope, You don't have to name them,
CL: middle ground, carefully defined, but not RFC2119
NM: Chris, would you
uppercase>
... Chris, would you uppercase?
CL: No. I would just carefully define and use lowercase.
NW: I don't want to get into that.
RF: We got comments on this from others.
DC: Would like editor
to go through all, lowercase, and let us know how it works.
... If necessary, clarify in place.
NW: Uh, OK.
CL: I would lift the exact 2119 definitions, but take them out of the context of a conformance requirment.
NM: 2119 doesn't talk about conformance, it talks about interop.
CL: OK, that changes my earlier comment. I do think we do conform to 2119. Dan's comment is wrong.
DC: No, our uses aren't necessary for interop.
From 2119: "6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
<Chris> we agree that RFC2119 should not be an RFC because it has a MUST that is not about interoperation or limiting harm :)
SW: propose. We retain the reference to RFC 2119, keep caps, and ask editor to review,
DC: Probably not necessary, as ours do indeed look like theirs.
NW: Our revised position is: leave it all as is, except in the sentence "The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used in the principles, constraints, and good practice notes in accordance with RFC 2119 [RFC2119]. However, this document does not include conformance provisions for these reasons", we have doubts about the word "however".
Scribe says We are now discussing Dan's note "2.2.1.1. URI ownership
? where did the example of http/DNS go?
"
SW: I wrote that to elaborate on rights and obligations of ownership.
DC: where did the DNS example go? Canonical example, where did it go?
SW: didn't seem pertinent
DC: unconvinced
SW: seemed incidental to me.
NW: generally happy with Stuart's text, would add example back.
Agreed.
DC: Also, move data: scheme out of this.
SW: was hinted that they are owned by the community that maintains the scheme spec for data:
DC: no, they don't have
owners
... when we talked about this, ownership was one pattern. news:
groups didn't have particular owner.
NW: agree, happy to say
data: has no owner, can go either way.
... Conclusion: add DNS example, and move data down to 2.2.1.2
SW: move down or remove
NW: if I move it down, I'll make clear there's no owner.
SW: OK.
----
? not testable; perhaps...
? that the URI owner has chosen different resources for them to refer to
"
DC: suggest we not discuss
Some discussion of whether not to discuss :-)
CL: "underlying" is the problem there.
SW: remove underlying
DC: neither helps nor hurts
SW: more direct
NW: delete last sentence of 2.3.2 "The distinguishing characteristic of representation reuse, as opposed to aliasing, is that the underlying resources are different."
Editor has removed it.
Others agree that's OK.
DC: Note: all this is input to the editor.
----
? Good practice: URI opacity
? opacity is a MUST; if the point is too subtle to make in bumper-sticker style, delete the box?
? The "mailto" URI scheme specification
? cite by chapter and verse
? 2.5. URI Opacity (whole section)
? this section doesn't make the main point, which is that owners get to decide what URIs mean; opacity violations are the subject of siteData-36; where did the reference to that issue go?
"
DC: the point is,
providers get to decide.
... no concrete suggestion, except to reference siteData-36
Editor (NW): I'll take a look.
----
? change to constraint
? fwd ref 5.3 esp "Principle: Error recovery"
"
NW: You'd like to change it to a constraint.
Agreed: change principle in 3.4 to a constraint.
----
"
<Chris> I disagree with Dans comment starting "gee; can I have a GPN about my personal pet pieve too?"
DC: this is about bad software from the past
CL: No, I'll give you
space on my server, but not change my applications.
... The ISPs don't see that as low quality service. I don't want to
have to worry about this.
DC: my suggestion really is to suggest that QA has a responsibility
CL: Not clear this is a QA issue. These ISP's know exactly what they're doing.
Agreed: leave good practice note, add reference to QA up front.
<Chris> we rely on server metadata as authoritative; thus we should ack that people should get to generate this server metadata
----
? obscures the point by talking too much about specifications.
? a representation consists of a sequence of bytes plus an Internet Media Type [RFC2046] which tells whether the bytes represent text, graphics, video, a spreadsheet, etc. The IANA registry [MEDIATYPEREG] maps media type names to data format specifications (§4).
"
CL: makes that a lot clearer.
<Chris> dans rewrite for "The Internet media type [RFC2046]) of a representation determines which data format specification(s) provide the authoritative interpretation of the representation data" is a lot clearer
<DanC_lap> (stuart, did you just (try to) say that file: is _not_ a mess?)
<Zakim> Chris, you wanted to talk about content transfer encoding
Scribe regrets that he missed scribing a long discussion driven by the scribe himself.
Short summary: NM believes current web arch is too strong in implying that all representations are single streams, are specifically octet streams, and need to be typed with IANA media types.
Suggests: form of a representation is determined by scheme spec
Appropriate typing mechanism MAY be signaled by scheme spec.
In most places we refer to IANA media types we should refer to
<Stuart> Chris is concerned about the application of other headers that affect what bits are transferred on the 'wire'.
<Stuart> 1) Not all transports give you the metadata....
"the type of the resource as designated by the scheme. Indeed, current common practice with HTTP is single octet stream with Iana."
<Stuart> 2) [Missed Chris's comment]
RF: Right, I agree in principle, but not that retrieval is not necessarily tied to schema
NM: agreed.
<Roy> The form of a representation is defined by the current protocol used for interaction (i.e., it changes if the protocol changes). A scheme should define the mapping from names to whatever those names are allowed to correspond.
Noah back in sync scribing.
NW: Having media types in 3.3 ahead of representations is odd
<Chris> media type is a) not provided in some schemes, such as ftp b) not the only thing needed to interpret the bytes (eg content language, content transfer encoding , assorted other headers)
<Stuart> Discussion of what to call 'concrete' representation forms if representation is used as a more abstract/general concept.
<Chris> dan clarified that the content transfer encoding is already dealt with ; the bytes of the representation have already been decoded (eg, gunzipped) so the bytes over the wire and the bytes of the representation are different
<Stuart> Norm: I'm concerned that changing what representation means is a deep change in the document.
<Stuart> Noah: Yes... that's why I hesitated to bring it up.
<Chris> rf: no other document actiually needs a reference to octets
<Chris> nw: (agrees)
NW: how pervasive would this be?
<Chris> dc: this is not editorial
NM: hard to tell.
<Chris> dc: would this force another last call
<Chris> nm: will propose some text, lets see what the scope is and whether it can be included without damage to timescales
<Chris> nm: and as long as its clear this would be in scope in the second edition
PC: what are you
proposing to do?
... I think adding conceptual or design princple
... Also are going to use terminology in the http case?>
<Chris> http://lists.w3.org/Archives/Public/www-tag/2004Oct/att-0003/webarch-28sep-comments.html
NM: Well, I hope that if we use the terminology "right" it will look both simple and clean
<scribe> ACTION: Noah to take a run through to see how it would look with more careful terminology.
<Chris> if we do lots of clarification where we are in fact talking about http, i hope we don't end up giving the impression that the web is *only* http
ACTION 1=Noah to take a run through to see how it would look with more careful terminology (committing best effort, not success)
----
"Also, they can be consumed more rapidly by agents in those cases where they can be loaded into memory and used with little or no conversion.
? need to note security issues there!!!
"
DC: that's a huge security risk. If we mention this, we need to point out the security concerns (I.e. if you trust the sender, the communication mechanism, etc.)
NW: as editor, I'm happy to note that security risk.
----
"In a perfect world...
? well said!
"
DC: Thanks! but...
----
"A specification SHOULD provide mechanisms that allow any party to create extensions.
? The surrounding text is good, but this is still too strong. Should Euclid's list of 5 postulates be extensible? Maybe some sort of counter to the 0/1/infinity principle...
? any essentially arbitrary list should be extensible
"
DC: this is still too strong
PC: A specification should devote the benefits or costs of providing extensibility
DC: 4 paragraphs of our text doesn't do it?
PC: should the keywords in Query be extensibility
<Chris> ScribeNick: scribenoah
NW: believe David Orchard believes extensibility always good
NM: actually, there are a ton of dimensions to any spec. Should we allow XML to go non-Unicode? Most of these dimensions shouldn't be extensible. The trick and the art is to choose just those you want to worry about.
PC: So, it maybe the
editors' attempt to reflect David's formulation that's pushed hard
over toward "extensibility is good".
... I think QA wants us to get people to think about
extensibsility, not in all cases to encourage extensibility.
... Dan, the principles come right out of the draft finding.
... I'm concerned we'd spend time changing web arch without
revisiting the draft finding.
Tim: we are discussing the comments dan emailed which are at http://lists.w3.org/Archives/Public/www-tag/2004Oct/0003.html
NW: I tried to reflect
what I could of the draft finding.
... I can change the first good practice bullet. Would like to keep
2nd and 3rd.
<DanC_lap> pls s/Extensibility mechanisms MUST NOT interfere/Extensibility mechanisms do not interfere/
<DanC_lap> but I can live with MUST not.
PC: If I take XQuery and add something to the language, it won't be understood by the earlier versions.
NW: right, there's no extensibility mechanism there.
SW: diminishing returns
Back to discussing first bullet in 4.2.3, do we have consensus on what to do.
Proposal: there is good reason to change the first bullet, but not now. QA probably will want a change. Conclusion, we'll reconsider later, leave it for now.
General agreement.
----
He says: "Discussing Dan comment "
Sorry, that's section 4.5.5
Try again.
We are discussing Dan's comment that says: "Good practice: QNames Indistinguishable from URIs
? this is a constraint; s/SHOULD NOT/do not/
"
The pertinent good practice note in the arch doc says:
"A specification in which QNames represent URI/local-name pairs SHOULD NOT allow both Qnames and URIs in attribute values or element content, where they would be indistinguishable.
"
Stuart thanks Tim for opportunity to have local IBM rep for IBM bashing
DC: suggests make constraint not good practice, and change SHOULD NOT to it's ambiguous.
<DanC_lap> (breaking for lunch)
We have agreed to DC's suggestion on 4.5.5
<DanC_lap> well, the chair didn't put the question AFAIK. The editor seemed sympathetic to DanC's comment and nobody else complained.
Right. Thank you for the clarification.
<Chris> Scribe: Norm
<Stuart> http://www.w3.org/2001/tag/2004lc/lc-status-report.html
<scribendw> Reviewing http://www.w3.org/2001/tag/2004lc/lc-status-report.html
<scribendw> (Revision 1.10 of 2004/10/05 12:21:52)
<Stuart> http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0131.html
<scribendw> ACTION: SW to review comments from PatH for issues that need discussion
<scribendw> Issue number 2 is spam.
<scribendw> Issue 4:
<scribendw> Delete the last two sentences of para 4 of 3.3.1?
<scribendw> RF: What they say is said elsewhere.
<scribendw> CL: I think it's valuable to say that you can compare URIs with fragment identifiers without retreiving them.
<scribendw> TBL: Lots of folks come with preconceived ideas, so it's not always best to say it in one place
<scribendw> RF: This reader was confused about interpretation of fragment identifier schemes across media types
<scribendw> DC: People have in mind that just because it looks like an xpointer they can use the xpointer spec.
<Roy> http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0121.html
<scribendw> DC: We should make this point near the .html point
<scribendw> NM: There's an implication that the only way you can only get the media type is by retrieval.
<scribendw> CL: We don't want this to apply to the case where the media type is in another attribute
<scribendw> RF: The first sentence was left over from before fragments were part of a URI.
<Chris> CL: case we specifically don't want to authorises is the media type from a type attribute on the link, plus the URI with a fragment
<Chris> CL: in the case where a retieval gives a different type
<scribendw> RF: Basically the confusion was does the fact that xpointer defines a syntax for fragment identifiers, does that give the person license to inspect the URI.
<scribendw> RF: No, just like the .html case.
<scribendw> NW: Now that I understand the point, I'm inclined to remove the sentences and make the point in the section on URI opacity.
<scribendw> SW: I'm going to take 5 with 3 (we delayed 3 earlier)
<scribendw> ACTION: DanC to close 6
<DanC_> ndw in re gk http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0125.html
<scribendw> Issue 6 is resolved.
<DanC_> 6 = AWWW, 20040816 release, sections 1 and 2
<scribendw> ACTION: NW to close this issue
<scribendw> Issue 7
<Chris> ACTION 4=NW to close the issue about AWWW, 20040816 release, sections 1 and 2
<scribendw> Issue 7 deferred with 3 and 5
<scribendw> 7 = resources/representations [was: random comments on 2nd LC of WebArch]
<scribendw> Issue 8: too positive on extensibility [was: random comments on 2nd LC of WebArch]
<scribendw> NW: I believe that I did this actoin
<scribendw> ACTION: CL to respond to the commenter for issue 8 pointing to the new draft on extensibility
<scribendw> Issue 9: section 2.2 - what does it mean to 'take on meaning'
<scribendw> DC: I replied and I haven't heard back from him
<scribendw> DC: I'm inclined to take silence as assent
<DanC_> re section 2.2 - what does it mean to 'take on meaning' minute: take silence as assent, running the risk that he'll say "no" later
<scribendw> Issue 10: Use of "assign" for URI -> resource
<scribendw> SW: I have done nothing yet
<Chris> nw: chris, look for 'perfect world' in draft
<scribendw> SW: We weren't able to adopt Larry's position and so further discussion is needed
<scribendw> PC: Is this the thread about "renting"?
<scribendw> RF: No
<scribendw> TBL: It sounds related
<Stuart> http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0078.html
<scribendw> RF: Larry wants us to get rid of the idea of "ownerhsip" to the textual string of the URI
<scribendw> Review of http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0078.html
<scribendw> ACTION: NW to fix cross references to "uri allocation" that read "uri assignment"
<timbl__> "Larry, for URIs like HTTP URIs where one can reasonably talk bout ownership, we don't feel "assign" or "allocate" are inappropriate. If your issue was that you felt the AWWW was suggesting that any URI must have an ownership property, then we agree with that problem and have rearranged the text. "
<scribendw> TBL: People should use the URIs that were assigned.
<scribendw> TBL: In a large number of cases, we mean assign so we should stick with "assign"
<scribendw> RF: Larry's point is that it's possible to make use of a URI before it's assigned.
<scribendw> RF: Someone decides to use a URI from my web server to identify something that I've never assigned. I can leave it 404 or I can provide a representation.
<scribendw> RF: Larry's point is that not all URIs are assigned.
<scribendw> TBL: Either they're assigning it or they're violating your trust or they're assuming you're going to create the resource or they're working with you.
<scribendw> CL: He says up front that he's trying to remove ownership
<scribendw> NM: We made some changes but we never bought into the concept, so we don't think that we need to make more changes.
<scribendw> RF: I think his edits make the document more accurate and they don't break anything
<scribendw> DC: Assign vs. use. RF, you like that better (yes). I'm not convinced.
<scribendw> TBL: I would object to that
<scribendw> TBL: Using words like assignment when assignment is being done, we help readers
<scribendw> DC: The text occurs in a section outside the ownership section, so it applies to all URIs, not just those with owners
<Chris>
<Chris> completing my action item http://lists.w3.org/Archives/Public/public-webarch-comments/2004OctDec/0001.html
<scribendw> SW: Where Larry is at, as I understand him, takes a very operational view. An HTTP URI means perform a set of operations and you get some expected results
<scribendw> DC: We're talking about assigning meaning to URIs just like we assign meaning to words.
I think DC means:
<scribendw> Some discussion of data: URIs
We're talking about assigning meaning to URIs >by giving the association to resources<, just like we assign meaning to words. Right, Dan?
<scribendw> CL: Either we can say you don't have to dereference a data: URI or we can say that looking at it is effectively dereferencing it.
<Chris> and I prefer the latter
<Chris> it seems tim does too
<scribendw> TBL: I don't htink there are any schemes where we need to make sure that people don't use the same URI for different things and there isn't allocation going on
<scribendw> SW: It seems we are leaving the "assign" variant in
<DanC_> PROPOSED: to keep " Constraint: URIs Identify a Single Resource Assign distinct URIs to distinct resources." despite the new information from LMM's comment
<DanC_> 2nded
<scribendw> by TBL
<Chris> ok by me
<timbl__> TBL: I don't htink there are any schemes I can think of now where we need to make sure that people don't use the same URI for different things and there isn't allocation going on.... and there is any question of what the URI identifies.
<timbl__> above
<scribendw> Accepted. RF abstains.
<scribendw> ACTION: SW to tell the commenter
<scribendw> Moving on to additional comments
<scribendw> TBL: Ownership of the resource and ownership of the URI in the semantic web are fundamentally different.
<scribendw> NM: So your answer would be: yes, I see the difference, but both admit to ownership.
<scribendw> DC: I'd be willing to consider ownership of the mapping from URIs to resources
<scribendw> NM: You could copyright a string. We have existing legal frameworks for dealing with these issues.
<scribendw> DC: We already say what I was hoping we'd say.
<scribendw> PROPOSED: URI ownership is an important concept, we think URIs can have owners, we are not inclined to make the changes suggested
<scribendw> CL: I own "x.com" and I make some namespace URIs, then my ownership period expires and someone else buys the domain. Do my resources still have the same meaning or do they mean what the updated server says?
<scribendw> DC: They mean waht the updated server says.
<scribendw> DC: "Bad things happen."
<Chris> especialy for the namespace case where no dereference is needed
<scribendw> TBL: The webarch says how things are supposed to work, we don't enumerate all the ways in which it can fail
<scribendw> TBL: The HTML WG says they own what the tags mean and they can change them at any time
<scribendw> DC: It's more like not well-formed documents; the spec doesn't say much about what not well-formed documents mean
<scribendw> CL: You're not required to dereference the URI so you won't find out what they mean
<scribendw> TBL: Eventually you'll get inconsistencies and then you'll know
<DanC_> (chris, that's tim's answer; it's not from the webarch document)
<scribendw> PC: There's a notion of timeliness here. Do we have to point that out?
<Chris> ok well in that case maybe the answer should be in - or derivable from - the webarch doc
<scribendw> PC: Do we say anywhere that we don't describe the ways in which things can fail?
<Roy> Larry's suggestion is to describe the mechanistic architecture of how URIs obtain meaning through use, whereas the TAG is describing the architecture of intended meaning that is supposed to guide folks building the mechanistic architecture in determining its meaning.
<scribendw> SW: In response to the question of has the meaning of the URI changed, a very operational view would say no, it still means what the HTTP spec says i tmeans
<scribendw> DC: That's one of the things I find unappealing about that point of view, something in the architecture has broken
<DanC_> 2nd PROPOSED: URI ownership is an important concept, we think URIs can have owners, we are not inclined to make the changes suggested
<DanC_> (I'd word it differently, but I trust it'll be worded differently where it matters, in webarch)
<Chris> another point of breakage, the iso committee for country codes can (and has) re-used country codes to refer to a different country
<scribendw> The scribe fails to capture some discussion here...
<Roy> PROPOSAL: The TAG uses the term URI ownership rather than resource ownership because some URIs identify resources that the URI owner (a.k.a., minter) does not own. For example, when a URI identifies a physical object that is merely named by the URI owner.
<DanC_> 2nd
<scribendw> Accepted.
<Chris> ok
<scribendw> ACTION: SW to make this response to Larry
<scribendw> <break></break>
<scribendw> SW: Unsure where to start
<scribendw> DC: Almost the null hypothesis: the last call document is almost good enough.
<scribendw> DC: My biggest reservation with the LC draft is that it doesn't distinguish between the Stickler position and the TBL position and yet they are very different
<scribendw> CL: Is that because it has an ambiguity?
<scribendw> DC: No, it's consistent with a lot of things
<scribendw> SW: Can you cast light on the difference?
<scribendw> DC: Yes, there are information resources that are dogs in Patrick Stickler's world view and there are not in TBL's view
<scribendw> NM: Can you clarify why Stickler believes there are information resources that are dogs?
<scribendw> SW: If you arrange for representations to be available for a resource that you assert is your dog, your dog is an information resource
<scribendw> Going around the table
<Chris> pointers to my thoughts on this issue:
<Chris> http://lists.w3.org/Archives/Public/www-tag/2004Sep/0162.html
<Chris> http://lists.w3.org/Archives/Public/www-tag/2004Sep/0137.html
<scribendw> RF: What we have currently is sufficiently vague that it doesn't have anything architecturally meaningful to say. Stickler's comment was, if that's what you want to say then why not call it a web resource. Sandro doesn't define information resource and he provided one. There's a long stream of replies about why that's not true, according to other people.
<scribendw> RF: My preference is for Stickler's proposal
<scribendw> NM: Right now, it's not clear that the distinction is crisp enough to be of benefit to readers
<scribendw> NM: I don't have a well-informed opinion about what answer is right.
<scribendw> NM: I could get clarity by asking all the questions we're talking about here.
<scribendw> SW: The distinction was introduced in response to some comments and seems to have helped.
<scribendw> SW: I think that there's a related bit from a conversation with Larry about ownership. There's need for implicit or explicit indirection between URIs that are web-page like and URIs that are real-world or conceptual artifacts. With respect to httpRange-14, one direction is to use the hash for indirection; the Dublin Core folks seem to use http redirection.
<scribendw> I thought that was interesting.
<Roy> [correction to RF above] Sandro agreed that what was in the webarch did not actually define information resource as intended, and thus his proposal was to add meat to that definition. His proposal was discussed on the mailing lists with very little support from others in evidence.
<scribendw> In making the web resource proposal, I got Stickler to agree that there's nothing in the document that he takes exception to, his concern is that people will read an implicit resolution into the httpRange-14 issue in the use of "information resource". If we're going to resolve it, we should do so more explicitly.
<Chris> Stuart proposed and Jacek seconded to change info resource to web resource. I agreed thusly
<Chris> It can be
<Chris> determined whether a given resource is a Web Resource or not. It exposes
<Chris> an electronic protocol (such as, for example, HTTP) and it can be
<Chris> interacted with. It need not return a representation (it might refuse
<Chris> to, or it might say there are no acceptable representations, etc) but
<Chris> agin, this is all testable technical specification.
<Chris> It was not possible to determine whether a resource was an information
<Chris> resource. By the very fact of someone referring to it, all resources
<Chris> have at least one bit of information (the 'alleged to exist' bit).
<scribendw> PC: I'm pretty sure I'm +1 on what CL said.
<scribendw> PC: We're going to leave someone unhappy and I feel bad about this.
<DanC_> (I wonder about a straw poll: (a) information resource per 18Aug draft, (b) web resource (c) refined information resource ala sandro)
<scribendw> PC: If there's any item that causes Dan not to get his dinner, this will be the one
<DanC_> [context: Dan doesn't get dinner if webarch doesn't go to REC in 2004]
<DanC_> [bet with PaulC]
<scribendw> PC: I'm tending to agree because it answers the question of what is on the web
<scribendw> NM: Is it my intention that makes it so, or is it that it's up a lot, or does it come and go with the server?
<scribendw> CL: Testable over the long term, not necessarily over the short term
<scribendw> NW: I like web resource proposal, I'm happy to adopt that.
<timbl__> ... in th ereal world, we say yo should give URIs to important recsources...
<timbl__> people have given them to dogs, and i have never felt there was a big diff between web res and other res .. not stg I feel strongly about.
<Chris> example of confusion re web resources and not web resources http://www.strangehorizons.com/2004/20040405/badger.shtml
<scribendw> TBL: This is an issue I feel strongly about. I've sometimes been a minority of one on the TAG.
<scribendw> TBL: The problem as I see it that there's a web architecture. The webarch doesn't make the philosophical distinction about whether the URI si the dog or a picture of the dog
<scribendw> TBL: In the semantic web, people never make the philosophical error of confusing the dog and hte picture of the dog
<scribendw> TBL: We're building the SemWeb architecture on top of the WebArch.
<scribendw> TBL: We have to be clean. Because we have a community of people who are web folks who are very involved in web servers and they aren't worried about the distinction, they don't see the pain.
<scribendw> TBL: Then we have people like Dublin Core using a URI without a hash to identify the concpet of a title of a book. They haven't worried about the fact that it's a kind of URI that thye would also use for a web page.
<scribendw> TBL: They've never done the recursive thing, they've never looked for the strong logical model.
<scribendw> TBL: If we try to make an architecture where everything works consistently, there's only one that I know of thta isn't in severla levels.
<DanC_> (the dublin core vocabulary predates use/mention clarifications in the RDF spec, and hence dc:title is sometimes a person and sometimes a person's name)
<DanC_> (hence? dunno if they're causally related.)
<scribendw> TBL: The thing up to the hash is a document and the stuff after the hash gives you a global idnetiifier for something that the document talks about
<scribendw> TBL: The problem is you have to go back to the Dublin Core, FOAF, and other grass roots ontologies and aks them to stop and please put in a hash.
<scribendw> TBL: I don't think we should make an inconsistnet architecture.
<scribendw> TBL: There are a lot of FOAF documents out there and it would be painful to put in a hash, but there are a lot more web pages out there.
<scribendw> SW: Can you demonstrate th einconsistency?
<scribendw> TBL: Yes, I think we're getting close with Ontoria(sp?)
<scribendw> Pointer, please!?
<scribendw> RF: The problem is you're describing a scenario where there are no ambiguous assertions.
<scribendw> RF: For example, the first example in the RDF Primer provides a URI for something that they call a "web page"
<scribendw> RF: Does that actually refer to the collection of resources that are combined to make the page, does it refer to the HTTP interface to that web server for only the initial request, ... There's a set of ambiguities associated with that use of the URI.
<scribendw> TBL: The URI identifies the web page, that's what it means and we shouldn't be ambiguoius about that
<Chris> and its ambiguous - is this the first resource you get back or all the linked ones as well
<scribendw> NM: If there's a picture in an IMG tag, that's in the resource but it's not int he thing you get back first
<Chris> as in 'the picture on this web page' URIodPage
<Chris> instead of URIofPictureLinkedFromPage
<scribendw> RF: The existing architecture has a variety of interpretations for a URI. The way to fix that is to use additional assertions to determine which on eyou mean.
<scribendw> RF: When you're using a URI and you make a request, that only refers to th einitial response that you get back.
<Chris> timbl just made the same ambiguous assertion
<scribendw> RF: for example, if I refer to my web page, it's identifying the HTML page
<scribendw> TBL: I'm saying a URI "Identifies" with a capital I, identifies may web pae.
<scribendw> TBL: You're saying that there's an HTML file that is a representation
<scribendw> The URI doesn't identify the representation
<scribendw> A diagram
<scribendw> (TBL draws a circle-and-arrow diagram)
<scribendw> RF: Tehre are multiple things that are associated with my web page that are not part of what HTTP says the URI is (???)
<scribendw> TBL: I will say that my page includes an image if I get back a representation that has an IMG tag that points tot he image
<scribendw> RF: In RDF, the way to remove the ambiguity between just the HTML page and the nentire set of responses associated with a request...
<scribendw> RF: I mean the application steady state that you get after you interpret the representation (???)
<scribendw> TBL: The image tag is just a shorthand for having the pixels in the HTML file.
<scribendw> NM: I think what RF is saying is that if you say that URI represents the home page, they don't understand the plumbing. The URI idnetifies the whole composed page. So we have to ask what it would mean to delete it or manipulate it.
<scribendw> TBL: I think of this thing (the home page) as an information bearing object
<scribendw> TBL: The TAG has to say what information it contains
<scribendw> TBL: The image is part of the resource and the message conveyed does include the picture
<scribendw> CL has some drawings too
<scribendw> CL: Suppose you have a URI that returns a frameset that contains a single HTML page.
<scribendw> CL: My point is that from a web architecture perspective, the single page and the framed page are different, but pepole will use the URI in the same way(???)
<scribendw> CL: You cannot use the URI for the HTML page and for the collection of things
<scribendw> CL: Do you need seperate URIs or not?
<scribendw> TBL: No. The set of source bits does not have a URI.
<scribendw> TBL: This is the XLink problem. It really violates the architecture by going under the covers and extracting, for example, the third paragraph of something that is "trust me" an XML page.
<scribendw> RF: We're way down a rat hole.
<scribendw> RF: If the URI has a last modified date and the last modified date of the html page and the image are different, what is the last modified date of the web page?
<scribendw> RF: One assertion is that the URI identifies the steady state you get back from retrieving all the images, stylesheets etc.
<scribendw> TBL: I call this genericity and not ambiguity.
<scribendw> RF: I can redefine the term too.
<Chris> if tim want sto talk about a collection of related resurces, for some definition of related, then he needs a different URI to do that. re-using the URI of the HTML document to also mean that collection *clearly* introduces ambiguity
<scribendw> TBL: Ambiguity is a derogitory term...
<Chris> its exactly the same ambiguity as the 'book vs whale' ambiguity
<scribendw> NW: What's the lsat modifie ddate in th eRF case?
<scribendw> TL: In this particular case, a useful function is "most reently modified of all the things you got"
<scribendw> TL: Including th edates of the specs!
<scribendw> NM: It seems that the essense of what we're thrashing on is that some resources have a compound nature.
<DanC_> (Roy, which was the more realistic example?)
<DanC_> (oh... a compound doc?)
<Roy> (on board)
<scribendw> NM: In the case where we have compound resources, there are the separate pieces and and the collection. To a human, the composition has certain real world characteristics.
<Roy> Iq+
<scribendw> NM: What I'm trying to get to is, we potentially have operations that we could apply to any of the components
<scribendw> NM: You could do it any of the n+1 ways
<scribendw> NM: If I send a delete to the HTML page, it gets a bit more squirrly. If I send DEL to the URI of the HTML page, do I delete the page or the components of the composition
<Chris> especially if some of those components are shared; do they get deleted or not
<scribendw> NM: I'm not saying which things should have a convenient URI, but from a long way back, it looks like there are n+1 interesting things here
<scribendw> RF: The turnaround point for this example is that we know the semantic web does not break on this.
<scribendw> RF: Because we define "web page" to mean the composition of the things we get
<DanC_> (I don't know that. I'd prefer that Roy speak for Roy)
<scribendw> RF: Because RDF has the ability to do that, it's just as applicable to URIs that refer to real world objects as it is to web pages
<scribendw> TBL: My point is that RDF doesn't care anything about wha tyou get from the URI it just has the collection of statements
<scribendw> TBL: People are using URIs (without hashes) to say that the URI has such a birthday.
<scribendw> TBL: And someone else says it (the RDF document) has a copyright.
<scribendw> TBL: And then someone else says that htings that have birthdays don't have copyrights and you ahve a conflict
<scribendw> TBL: Supposing the abstract thing is not a dog but another web page. Then you can't tell from the predicate what resource it applies to.
<scribendw> RF: You have to add predicates to disambiguate the use your doing
<scribendw> TBL: We can construct the client so that you don't have to make those extra assertions
<scribendw> TBL: The HTTP module is built to give you information back, if we don't draw a model fo this where thta's whta we say the URI identifies, that you have to stop and ask if that' swhat the URI identifies, then we end up with a big inconsistent mess. It's not an architecture I find useful.
<scribendw> SW: This (pointing to the diagram) isn't a complicated situation. The web page is a resource, the HTML page is a resource, and there seems to be some resource that is the composition of those resources.
<scribendw> SW: You could almost talk about the relationships
<scribendw> RF: We're talking about what does the URI mean. When you pass it to a cache, it means one and only one thing, the sequence of bits.
<scribendw> TBL: The cache knows that it's got a representation of something
<scribendw> RF: What I'm trying to say is that it doesn't include the external image.
<scribendw> TBL: The semantic web doesn't work if two groups use the same URI in different ways and someone tries to disambigute with additional predicates
<scribendw> Scribe stops trying to keep up
<Zakim> DanC_, you wanted to offer http://esw.w3.org/topic/HashSlashDuality#preview
<scribendw> Can we use DanC's HashSlashDuality text in the webarch document, in a finding that addresses httpRange-14?
<scribendw> Unclear.
<Chris> I assumed that was why we were talking about it, yes
<scribendw> Review of http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0057.html
<scribendw> (We're moving on)
<DanC_> I find it ( http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0057.html) appealing, but I can't think of any arguments that should persuade Roy