See also: IRC log
<paulc> Information resources and HTTPRange-14 discussions continues
<paulc> Norm: Here is a rewrite of section 31. "Information Resources and Representations" for your review
<Stuart> [aside Norm projects]
<paulc> TimBl: we need to modify the sentence "There is nothing about the content of this doucment that cannot be principle be transfered in a representation."
<paulc> Noah: concerned about "That is, given enought bits of information, it is possible to convey everything about an information resource."
<paulc> DanC: I would prefer this text start with something motivational.
<Zakim> DanC_, you wanted to suggest starting with motivation rather than dividing the world
<Stuart> scribe Paul
<Stuart> chair Stuart
<paulc> Stuart: I wonder if this text is getting concensus.
<DanC_> I wasn't kidding about the I18N WG having asked us to change Oaxaca on the basis of pronouncability http://lists.w3.org/Archives/Public/public-webarch-comments/2004JanMar/1060.html
<paulc> Roy: It will require a lot of changes since people have pointed to many words that need to be changed.
<paulc> Roy: What is the distinction that this section is trying to make.
<paulc> Roy: We define the term "information resource" but I don't believe the document uses this definition.
<timbl_> http://www.w3.org/2001/tag/webarch/
<paulc> Re: Oaxaca Would changing it to Ushuaia work?
<paulc> TimBL: (doing a search) There are uses of the term in the namespace document discussion.
<paulc> TimBL: There other 10-12 uses of the term.
<paulc> Roy: Patrick S said that our previous defn of "information resouce" did not match what TimBL and others were saying. He suggested we use "Web resource" instead.
<paulc> DanC and Roy: discussion of what is an "information resource" and what is not.
<paulc> TimBL: what is distinction between atoms and bits.
<paulc> Roy: I need a motivation for the need for a definition of "information resource".
<paulc> TimBL: at the core of this is the HTTPRange-14 issue.
<paulc> Roy: The rationale for the division has to be in the document.
<paulc> Norm: A re-drafted Section 3.1.1 Identifying Information Resources might give this rationale.
<paulc> Norm: (projecting a draft Section 3.1.1)
<paulc> Norm: draft text is based on the hash versus slash held earlier in the meeting.
<DanC_> "by the nature of the URI" doesn't appeal to me
<paulc> Noah: why does "information resource" only occur in the first para of this proposed text.
<paulc> Stuart: this text confuses "document" and "information resource"
<paulc> Roy: this text does not motivate the need for the definition of "information resource"
<timbl_> Tim: I think one could write something indicating that "document" we mean "information resource".
<paulc> Stuart: Let's go back to 3.1 discussion.
<paulc> Noah: Let's discuss Roy's problem with the motivation.
<paulc> Noah: Time varying of something is a problem.
<paulc> Norm: Tim, you said that only information resources have representations. Did you mean this?
<paulc> TimBL: (draws figure on flip chart to explain his point of view)
<paulc> Roy: The problem I have is that we have this elaborate diagram and elaborate definition to describe how HTTP work but it does not work that way.
<paulc> Roy and TimBL continue to disagree about HTTPRange-14.
<paulc> Paul: Maybe we should have used the term "web resource" as suggested by Chris and Paul yesterday and day before.
<paulc> Paul: I suggest we start striking text from the WebArch instead of adding more and more text that we all disagree on.
Noah has suggested in response to Paul: the term "web" is very important. If we use the term "web resource" then we are indirectly implying that the Semantic Web, and other systems built of URIs, are not "on the web" and that our architecture document does not apply to them.
<paulc> Roy: It is possible that a rationale could be provided for the distinction between "information resource" and what is not a "information resource".
<DanC_> "rationale" is the word I didn't hear
<paulc> Roy: and why this distinction is important.
<paulc> Roy: It is fine with me if the rationale and definition in the document since that will permit us a public review of the material.
<paulc> Roy: The rationale MUST be provided in the document.
<paulc> Stuart; Quoting TimBL "Only information resources of representations."
<timbl_> [Chris enters]
<Zakim> timbl_, you wanted to disagree that the question of whether or not something is "on the web" hlps with HTTP-range-14, and the Information Resource. Can a dog be on the web?
<paulc> Stuart: We need some suggestions on what to do with the WebArch document and we probably need a break.
<paulc> TimBL: We cannot talk about only representations - we need a term like "information resource".
<DanC_> 3rd para is "Other resources, such as cars and dogs..."
<paulc> Chris: I like the projected text written by Norm for section 3.1.
<paulc> Chris: This is better than what we had yeserday. I no longer object to combining "information resource" with this approach.
<timbl_> TimBL: Much of the arch doc, most of section 3 and all of section 4, is to do with Information Resources only - not dogs. We are dealing with what for most people is a web of documents and we can't define 'document", like trying to define email architectruie without defining the concept of "message".
<DanC_> [norm, there are now enough references to "this text" in the record that the meeting record will be incomplete without a copy of it somewhere; checking it in seems easiest to me, but if mailing it to www-archive or something seems easier to you, very well.]
<Norm> This text is now available at http://www.w3.org/2001/tag/2004/webarch-20040928/Infosrc-rewrite.html
<paulc> Can someone please give the link to the Last Call comments status?
<DanC_> Last Call Comment Status
<DanC_> Last Call Comment Status $Revision: 1.108 $ of $Date: 2004/10/07 16:14:34 $ http://www.w3.org/2001/tag/2004lc/lc-status-report.html
<paulc> Stuart: let's do the following items:
<paulc> a) plan for extensibility and versioning finding work
<paulc> b) Responses from Last Call commenters during the meeting
<DanC_> http://www.w3.org/2001/tag/issues.html?type=1#HTTPSubstrate-16
<paulc> c) HTTPSubstrate-16 progress?
<paulc> Extensibility and Versionsing discussion:
<paulc> DanC: Bonus points if the finding is 5 pages or less
<paulc> Norm: I will report back but a new draft in Oct is much better than one in Dec since Nov is so busy.
<DanC_> Noah noted, re Schema WG liaison, that he participates there. DanC nominated Noah as liaison from TAG to XML Schema WG
<paulc> Noah: What is the relationship between E&V and the WebArch document.
<paulc> PaulC: The subsequent work on E&V is not (in my view) on the critical path for a WebArch PR.
<paulc> Norm: Let's get going on getting XML Schema engaged in this area.
<paulc> Norm: David is doing the heavy lifting currently and we need to ensure he is aware of the Noah message on this topic.
<paulc> ACTION: Norm to report workplan and dates for E&V work.
<paulc> b) Responses from Last Call commenters
<paulc> Tim Bray's responses:
<paulc> http://lists.w3.org/Archives/Member/tag/2004Oct/0019.html
<paulc> Section 3.2.1:
Paul asked for a link to my mail to the TAG on versioning. The primary link is http://lists.w3.org/Archives/Public/www-tag/2004Aug/0010.html . The HTML causes font problems for some browsers, appraently. A link with pure text is at: http://lists.w3.org/Archives/Public/www-tag/2004Aug/0009.html .
<paulc> Norm: the text on URI collision does appear to be wrong.
The above links are for the emails sent to the TAG. The whitepaper itself is at: http://lists.w3.org/Archives/Public/www-tag/2004Aug/att-0010/NRMVersioningProposal.html .
<paulc> The text "If rep communicates the state of the resource inaccurately, this inaccuracy or ambiguity may lead to URI collision"
<paulc> needs to be modified or deleted.
<paulc> Editor will fix this.
<paulc> Section 3.6.2:
<paulc> TimBray: about "exceptional circumstances" is wrong
<paulc> Editor to add an example and check with Tim.
<paulc> TimBray: "I think they fail to achieve both the conditions specified as good in namespace documents"
<paulc> Norm: Tim disagrees with our text and we are not likely to convince him otherwise.
<paulc> DanC: I have looked at Tim's justification and would like to accept Norm's suggestion that we inform him we are not making changes.
<paulc> Section 4.6
<paulc> Norm: We have made changes and Norm will check to see if they make Tim happy.
<paulc> Finished with Tim's comments.
<paulc> Issue on primary and secondary resources:
<DanC_> # Representation of a secondary resource?
<DanC_> * 2004-09-21T15:54:05Z from jacek.kopecky
<DanC_> # Representation of a secondary resource?
<DanC_> * 2004-09-21T15:54:05Z from jacek.kopecky
<DanC_> # Representation of a secondary resource?
<DanC_> * 2004-09-21T15:54:05Z from jacek.kopecky
<DanC_> # Representation of a secondary resource?
<DanC_> * 2004-09-21T15:54:05Z from jacek.kopecky
<DanC_> Representation of a secondary resource? 2004-09-21T15:54:05Z from jacek.kopecky http://www.w3.org/mid/1095782045.2943.125.camel@Kalb
<paulc> Norm: (projecting revised text)
<paulc> "The terms primary and secondary in this context do not limit the nature of the resource. In this context, primary and secondary simply indicate that there is a relationship between the resources. A secondary resource is by definition one that is identified with respect to some primary resource."
<paulc> "Any resource that can be identified can be identified as a primary resource or a secondary resource. A given resource may be identified as a primary resource through multiple URIS and it may be identified as a secondary resource through multiple URIs."
<DanC_> tim, primary/secondary has *nothing to do* with information resource.
<DanC_> (I remember yesterday's discussion differently. Whee!)
<Roy> [URI] The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations.
<Zakim> timbl_, you wanted to object to "Any resource can be identified as a primary resource" on the basis that if a resource has secondary resources it must be an information resource.
<DanC_> TimBL and Noah discuss relationship between fragment identifiers and documents.
<Zakim> DanC_, you wanted to note that semantic web isn't the only one using #-uris for lots of things; see abstractCompnentRefs-37, WSDL, etc.
<timbl_> Noah: When the semantic web usus u#f to identify a dog, does it then conjoure up dsome document <u> ?
<Stuart> From Roy:
<timbl_> Tim: yes - the document <u> may be imaginary but it good proactice for it to be avialbel online.
<Stuart> [URI] The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations.
<Norm> ping?
<Roy> The terms primary and secondary in this context do not limit the nature of the resource --- they are not classes. In this context, primary and secondary simply indicate that there is a relationship between the resources for the purposes of one URI: a URI with a fragment identifier.
<Roy> Any resource that can be identified can be identified as a secondary resource might also be identified as a primary resource through some other URI, and a resource may be identified second-hand via multiple URIs. The purpose of these terms is to enable discussion of the relationship between such resources, not to limit the nature of a resource.
<DanC_> (again, I think this can't be done well without a figure)
<timbl_> How about: Any resource that can be identified can be identified as a secondary resource might also be identified through some other URI, and a resource may be identified second-hand via multiple URIs. Ã' The purpose of these terms is to enable discussion of the relationship between such resources, not to limit the nature of a resource.
<DanC_> "that can be identified" is superfluous
<pbc> I agree with Dan: a picture would be very very useful here.
<DanC_> timbl: "that can be identified" is a cut/paste error...
<Roy> Any resource that can be identified can be identified as a secondary resource might also be identified using some other URI without a fragment, and likewise resource may be secondarily identified via multiple URIs (each with their own reference to the same resource). The purpose of these terms is to enable discussion of the relationship between such resources, not to limit the nature of a resource.
<timbl_> How about: Any resource that can be identified as a secondary resource might also be identified through some other URI, and a resource may be identified via multiple URIs with fragment identifiers. Ã' The purpose of these terms is to enable discussion of the relationship between such resources, not to limit the nature of a resource.
<pbc> Any resource that can be identified as a secondary resource might also be idenfieid through one or more URIs not containing a fragment identifier.
<DanC_> rf: eg. rdf doc available at U1 and U2, then for any U1#foo, there's also a U2#foo that means the same thing
<timbl_> +1 to Norm's text
<DanC_> +1 to Norm's projected text
<DanC_> RF: this is pretty much what I proposed
<Roy> +1
<Norm> The terms ?primary? and ?secondary? in this context do not limit the nature of the resource?they are not classes. In this context, primary and secondary simply indicate that there is a relationship between the resources for the purposes of one URI: a URI with a fragment identifier. Any resource can be identified as a secondary resource. It might also be identified as a primary resource through some other URI, and a resource may be identified as a secon
<Norm> dary resource via multiple URIs. The purpose of these terms is to enable discussion of the relationship between such resources, not to limit the nature of a resource.
<timbl_> ________
<Norm> The terms ?primary? and ?secondary? in this context do not limit the nature of the resource?they are not classes. In this context, primary and secondary simply indicate that there is a relationship between the resources for the purposes of one URI: a URI with a fragment identifier. Any resource can be identified as a secondary resource. It might also be identified using a URI without a fragment identifier, and a resource may be identified as a secondar
<Norm> y resource via multiple URIs. The purpose of these terms is to enable discussion of the relationship between such resources, not to limit the nature of a resource.
<DanC_> +1 to the revision with "without a fragment identifier"
<timbl_> +1
<DanC_> PaulC: "it" doesn't clearly refer
<DanC_> RF: s/. It/and/
<DanC_> PaulC: I think this could use some editorial work, but I think I can agree to this.
<DanC_> so RESOLVED.
<pbc> Proposal: accept this material to resolve the comment.
<pbc> Adopted unanimously.
<pbc> ACTION: Dan to reply to commenter re primary and secondary resources.
<pbc> c) HTTPSubstrate-16
<Norm> http://www.w3.org/2001/tag/issues.html?type=1#HTTPSubstrate-16
<pbc> ACTION: update status of HTTPSubstrate-16 to include Ottawa action on Dan to stir the pot e.g. find someone to help write an opposing RFC.
<timbl_> '
<pbc> PaulC: I recommend that Dan execute on his Ottawa assigned action item.
<Zakim> DanC_, you wanted to note with regret that the records of the last ftf that I can find *don't* give specific technical issues with RFC3205
<Roy> PC: I think we should execute the action item
<Stuart> : http://www.w3.org/mid/33D970235519324D988AFFDE7EA2E24C028FEA95@RED-MSG-41.redmond.corp.microsoft.com
<pbc> http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0061.html
<timbl_> b
<pbc> Dan: It seems then that I should do the Ottawa action item.
<pbc> Resolved to continue Dan's Action item.
<DanC_> ACTION DanC: recruit someone to write a counterpoint to RFC3205 CONTINUES.
<pbc> What should the editor do with the information resources proposed text?
<pbc> Meeting recessed for lunch.
<scribe> scribe: noah
The TAG thanks Day Software for a terrific job of hosting our meeting, and for supporting Roy Fielding's participation in the TAG!
NW: We're missing what Roy requested on Information Resource rationale.
RF: Right. I'm OK with your putting in whatever you want on Information Resource, but want rationale
CL: Retrieval etc. don't apply to dogs
<Chris> CL: One motivation - response codes, representations, GET not PUT applies to InfoRes and does not apply to dogs and elephants
TBL: Also content negotiation.
NW: 3.1.1 ties the Information resource heading to the # issue.
NM: It may be trying, but it switches from the "info resource" to "document" terminology
NW: Best attempt given consensus as of last night.
TBL: 3.1.1 is not one section. Would like a header of ahead of paragraph starting "Some parties"
NW: Editing in realtime. Watch for errors.
Some discussion in answer to Noah question leading to (tentative agreement that):
For purposes of 3.1.1 and subsections, the word "document" should be replaced by "Inforrmation Resource". Change made in realtime.
SW: Please propose rationale for why Info Resource called out
<Chris> Proposal: Its is clear that the universe of resources is larger than the universe of resources that have electronic representations, can be interacted with via propocols, and exchange informations. To make it clear when we are referring to the smaller set we use the term information resurce
<Chris> Proposal: Its is clear that the universe of resources is larger than the set of resources that have electronic representations, can be interactied with via propocols, and exchange informations. To make it clear when we are referring to the smaller set we use the term information resurce
RF: that's an assumption, not rationale
<Chris> RF: which set is larger is not material to the current argument
TBL: rationale depends
on whom you're convincing
... one rationale: the word resource is the universal set,
therefore anything, therefore saying it's a resource carries no
information. We could replace "resource" with "thing". You would
find that unhelpful.
<Chris> Proposal 3: To be clear when we refer to the set of resources that have electronic representations, can be interactied with via protocols, and exchange representations, we use the term information resurce.
TBL: Often, you are out of habit using the term "resource" for something narrower.
RF: OK, but phrase it
for the reader.
... you're not describing my position correctly.
... please describe what you TBL need from those definitions,
independent of reader.
TBL: don't think you need rationale for introducing a definition. Why here?
DC: This one is special (I infer he means controversial...{scribe})
<DanC_> "this is an important concept in the document", said timbl. I think that's only the case if you take your position, timbl. If you take the position that only information resources can have representations, then there's a connection. But Roy's asking _why make that connection_.
<DanC_> I think
<Chris> Proposal 3 (modulo correct spelling)
NM: Maybe we have to resolve HTTPRange. If we decide Tim is right on HTTP range then the rationale is: "Widely deployed protocols such as HTTP range are appropriately used with only a subset of the resources nameable with URIs. These we call Info Resources."
Discussing Chris proposal: " Its is clear that the universe of resources is larger than the set of resources that have electronic representations, can be interactied with via propocols, and exchange informations. To make it clear when we are referring to the smaller set we use the term information resurce
<noah>
TBL: I'm not sure this does it.
NW: Why do only electronic things have ability to interact via protocols.
<Norm> Electronic things here meaning "bag of bits" not computerized machinery
TBL: When you use "representation" the way Roy and others have, you cannot distinguish IR from others. Resource is unknowable.
<Chris> Chris: I understand Roys position to be that a reasouce is unknowable. Facets of it can be observed by examining its representations, if it offers any. These observations do not define in total the resource. Correct, Roy? (If not please clarify in a few sentences)
<Roy> The resource can also be described by other means, such as RDF
<timbl_> Noah: If I have a dog whose uri has a #, then is there a way I can access informationm about the dog?
<timbl_> Tim: yes, access the 'stem' resource is special (that which has a URI with eth frag id and # stripped off)
NM: If you believe HTTP to directly address a dog, you can get it's temperature from Get. If HTTP is only for Info Resrouce, then my dog is not something in which you can do a get.
TBL: right. You could use RDF to find a statement that some other http resource offers the temperature of http://animalcollection#dog. You CANNOT do a GET on that secondary resource.
RF: ... Normally people
use HTTP URIs to identify things whether they are discussing things
literally on the web, or else to refer to a non-Info Resource (I.e.
Except for situations where you are using a URI to identify a
proxy,)
... on the web, you don't know what a URI means without something
like RDF
... I'm uncomfortable saying "this is a document because they used
http: uri"
TBL: you're rationale
is that people misuse terms, but here we're doing architecture.
... you mean in identify in common parlance to user.
RF: yes
TBL: we could talk about both, but should do so clearly.
DC: Concur, informal
references work in informal discourse. Doesn't work in WSDL or
RDF.
... You haven't tripped over using wrong number of "*" in a C
program?
RF: yeah, but you can figure it out.
<timbl_> DanC: If you buolkd an RDF system including data in which people have used teh same URI for distinct things, you get a problem.
<DanC_> "systems gain in rigor" -- NM
<timbl_> Roy: yes, a collision at best. A problem.
RF: HTTP has mechanisms that allow HTTP to be a gateway to the rest of the universe.
<Norm> Noah's example of the phone number is an interesting analogy
NM: No. There are systems that home heating systems by dialing a phone number. That's not a good reason for saying that the specs for the phone network should name heating systems. Phone numbers name endpoints in the phone system, typically but not always telephones. Higher level specs can indeed license the inference that a phone number is a proxy or label for a heating system, but >the specification for the phone system should not<.
<Zakim> DanC_, you wanted to concur that it does work in informal discourse; it doesn't work in WSDL or RDF or other formal systems, and there's something of a spectrum. I hope we find
DC: still think we should take HTTP Range off the critical path for this version of the document.
TBL: We have issues?
DC: Only in relation to the stuff I want to pull.
NW: Agree. Could pull Info Resource term. Would not harm this version of this document now.
<DanC_> DC: I agree that the range of the identification function for hash-less http URIs should be information resources, as an intuition about how we should build the web going forward, but I don't have a convincing or even compelling justification for it, ...
<timbl_> Noah: We can't only use "resource" as 'information" resource ---- because we all agree that URRIs can in general identify things which are not IRs. This spec should be an architecture for everything identified by a URI
<DanC_> ... but for the rest of this version of webarch, the principles and boxes are largely justified in ways that I can use effectively in community discussions. Putting any part of the httpRange discussion in this document results in long, long discussions. Let's please punt it 'till the next version so we can get to REC this year.
<DanC_> (that is: DanC: ... but for ...)
<Roy> I don't think that a distinction buys us anything -- what does it buy? Write that in the document and there is a resolution.
SW: satisfied to go back to last call text.
NW: Understand Info Resource and learned some. Don't like last call version.
NM: I think there are 2 proposals: back to LC draft and pull all reference to Info Resources.
Various: right, both are in play.
RF: Uh...we were making progress. Why stop now?
DC: OK, don't slow down for me.
SW: Roy, what do you want?
RF: I'm OK with including your version of the conclusions. Please be sure to tell the reader why we did this.
SW: any ideas what next?
TBL: Do you need HTTP Range.
RF: More might be better, but all I need is enough of HTTP range to rationalize it.
NM: another rationale, independent of HTTP is "There is confusion about the range of things that URIs name. We make clear that URIs are useable to name real world objects as well as what we call Information Resources (I.e. the thing computer hackers are tempted to believe are "on the web")" That's a potential rationale that's independent of HTTP.
TBL: Noah's section might belong in 2.2.
NM: OK with me.
TBL: I meant the rationale is already in 2.2.
NM: All the better. The question is does Roy accept as rationale. I've never had a problem.
<timbl_> Suggested text in addition to 3.1.1.1 The TAG takes the view that this assumption is valid. Web technology has used http: URIs to identify information resources. To use an http: hashless URI to identify abstract properties such as RDF properties is an error, as it overloads a URI which others might justifyably use to identify a web page.
<timbl_> Suggested text in addition to 3.1.1.2. [The TAG takes the view that] this assumption is invalid. The semantics of a fragment identifier are a function of the Internet Content TYpe of any representation associated with the stem resource. For example, RDF uses URIs with hashes to identify real-world objects.
Norm offers text that we are discussing:
<Norm> By design a URI identifies one resource. We do not limit the scope of what might be a resource. The term "resource" is used in a general sense for whatever might be identified by a URI. It is conventional on the hypertext web to describe web pages, images, product catalogs, etc. as ?resources?. The distinguishing characteristic of these resources is that all of their essential characteristics can be conveyed in a message. We identify this set as ?informati
<Norm> on resources?.
<Norm> This document is an example of an information resource. It consists of words and punctuation symbols and graphics and other artifacts that can be encoded, with varying degrees of fidelity, into a sequence of bits. There is nothing about the essential information content of this document that cannot in principle be transfered in a representation.
<Norm> However, our use of the term resource is intentionally more broad. Other things, such as cars and dogs (and, if you?ve printed this document on physical sheets of paper, the artifact that you are holding in your hand), are resources too. They are not information resources, however, because their essence is not information. Although it is possible to describe a great many things about a car or a dog in a sequence of bits, and to serve those bits as representati
<Norm> ons of that resource, the sum of those things will invariably be an approximation of the essential character of the resource.
There has been general agreement, except with the phrase: Although it is possible to describe a great many things about a car or a dog in a sequence of bits, and to serve those bits as representati
<Norm> ons of that resource, the sum of those things will invariably be an approximation of the essential character of the resource.
Try that again: There has been general agreement, except with the phrase: Although it is possible to describe a great many things about a car or a dog in a sequence of bits, and to serve those bits as representations of that resource, the sum of those things will invariably be an approximation of the essential character of the resource.
NW: Proposal to delete
problematic phrase, leaving: Although it is possible to describe a
great many things about a car or a dog in a sequence of bits, the
sum of those things will invariably be an approximation of the
essential character of the resource.
... editor may fix the word "things"
TBL: why a problem?
SW: might be confusion that "thing"=="resource"
NW: as I say, I'll try for better.
RF: OK, where's the rationale?
NW: disappointed,
thought the first para implies "because you would have been tempted
to thing the web was smaller than you might have thought"
... not good enough for you?
RF: don't think so
TBL: answer is in: " It is conventional on the hypertext web to describe web pages, images, product catalogs, etc. as "resources". The distinguishing characteristic of these resources is that all of their essential characteristics can be conveyed in a message. We identify this set as "information resources". "
RF: You still aren't saying "this is the reason"
NW: I'll say it's a rhetorical device, OK?
RF: OK, that does it for me?
TBL: you really need that, is it rhetorical?
<timbl_> The term "information resource" is introduced as well a "resource" because both concepts are need in this document.
<DanC_> NM: how about "because we observe these terms are useful in discussion of web technologies and may be useful in development of emerging and future technologies."
<DanC_> NM: how about "because we observe these terms are useful in discussion of web technologies and may be useful in specification of emerging and future technologies."
Norm edits again:
<Norm> Proposed as a replacement for 3.1 in 2.2:
<Norm> By design a URI identifies one resource. We do not limit the scope of what might be a resource. The term "resource" is used in a general sense for whatever might be identified by a URI. It is conventional on the hypertext web to describe web pages, images, product catalogs, etc. as ?resources?. The distinguishing characteristic of these resources is that all of their essential characteristics can be conveyed in a message. We identify this set as ?informati
<Norm> on resources?.
<Norm> This document is an example of an information resource. It consists of words and punctuation symbols and graphics and other artifacts that can be encoded, with varying degrees of fidelity, into a sequence of bits. There is nothing about the essential information content of this document that cannot in principle be transfered in a representation.
<Norm> However, our use of the term resource is intentionally more broad. Other things, such as cars and dogs (and, if you?ve printed this document on physical sheets of paper, the artifact that you are holding in your hand), are resources too. They are not information resources, however, because their essence is not information. Although it is possible to describe a great many things about a car or a dog in a sequence of bits, the sum of those things will invariably
<Norm> be an approximation of the essential character of the resource.
<Norm> We define the term ?information resource? because we observe that it is useful in discussions of web technology and may be useful in constructing specifications for facilities built for use on the web.
SW: PROPOSAL to accept the above.
AGREED without dissent.
<Chris> Champagne, rose petals, etc
<scribe> ACTION: Stuart to respond to Pat Hayes, Patrick Stickler and Sandro Hawke giving proposed resolution of Information Resource
NW: reports new text
now checked in as editors' copy
... Proposal to drop 2.2.1 "The Range of URI Schemes" and
subsections from V1. We've shown we don't need it to motivate
"Information Resource"
SW: do we need an explicit statement on not closing "/" vs "#"
NW: httpRange-14 remains open
SW: some people felt document caused confusion.
NW: I posit problematic sections gone, let's remove and see if anyone wants it back.
DC: It was acceptable, let's do a straw poll.
CL: If removed, could it show up finding.
General agreement.
CL: I think it's valuable, don't want to lose it.
Straw poll:
Prefer keeping: 1
Prefer out: 5
Object to out: none
<DanC_> ACTION: DanC, with Norm, develop a finding on httpRange-14 starting with the HashSlashDuality text, which we just advised the editor to take out
PROPOSAL: Remove section 2.2.1 and descendants and use as input to finding on httpRange-14
AGREED without dissent.
<Norm> Note that the reference to 2.2.1 may be confusing as it is only 2.2.1 in the editorial draft under discussion at this meeting, it is *explcitly not* the text of 2.2.1 from the LC draft.
<DanC_> abstaining: Berners-Lee
ABSTENTION: DC, TBL
SW: Does the editor need other text reviewed?
NW: don't think so
DC: glossary? decaying?
NW: Built automatically, have paid some attention.
Some discussion of specific terms.
DC: as long as you're paying attention
SW: Summary, we're
about ready to give something to all of our commentors.
... Have near final editors' drafts on text for most areas.
... What's up next?
CL: either do a "it's
near PR draft" or an "it's a PR draft"
... PR would be a suprise to most people
RF: do a public draft
<DanC_> NM: I think aiming the "representations aren't necessarily 8-bit octets" action for the 18Oct telcon is a good idea
NM: Will attempt to do his action of Tues, to prepare a draft for Oct. 18 document.
<timbl_> The use of octet streamsis a Constraint.
<timbl_> "n the design of the Web, some design choices, like the names of the p and li elements in HTML, the choice of the colon (:) character in URIs, or grouping bits into eight-bit units (octets), are somewhat arbitrary; if paragraph had been chosen instead of p or asterisk (*) instead of colon, the large-scale result would, most likely, have been the same. "
<timbl_> It says that the choice was arbitrarty.
<timbl_> Do you not think the document imlplies that if there were a non-arbitrary reason for doing otherwise trhen a constraint could be relaxed?
<timbl_> I just wante dto point you at the exiting thinking about his sort of question.
<timbl_> I'll look forward to our draft.
Schedule
<Norm> ACTION: Norm to produce an editor's draft by 14 Oct (COB EDT)
<DanC_> ACTION DanC: draft a request for proposed recommendation, based on Norm's draft ...
Noah to provide branch draft on representations by 10/18. Action was recorded without date on Tues, so no new action enterred.
RF: What's next meeting about?
Various: hopefully, thinking about next version of the Arch document.
<DanC_> 18 Nov - 6 Dec 2004
<DanC_> publication moratorium around W3C AC meeting
<DanC_> NM: I'm at risk for the 18Oct telcon, due to plane flight landing 1 hour before TAG telcon
<DanC_> 20 Dec 2004 - 4 Jan 2005
<DanC_> publication moratorium around W3C AC meeting
<scribe> ACTION: Chris to cause draft of press release to happen
<DanC_> ACTION DanC: bring webarch 9Dec2003 to next meeting with Stuart
Long discussion resulting in proposed aggressive pub schedule.
<Roy> Jean-Michel Pittet
Norm is mailing and is posting below:
<Norm> 18 Oct
<Norm> NW to provide Editor's Draft
<Norm> NM to provide branch (NM at risk)
<Norm> DC to produce PR request (at risk)
<Norm> 25 Oct
<Norm> Decide to go to PR
<Norm> 01 Nov
<Norm> Director's Decision telcon
<Norm> Would like to be there: CL, SW, TBL
<Norm> 05 Nov
<Norm> i's dotted, t's crossed
<Norm> Publication as a PR draft
<Norm> Call for testimonials
<Norm> 18 Nov - 06 Dec
<Norm> Blackout
<Norm> 08 Dec
<Norm> AC Reviews due (05 Nov plus four weeks and a few days)
<Norm> Testimonials due
The tag records its thanks to Jean-Michel Pittet
<Norm> 13 Dec
<Norm> i's dotted, t's crossed
<Norm> 14 Dec
<Norm> REC published
<Norm> Press release
<Norm> 25 Dec
<Norm> Connolly family dine's on PC's Cotton nickle
