W3C | TAG | Previous: 12-14 May FTF | Next: 7 June

Minutes of 24 May 2004 TAG teleconference

Nearby: Teleconference details · issues list (handling new issues)· www-tag archive

1. Administrative

  1. Roll call: SW (Chair), TBL, RF, DC, NW, IJ, MJ. Regrets: PC, CL
  2. The TAG did not yet accept the minutes of the 12-14 May F2F
  3. Accepted this agenda
  4. Resolved: Next meeting: 7 June. 31 May 2004 meeting canceled.

1.1 Feedback from May AC Meeting and WWW 2004 in New York

  1. Comments/Observations from TAG participants at these meetings.

[IanJ]

DC: PC and I presented the TAG slides to the AC; no real feedback. I presented IJ's slides at www2004. Quite a few people in the room (though opposite another interesting session). I'm pretty sure there was no substantive feedback.

1.2 Future F2F Meetings

  1. 9-11 August Ottawa [Already confirmed]
  2. Proposals for F2F meeting venue in 5-7 October in Europe
  3. Covering AC Meeting 1-3 November. Schedule a TAG ftf?

    Likely to attend: IJ, TBL, SW, MJ

    Likely regrets: DC, NW

    No decision.

1.3 TAG Charter

Action IJ 2004/12/14: Organize meeting between some of AB and some of TAG and Danny Weitzner to discuss patent policy and W3C charter.

IJ: I have started to plan this for 26 May.

2. Technical

See also open actions by owner and open issues.

2.1 Review of Action Item proposals

  1. Marking Operations Safe in WSDL

    Resolved: Completed action SW 2004/04/26: Thank the WSDL WG for what they've done so far, ask them to explain a bit about what can go wrong, encourage them to put it in the test suite. (proposal)

  2. URIEquivalence-15: When are two URI variants considered equivalent?

    Resolved: Completed action SW 2003/06/30 Track RFC2396bis where Tim Bray text has been integrated. Comment within the IETF process. (proposal)

Action IJ: Announce the closure of issue URIEquivalence-15.

2.2 httpRange-14 status

[IanJ]

Two messages regarding text for httpRange-14 were sent:
  1. TBL (to IJ and RF?)
  2. Response from Roy
TBL: I sent to IJ; I think I'm done.
DC: But it was supposed to be a proposal to the group.
[We review RF's notes]

TBL ok with the following changes suggested by RF:

  1. s/object/resource
  2. "...except that they be able to support (potentially)..."
  3. s/which/that/
  4. s/have/name
TBL: If someone were to create a service where one could POST to a light switch but couldn't do GET, would that be a ...[scribe missed].
RF: The thing about the info space is that any of the scripts can be instructed to use the info space; it's just that some do not.: Resources that accept POST and nothing else and don't provide Content-Location links are not using the info space.
TBL: Yes, you're right. It's not that systems that use POST don't use the info space; it's that systems that use POST and not GET do not typically use the info space. Originally, POST used to add to a collection. So, one CAN use POST to add to the information space. But it's not typically used that way in practice.
RF: there are also ways to use POST with Content-Location.
IJ: I think it's useful to say that explicitly in the text.
TBL: Compare with NNTP and point out that typically people don't do this; resources that use POST without those semantics and don't support GET are not really participating in the information space architecture.
RF: I think that Pat's comment was already addressed by changes to the URI spec.
TBL: I think that the set of resources is an unknowable set. You can say that when a URI names something, then the URI is a thing. But whether something is unnamed is untestable.
RF: Everything is a resource when it's usable by a system of some kind.
TBL: I can't test whether something is a resource or not. The set of "things" and the set of "Resources" are both infinite.
NW: I've been thinking about DC's earlier question about whether we have closed this issue. I think that until we have the concrete text for closing the issue, and we've had public review of it, I'd be unwilling to close the issue.
[Zakim]
Stuart, you wanted to ask whether resources only have to be capable of bearing a name or being described
[IanJ]
RF: Every definition of resource proposed that has been proposed has raised objections.
SW: Something can go from not being a resource to being a resource by giving it a name or description.
[mario]
c.f. 2396bis-05: Resource: Anything that has been named or described can be a resource.
[IanJ]
RF: the important thing is that a resource is not necessarily a resource for all systems.
[Zakim]
DanC_, you wanted to say "everything is a resource" is true
[IanJ]
[Discussion of whether "everything is a resource" or "everything is a resource once it has been named or described"]
DC: I'd like TBL to write everything down in final form so we can agree to it.
TBL: I think that "everything is a resource once it has been named or described" is contrary to published Recs and a philosophically untenable position since untestable.
[DanC_]
[[ The things denoted are called 'resources', following [RFC 2396], but no assumptions are made here about the nature of resources; 'resource' is treated here as synonymous with 'entity', i.e. as a generic term for anything in the universe of discourse. ]] -- http://www.w3.org/TR/rdf-mt/
[IanJ]
RF: This formulation is a specific response to "Can something be a resource if it's never been named?"
TBL: The impractical question of whether anybody has named the thing is one which is not very useful. The useful concept is the universal space of everything.
DC: I think it's responsive to PH's concerns to distinguish "information resource".
TBL: Self-referential to say that the domain of a function depends on whether the function has been used. I agree with DC that the Sem Web folks do not go down that rat hole.
RF: I'm not going to change RFC2396 any more. I think you are technically wrong on this point.
DC: Real numbers are all resources.
RF: I think that falls within the current definition.
DC: Each real number is a resource. Not each real number has a name.
[DC and RF disagree]
DC: Each real number, at the same time, is a resource.
RF: You can use all real numbers as resources when you add a qualifier (e..g, "X is in the set of Real numbers..."). "For all x" creates an enumeration.
TBL: When you say "for all x where x is a real number", when you use x as a variable in URI space, then you are saying that x is ranging over a space which is uncountable.
RF: Yes.
TBL: In world of RDF, "resource" is universal set; it's used that way and useful that way.
[We look at current text.]
[timbl]
?? no - pointer?
[IanJ]
RF: Please note that the resources in the current text are those that have been identified.
DC: I think PH's concerns are largely mitigated (if not gone) by identifying "information resources".
RF: I can find URI to mailing list later; there are at least 400 messages on this topic. Proposal "Because the set of resources is unknown; anything can be a resource." There was an issue in the URI issues list, but that issue was closed a long time ago.
[DanC_]
http://www.gbiv.com/protocols/uri/rev-2002/issues.html
this seems to be the relevant issue: http://www.gbiv.com/protocols/uri/rev-2002/issues.html#024-identity
[timbl]
Miles says: "I don't believe that any of these were the authors intent, so to clear up any confusion, the "that has identity" qualifier should be dropped."
I agree.
"A resource can be anything"
[IanJ]
MJ: Are there plans to distinguish resources with names from others?
DC: No, but plans to identify those that are GET-able from others.
RF: there were objections to Miles Sabin's proposal "a resource can be anything".
[timbl]
We are *not* bound by the english langauge as arbiter for this term whioch we are creating in this specifi ccontext.
[IanJ]
RF: You can't use an "unknown" real unless you've named or described it.
DC: The URI spec needs to refer to the universal set.
RF: It does refer to the universal set.
[timbl]
(Actually you *can* make a statemnet about an unnamed real number, by making a statment about all real numbers.)
[IanJ]
(But RF cited explicitly the case where one was not making a statement about all real numbers)
TBL: We are not constraining HTTP URIs any more than URIs. Information resources are those things one would reasonably expect to use GET on; there are some resources identified by HTTP URIs that do not respond to GET.
DC: So you can't conclude from syntax alone that a URI identifies an information resource.
TBL: Right. We have reached consensus on much of the diagram; we are now arguing about the outermost box.
[DanC_]
Roy, this 21May update http://lists.w3.org/Archives/Public/uri/2004May/0025.html seems to give the status of RFC2396bis; seems it has not yet gone to IETF last call. right?
[IanJ]
TBL: This is a URI space diagram, not a thing space diagram.
[Roy]
right. if needed, I will hold it
[IanJ]
TBL: I think we agree about the range of HTTP URIs. We are not using the word "resource" in that consensus.
Proposed action TBL: Make case for "a resource is everything" on uri@w3.org.
RF: I've already been asked to forward this to the IESG. I don't want to postpone unless there's an archived reason to.
TBL: Need to include URIs to defn of resource in RDF specs. Also need to assert that the "other set" is not useful.
DC: I intend to send a mail; TBL needs to reply on the list.
RF: Ok.
TBL: Ok.

[TBL's action effectively carried out by DC].

The TAG did not discuss issues below this line.

2.2 Possible New Issues

  1. XML 1.1 Question from XMLP-WG

2.3 Web Architecture Document Last Call

Resources:

  1. Last Call issues list (sorted by section)
  2. Annotated version of WebArch
  3. Archive of public-webarch-comments
  4. List of actions by TAG participant
  5. Additional actions
    1. Action IJ 2004/02/09: Incorporate editorial suggestions (see minutes of that meeting for details).

Actions 2004/03/15 (due 25 March?) to review sections:

3. Status report on these findings

See also TAG findings

4. Other action items

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2004/05/26 03:14:17 $