See also: IRC log
<Stuart> Scribe: Jonathan Rees
<Stuart> scribenick: jar
<leobard> hi, joining chat for the momment, phoning in in 10 minutes...
stuart: we are expecting guests to
talk about httpRedirections-57
... agenda accepted
... no objections or abstentions re minutes of 13 march
... next meeting 27 march. ashok to scribe
... noah regrets for 27 march
... approval of feb f2f minutes to be tabled pending completion of
all days
Resolution: Approve 13 March 2008 minutes at http://www.w3.org/2001/tag/2008/03/13-minutes
Richard Cyganiak has joined the call
Leo is in IRC and is expected on the call
stuart: Welcome Leo
... Hoping that today, we can see clear to the end of this
document
... To discuss: diagram and conneg + redirection
leo: State of SWEO - finishing in 1
week, end of March. Cool URIs has been in progress for 1 year. Must
be published within 1 week, if it's to be a note
... hoping for no feedback
... We received a big review from Tim in Feb, and changed the doc.
No ack yet.
<Stuart> http://lists.w3.org/Archives/Public/public-sweo-ig/2008Mar/0052.html
Tim: 16th of March...
leo: Tim's suggestion has been added as an alternative
Tim: It's important which one you
should do
... we want generic documents when appropriate, and not when
not
leo: Look at 4.3, second
paragraph
... Do you suggest we remove 4.2 ?
<leobard> remove 4.2?
Tim: No, 4.2 is appropriate when the HTML has more information than the RDF
<Stuart> Editorial question: should 4.2 have a more expansive heading than "303 URI"?
Tim: If one is more powerful than the other, then it is a different document & must have different URI
<timbl_> 303 URIs with documents with different information.
Tim: how about "redirects to documents with different information"
[scribe's possible inaccuracy in quoting tim]
Tim: Probably more common is HTML
automatically generated from RDF
... When RDF has been scraped, then they're clearly different
... There's nothing about CN, is there.
Leo: CN near beginning, in 2.1, but not detailed
<leobard> link to q - qs plz?
tim: if html is from rdf, the rdf should be preferred
stuart: There was a Richard/Tim exchange [in IRC]
<timbl_> qs(rdf) > qs(html) if the html is generated from the html.
tim: crucial point was where we
changed tabulator in with firefox, which has a choice between html
and rdf
... there is a loss when you generate html from rdf
... problems with rules like "if the client can take rdf, give it
rdf" (similarly html)
<Stuart> My concern is where this (qs/qc) can be fixed in time for an LC publication tomorrow and a 1 week review cycle?
leo: Is this written down somewhere?
tim: No
(q / qs relates to CN algorithm - quality)
<timbl_> qs = the amount by whichhte qualty of this is presevced (1) or degraded (<1)
(scribe having difficulty transcribing Tim)
leo: Can you give example of correct server behavior?
<timbl_> If the RDF is dscarped (lossily) from hte HTML, the q(rdf) < q(html)
tim: Quality measure should take direction of scraping into account
(Tim explaining CN quality parameters using images as an example)
<timbl_> http://httpd.apache.org/docs/2.0/content-negotiation.html
<leobard> cygri sees a problem with server side of q-values, it seems not specified
leo: The client/server quality
interaction is not specified in HTTP/1.0
... Apache does a particular thing, but this seems obscure
... This presents a problem for the document
... Nothing to cite
tim: Fair enough. Maybe explain what to do specifically for Apache
stuart: Maybe a simple reference to apache doc would help?
richard: Explain it in general terms
- say that you should bias [using quality params] in the right
direction?
... Point to apache as one example
<timbl_> In the case in which for example an HTML file has been generated from the RDF file, then the HTML has lost some information, so the RDF should be deleivered for clients whcih accept boethr RDF and HTML with similar q levels (see HTTP sec).
<timbl_> In the case in which the RDF file has only a subset of the information in the HTML file, and teh client handles with, then the server should have a preference for the HTML in the content negotiation algortithm
<timbl_> See for example the Apache content negotiation [ref].
Tim: You can do it with typemap files, but not with multiviews. Apache bug.
<timbl_> You can do this with a type-map file but not with multiviews, as there are no qs specified in the config file for multiviews
<leobard> the replaced diagram is here: https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/html/cooluris_sweo_note.html#r303gendocument
stuart: What is the effect on the diagrams of this discussion?
<leobard> diagram: https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/html/img20071212/303conneg.png
tim: It's simplistic about CN
<timbl_> "application/rdf+xml wins"?
richard: it should be changed
raman: Can you add a pointer to the tag finding i wrote last year? [genericResources]
richard: yes
<cygri> http://www.w3.org/2001/tag/doc/alternatives-discovery.html
raman: in the section on generic resources
stuart: general agreement on switching 4.2 and 4.3
tim: It's not a disinction between web documents and things. Web documents *are* things
richard: but this is covered in the first sentence
raman: Too vague - strike it out
discussing 'err on the side of caution'
<Stuart> from my POV the httpRange-14 questions was "what kinds of thing can be named with an http URI" and we said "...anything..." even in the case where there is no '#' in the URI.
tim: end of 3.1 will confuse people.
<timbl_> It is not necessary to make that distinction, to define from first priciples what a douemnt is or is not.
ht: Agree with the goal of this
section - advise people when they have a certain class of
problems
... Everything would follow if section title were "URIs for things
not on the web"
<timbl_> You can say, "We have demonstrated how URIs can be given to things, and to the documents about those things, and how they connect".
tim: Doesn't have to be "real world objects"
ht: Need to judiciously change the rhetoric - we don't need to descend into argument
richard: But this argument has been
going on for 5 years
... There is a problem, I have something sitting in front of me,
can I return a 200 or not?
... The question [of what is an IR] matters
timbl: No one will think a telephone is a web document
jar: But is a representation a web document? Or the number 3?
<Stuart> jar... do you mean the number or a numeral?
ht: There are clear cases and hard cases
<cygri> seems i dropped from the call ... will rejoin
<raman> lots of static on the line
timbl: It's important that we not go there - questions like is 3 an IR
<leobard> decision is needed on whether remove 3.1 or keep it
timbl: Propose 3.1 be removed
<timbl_> Note that URIs of people amd the documents abou them sould not be confused: For example the person Alice is described on her in an information resource, Alice's homepage. Bob may not like the look of the homepage, but fancy the person Alice
<timbl_> +1 for remove 3.1
<ht> I'm happy with 3.1 as it stands, with one small modification
<ht> First sentence should be changed to "Above we assumed that there is a distinction between web documents and everything else"
<ht> and similarly to the title of the section
<timbl_> as
ht: Thinks only one small change is
needed - don't remove 3.1
... Only problem is "real world object"
... Summary is helpful
<timbl_> Note that URIs of people and the documents abou them sould not be confused: For example the person Alice is described on her homepage. Bob may not like the look of the homepage, but still like the person Alice.
tim: "Not everything is a web document" - 303 is perfectly fine for web documents
ht: Can I ask the authors, do you understand why we're opposed to setting up an opposition between web documents and real world objects?
yes
ht: Can you rewrite this? It's going to be too hard to redraft the paragraph on this call
we've rewritten it 5 times already
timbl: 303 and # work in all cases,
IR and non-IR
... non-IR is not an interesting category
<timbl_> Distinguishing between things and the web documents about them.
<timbl_> We have discussed ways of giving URIs to all kinds of things,
<timbl_> so that the client can find out the URIs of documents between them.
<timbl_> Note that URIs of things, say people, amd the documents abou them should not be confused: For example the person Alice is described on her homepage. Bob may not like the look of the homepage, but still like the person Alice.
author: To fix this would require a
lot of changes, not just here but throughout the document
... No time
stuart: Let's try Henry's suggestion
<ht> HST is sending Richard and Leo a suggested rewrite, copied to www-tag
stuart: Tim, please review
<Norm> noah, could you take a look at the minutes I sent you for review yesterday or the day before?
timbl: Getting the document is more important than perfecting it
stuart: Thanks for doing this. We all think it's a good document
CURIEs
<ht> http://lists.w3.org/Archives/Member/tag/2008Mar/0069
<noah> Norm - did you take the edited HTML I sent you on 2/29, or just rerun from the IRC log? Doing the latter is a real mistake. I did quite a bit of editing on a private copy of the log, then generated clean HTML. I >think< the text that's worrying you does not show up in the clean copy.
i haven't been scribing. iw as talking
my question is how strongly tag should come down against union of URI and [curie]
<timbl_> xml2? URI2?
noah: Would you be willing to commit to there never being a new URI syntax beginning with [ ?
<Stuart> noah's question is targetted on the 'stewards' of the URI spec.
<Zakim> ht, you wanted to suggest a change to point 3
ht: We're clearly talking about new
context or new languages... maybe this isn't explicit enough
... The square brackets don't address this problem. It's not up to
HTML 2 WG to say that URIs don't begin with [
noah: Have they redefined the syntax of URIs?
<Stuart> Norm.... pointer please to the transgression?
<timbl_> They have not redefined URI, but they are defining a competing type which incldues URI and will only work if URI strings never start with '['
raman: We need to create an environment where people can solve these problems
norm: Then we should say yes
<Norm> raman's x:foo example is different from javascript:void. The "x" isn't constant.
tim: Precedent: transition from URI to IRI.
<Stuart> see http://www.w3.org/2006/07/SWD/RDFa/syntax/#id102419
<Stuart> example text is:
<Stuart> "This document is licensed under a
<Stuart> <a xmlns:cclicenses="http://creativecommons.org/licenses/"
<Stuart> rel="cc:license"
<Stuart> href="[cclicenses:by/nc-nd/3.0/]">
<Stuart> Creative Commons License
<Stuart> </a>."
ouch.
<ht> Is that for HTML2 or XHTML 4.01?
tim: There's no way URIs will start with square brackets...
<Stuart> ht: don't know haven't read enought of the surrounding context... but assume RDFa in XHTML2
tim: but that's not the problem. The problem is that as time goes on all URI parsers will be expected to handle these things
<ht> If it's XHTML2, there's no problem -- they can define the content of href in a new language however they like
<ht> the problem comes if they try to push this back into HTML4.01
raman: How is this different from ability to handle new uri schemes (e.g. javascript:)?
<Norm> that's not a useful distinction, ht, even if its only spec'd for xhtml2, if it's useful, it'll be back-formed into other specs
(I think raman is making the same comparison I did, of [...] to a new URI scheme)
ht: Browsers all already have
plugin-based URI scheme handling
... I don't think this is ready to send
<Norm> <a xmlns:http="http://foo" href="[http:/bar]">bar?</a>
ht: I hear a repeated willingness to engage constructively
<noah> IF we go down this path, I think a key question is whether we suggest that existing formats MAY or SHOULD support CURIE | URI
ht: Let's ask them questions about exactly where they see this being used and where not
noah: Key missing piece: we should point a direction (may, should)
ht: I disagree. This is a use for new contexts/languages going forward
timbl: Not realistic
<Norm> +1 to timbl_
timbl: bad engineering
<noah> SOm Henry says "MAY
<Zakim> jar, you wanted to say that he thinks RDFa has been VERY careful not to allow href="[...]"
<noah> SOm Henry says "MAY" and Tim says "SHOULD
<ht> No, Henry says MUST NOT change parsers to accept CURIEs where existing W3C specs call for URIs
<Norm> Indeed, jar, 2.1 does seem to be clear along the lines you suggest
<noah> Sorry to come late and then run, but I've got to go. Next week I will NOT be on the call. Please accept my regrets for that.
<ht> ACTION: Henry S to post a redraft of comment (3) from http://lists.w3.org/Archives/Member/tag/2008Mar/0069 to tag@w3.org [recorded in http://www.w3.org/2001/tag/2008/03/20-minutes.html#action01]
<trackbot-ng> Created ACTION-126 - S to post a redraft of comment (3) from http://lists.w3.org/Archives/Member/tag/2008Mar/0069 to tag@w3.org [on Henry S. Thompson - due 2008-03-27].
