Discussion of httpRange-14 Action Item

Action Item on HttpRange-14 Resolution

Our action item was: http://www.w3.org/2005/06/27-swbp-minutes.html#action02 [[ ACTION: ralph davidw and davidb to an initial draft of TAG httpRange-14 resolution impact on semweb application developers ]]

<RalphS> the three of us have an oustanding action item re: httpRange-14

<dwood> agendum+ Ralph, DavidW, and DavidB to an initial draft of TAG httpRange-14

<dwood> resolution impact on semweb application developers

<RalphS> DBooth: we could document the approaches that have been previously discussed

<RalphS> ... previous to my proposal

<RalphS> David: does the TAG's decision to return 303 create a practical hurdle in developers constructing URIs?

<RalphS> ... I think we have a sense that this does create hurdles

DWood: We need to address the httpRange-14 resolution and its impact on SW. Does the decision to return 303's provide a practical hurdle in constructing URIs? My sense is yes, but we haven't said what to do about it.

<RalphS> ... DBooth has made a stab at addressing this

<RalphS> ... is DBooth's proposal orthogonal to our shared action item?

DWood: DBooth took a stab, and I haven't read his latest decentralized proposal. We previously thought it was orthogonal to our action.

<RalphS> DBooth: I mentioned concerns in early version of thing-described-by

<RalphS> ... wasn't exactly in the form of a use case

<RalphS> ... but perhaps could be put into that form

Ralph: Not obvious what practical difficulties there are. Use case would help me. DanBri asked early on about purl.org using 302 redirects (for pragmatic reasons), whether the TAG's resolution means specifically 303 or would 302 be acceptable. (The answer was no, it must be 303.)
... After the TAG's decision, I've had a few other discussions with people about it, and if asked they would say "303 only" and I think they'd be correct.
... Writing prose about that question would be useful, and that may lead us to use cases, but purl.org would not be a good example because the reasons they chose 302 were practical and made long ago.

<scribe> ACTION: DBooth to write up his concerns with the httpRange-14 decision, i.e., why native 303 redirects are too hard and inefficient [recorded in http://www.w3.org/2005/09/05-swbp-minutes.html#action01]

Ralph: Need to have a way to celebrate to the world why the TAG's decision is good.

DWood: Why did DanBri want 302?

Ralph: He didn't. He was just asking because he noted purl.org does it, and wondering if it needd to be changed.
... It would be costly to get OCLC to change purl.org.
... It would help to document why it is important.
... And to understand to why the TAG's decision is an important milestone.

<RalphS> DBooth: 303 redirects could happen at purl.org or by the server that the 302 points to

DWood: What bugs me about 303 is that it says "it ain't here, but you can get it somewhere else".

Ralph: You're touching on why the semantic difference matters. 302 does not have the semantics we need for this.

<dwood> Quoting from http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html :

<dwood> The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource

<RalphS> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4

<RalphS> Ralph: 302 talks about the _resource_ whereas 303 talks about the _request_

DWood: So you're saying that if I want to resolve dc:creator, and I want to know canonically what that means, I expect . . . what? A 303 response that may lead to a resource describing dc:creator?

DBooth: Yes.

Ralph: I quibble with the word "expect". You should be prepared to handle any of the HTTP responses.

<RalphS> DWood: RDF:Property is disjoint from Information Resource

<RalphS> Ralph: hmm. interesting; I'll have to think about whether I agree with that assertion

DWood: So my SemWeb app has a URI for an RDF property. And I know that it cannot be an information resource therefore.
... We're always going to use predicates that are disjoint from info resources.

Ralph: I'm willing to grant that as a true assertion (for now), and you know if you do a GET on a property, you won't get a 200, you may get a 303.

DWood: The URI returned by the 303 may be useful, so then it falls under SWBP scope.
... I'm hoping we can get to the point of saying "The SWBP response to the TAG finding means that a URI for a non-info resource SemWeb predicate the response should be 303 and should contain the following data".

<RalphS> DWood: I was really addressing the use case where the URI was of a Subject rather than a Property

DBooth: In my use case, the URI is a subject -- not the predicate.
... And the app wants to learn about it.

DWood: Can we continue with the assumption that predicates will never be info resources?

Ralph: Yes, because I don't think it matters.

DWood: If I do a lookup on an RDF predicate, and the response is a 303, then the URI *SHOULD* contain ___.

Ralph: Good.
... And also the other way around: when I'm defining a new vocab, how do I pick the names.

DWood: That's within our perview.

<scribe> ACTION: Ralph to write up why 303 and not 302 [recorded in http://www.w3.org/2005/09/05-swbp-minutes.html#action02]

<RalphS> DWood: my interest as an application developer is in narrowing the gap between machine-readable and human-readable

DWood: My interest as a SW app programmer is marrying the gap between machine/human readable info. This discussion is important in that regard because it's nice to have machine-readable RDF and human-readable info, but occasionally you need to map between the two.

Ralph: To what degree is your position motivated by an interest in having a single "info resource" which is both presentable to humans and machine processable?

DWood: No, that's a special case.

Ralph: Content negotiation adequate?

DWood: (Dodging question somewhat) It would be a mistake to come up with a solution that precludes the embedding of machine or human readable info in the content retrieved from the URI?
... If you do a GET on the URI, we shouldn't say anything to force the content to be machine or human readable.

Ralph: We can and should. We can have mechanisms for choosing which content.

DWood: Agreed. We need a way to determine what came back.

Ralph: you want a use case that shows that DublinCore.org can serve both human and machine readable content at the same URI.

DWood: Yes, GRDDL perhaps.

<dwood> ACTION: David Wood to send an email to the SWBP mailing list expressing a use case for SemWeb predicates to be resolved via 303 responses, returning both human and machine readable data. [recorded in http://www.w3.org/2005/09/05-swbp-minutes.html#action03]

<RalphS> DBooth: the other use case of Subject URI is still in question; in this case we don't know whether or not the Subject is an Information Resource

DBooth: There's also still an efficiency issue with doing the 303 redirect.

Ralph: The HTTP spec refers to GET, but the idea applies to other schemes also. In the case of HTTP, HTTP has a mechanism a level of indirection and the semantics that a SW developer must understand is that a 303 is simply an indirection, and the data you're looking for you find by indirection.

DWood: If you're a SW developer, a 303 response should not be treated as a error as it would often with other apps.

Ralph: In the case of predicates, the app developer is most likely to always get this level of indirection, but in the case of a subject, we don't know which is more likely, but the machinery will work for either.

<RalphS> Ralph: for SemWeb purposes, HTTP 303 is _just_ another level of indirection

DWood: I think you're right about subjects. The 303 should mean the same thing for any URI -- subject or predicate. But if it's a predicate, then the 303 returned should be resolvable.

DBooth: Why not require it for subjects also?

<dwood> I propose that predicates SHOULD be resolvable on the Web, and subjects MAY be resolvable

Ralph: Can't require it for subjects, though we should encourage it.

DBooth: Why treat subjects differently?

DWood: Subjects are more likely to be local content, whereas predicates are more likely to be more global ontological concepts.

DBooth: I would challenge that assertion for evidence.

Ralph: Maybe we don't need to distinguis these two cases. But it's clear that as the SWBP WG, the things that are in scope for us to determine are about how to write ontologies, and in the course of that we can place requirements on the predicates. We can't place additional restrictions on the rest of the world.

DBooth: The WG is about how to write RDF, which has subject, predicate and object. I don't see a good reason to restrict the guidance to the predicates.

DWood: Often data is voluminous and auto-generated.
... It would be too costly to do http URIs for subjects.

Ralph: Then you're not being a good Web citizen if you're not intending to make it resolvable. By using an http URI, you're suggesting to the world that there's usefule machineray that may help them.

<Zakim> dbooth, you wanted to ask what is the cost of treating subjects the same as objects

Ralph: DWood's app wants to choose http URIs as subjects and he doesn't want to bear the burden.
... 400 responses are highly unfriendly, rather than being intentional.
... So he wants to mint URIs that don't return 200 or 303.

DBooth: Why?

DWood: An org is creating a very large number of http URIs as subjects because some are resolvable, and they don't want to separate the two because the ongoing use of the data may later make some resolvable.

Ralph: Does your app distinguis between URIs that it has used and those it has not yet minted?

DWood: It could.

Ralph: So it could return one of three answer: 1. Known things: 303 2. Known but unwilling to say more: 303 with no further info; 3. not known: return 404.

<dwood> yeah, I think that is OK

DBooth: So that would permit subjects and predicates to have the same treatment.

<dwood> yes

Ralph: That's significant to record. If I always get 404, the Web is telling me "no such name exists". Whereas this is saying 'I'll confirm the existance of that name, but nothing more about it".
... Same reasoning for objects.

DBooth: My concerns (ease of minting 303-conformant URIs, and scalability/efficiency of requiring the redirection).
... are still applicable. My proposals are intended to address them.

ADJOURNED