See also: IRC log
ER: Next telcon next week on 22 Aug 2006
NM: Regrets for Noah for 22 Aug.
<DanC> so what's the address of the minutes?
ER: We had invited Rhys Lewis to join us, but he would prefer to wait a week or two.
<DanC> (is this the corrected minutes? http://lists.w3.org/Archives/Public/www-tag/2006Aug/att-0061/08-tagmem-minutes.html )
<ht> Raman, see number higher up in this conv.
<DanC> LSID URI thread includes http://lists.w3.org/Archives/Public/www-tag/2006Aug/0000.html
DC: W3C has health care and life sciences interest group
<DanC> "Resource identifiers: URI vs. LSID (and ARK)"
DC: Has BioRDF subgroup, which had a meeting July 31
... Seems like people are warming up to the ARK approach.
... Still not clear to me that there's a suitable DNS domain to use in ARK case
... I tried out some software that went for an actual LSID. Got 404. Sent mail asking about it. Answer was: well, that machine was just down.
... Seemed a lot like HTTP as we know it.
... Trying to grok the social structures around LSID.
... One issue with the minutes of that meeting is that it reports my position (I.e. Dan's) as if it were the W3C's.
... There is a reasonable record in minutes, no formal decisions made.
... ARK stuff was influential, albeit would have been easier to consider if known 4 years ago given large amount of deployed software.
HT: I thought I saw decision to keep talking in the Wiki.
DC: Hmm. I don't remember being formally asked to concur with that.
... Versioning came up, and things headed downhill when that happened.
NM: Do they mean new versions of schemes for naming things, or for example, how to name different versions of attempted sequencing of a given gene?
DC: Any and all of that. Not clear.
... Furthermore, there were strong feelings that metadata vs data distinction is important, but everyone draw's the line differently.
... Do we cite ARK in the paper?
HT: No, but our finding is at the moment more a log of discussion than points.
... I'm particularly grateful that the ARK stuff is at least being looked at, and that folks like Sean Martin have had an open mind when ideas like that have been raised.
NM: One issue raised a month or two ago was that our draft finding didn't do a compelling job of justifying its points. Are we working on that?
HT: It's at the top of my TAG queue to do that.
DO: I've responded to 4 or 5 comments from David Booth, Boeing, etc. which have given me ideas for sections 4,5,6.
... Debating whether I can do this in half day, in which case it will be a priority, otherwise versioning work will come first.
<DanC> (looking up http://www.w3.org/2001/tag/issues.html?type=1#URNsAndRegistries-50 , I see "Henry and David to update draft finding URNs, Namespaces and Registries accepted on 18 Apr 2006". looks like that continues )
DO: Mary Schleiff of Boeing asked
<DanC> Can TAG
<DanC> > members please clarify if their gripes about XRI would
<DanC> > dissolve if XRIs begin with "http://xri.net"
<DanC> > instead of "xri://"?
<DanC> for my money, yes.
NM: Marty's message at http://lists.w3.org/Archives/Public/www-tag/2006Aug/0043.html says:
"I think the statement in URNsAndRegistries  that "Naming authorities
can impose such constraints on the http: URIs under their control" also
covers XRI metadata requirements if we use a naming authority like
"http://xri.net" instead of the "xri:" scheme.
DO: We should consider taking a stand on this in the finding.
DC: How about just agreeing a formal TAG position on this.
<daveo2> Can TAG members please clarify if their gripes about XRI would dissolve if XRIs begin with "http://xri.net"instead of "xri://"?
Proposal: Does the TAG wish to answer "yes" to the question asked by Marty Schleiff "Can TAG members please clarify if their gripes about XRI would dissolve if XRIs begin with "http://xri.net"instead of "xri://"?"
HT: His assumption is that applications are going to recognize that string and recognize it specially.
DC: That's OK
<DanC> friendly ammentment: yes, they _should_ make available representations there. but if they choose not to, oh well.
NM: Yeah, they are documenting that "metadata in URI" and software can rely on it.
... Generic access to HTTP GET can work too. If they choose to go 404 on their stuff, it's their loss.
HT: But they're saying the WILL do 404.
DO: That's OK.
DC: Not just as good, but their choice.
DO: But, crucially, they can change their mind later if generic HTTP access is missed.
NM: Exactly. Strong +1 to that the crucial point is that by naming with http:, you always have the option to deploy.
HT: But now they have an obligation to deploy representations.
DC: They have an obligation to deploy representations regardless of the scheme they use.
NM: And that's a bit harder if you have a scheme for which there aren't widely deployed software protocols for access to those representations.
<DanC> friendly ammentment: yes, they _should_ make available representations there (http://www.w3.org/TR/webarch/#pr-describe-resource ) . but if they choose not to, oh well.
HT: Do you really mean that across schemes, Dan? What about mailto:?
<DanC> Proposal: to the question asked by Marty Schleiff "Can TAG members please clarify if their gripes about XRI would dissolve if XRIs begin with "http://xri.net"instead of "xri://", answer yes, with a reminder they _should_ make available representations there (http://www.w3.org/TR/webarch/#pr-describe-resource )
OK by me
<DanC> aye. +1
<ht> HST: aye
<EdR> ED: +!
RESOLUTION: to the question asked by Marty Schleiff "Can TAG members please clarify if their gripes about XRI would dissolve if XRIs begin with "http://xri.net"instead of "xri://", answer yes, with a reminder they _should_ make available representations there (http://www.w3.org/TR/webarch/#pr-describe-resource )
<DanC> ACTION: DaveO to respond to Marty Schleiff [recorded in http://www.w3.org/2006/08/15-tagmem-minutes.html#action01]
<ht> NM: I've written a lengthy email [above] and will be sending another covering the comments of Hoehrmann and Williams
<DanC> NM: I responded to ~10 comments from each of Bjoern and [missed]; I expect only a few of them will result in changes
<ht> ... I'll be sending another one which will synthesize these into a minor revision to the draft
<ht> DanC: What will change?
<ht> NM: Bjoern is particularly upset with the name of this finding itself
<ht> TV: Right, and if we approve it then we can push the W3C to change its practices
<DanC> I disagree that "http://www.w3.org/2001/tag/doc/metaDataInURI-31" is intended to be used directly by people
<ht> NM: One are that will change is the discussion of guessing
<ht> ... The Best Practice which this section ends with is too close to motherhood, perhaps
<ht> ... Both Hoehrmann and Williams pointed to this
<ht> ... I will try again to improve this
<ht> DC: I would like to discuss the URI for the finding
<ht> TV: It's the whole of the W3C naming policy
<ht> ... in particular the use of dates
<ht> DC: What's worth fixing wrt _this_ URI
<ht> NM: Well, what I said in my email was that URI authorities can decide not to be helpful, if they don't want to make external usability a design criterion
<ht> DC: What URI would you suggest, TV?
<ht> TV: TR/MetadataInURI, or tag/findings/MetadataInURI
<ht> NM: Hoehrmann is saying "It's my call as a user to judge your URIs for usability, and I judge them deficient"
<ht> ... You (DC) are saying "It's our call as the authority, and the only thing we warrant for use on the side of a bus is 'www.w3.org'"
<DanC> (actually, historically, "w3.org/pics" was one of the more widely-plastered URIs W3C promoted)
<ht> Norm, see log above
HT: Another question about the finding.
... Your draft uses the word designate where others use identify. Was that intentionally or by chance?
NM: Do you want a change? I could try.
HT: Well, I could send email that covers some other issues in the intro. Has to do with resource vs. representation of the resource.
... Sometimes we blur sometimes we don't
NM: I have sent a long email covering Bjoern's concerns and will send one more detailing responses to Stuart. Those are long. I will send in addition a shorter one netting out what I think the TAG should look at in resolving metadataInURI 31
ER: Any other business?
<Norm> Norm apologizes for missing most of the meeting :-(
<ht> OK, phone number is gone from all logs
<ht> Noah, you may need to re-fetch.. . .