16:57:15 RRSAgent has joined #tagmem 16:57:15 logging to http://www.w3.org/2012/05/03-tagmem-irc 16:57:17 RRSAgent, make logs public 16:57:17 Zakim has joined #tagmem 16:57:19 Zakim, this will be TAG 16:57:19 ok, trackbot; I see TAG_Weekly()1:00PM scheduled to start in 3 minutes 16:57:20 Meeting: Technical Architecture Group Teleconference 16:57:20 Date: 03 May 2012 16:57:27 Scribe: Jeni Tennison 16:57:30 ScribeNick: JeniT 16:57:40 Chair: Noah Mendelsohn 16:59:24 Larry has joined #tagmem 16:59:35 TAG_Weekly()1:00PM has now started 16:59:42 +??P1 17:00:13 +Masinter 17:00:15 Ashok has joined #tagmem 17:00:26 Regrets: Robin Berjon, Yves Lafon 17:00:30 +??P7 17:01:02 +plinss 17:01:32 +Ashok_Malhotra 17:02:06 jar has joined #tagmem 17:02:34 +Jonathan_Rees 17:05:51 I suggest someone in the US call Noah and ask what's up 17:05:56 noah has joined #tagmem 17:06:05 -ht 17:06:16 +Noah_Mendelsohn 17:06:23 zakim, who is here? 17:06:23 On the phone I see JeniT, Masinter, plinss, Ashok_Malhotra, Jonathan_Rees, Noah_Mendelsohn 17:06:26 On IRC I see noah, jar, Ashok, masinter, Zakim, RRSAgent, JeniT, ht, timbl, trackbot, plinss, Yves 17:06:52 Topic: Convene 17:07:02 +??P7 17:07:12 Regrets: Robin, Yves, Tim 17:07:30 Present: Jeni, Larry, Peter, Ashok, Jonathan, Noah 17:07:58 noah: I am probably not available next week 17:08:11 Ashok: could you create the agenda? 17:08:18 i volunteer to chair if Noah can't make it 17:08:29 ... I could then chair if you weren't available 17:08:51 noah: the meeting will be going ahead 10th May 17:08:56 http://www.w3.org/2001/tag/2012/04/26-minutes 17:09:06 Topic: Approve minutes of prior meeting(s) 17:09:52 noah: these are noted as being a draft 17:10:06 masinter: I was using the minutes as a privacy example 17:10:32 noah: Larry, please look at actual text if you want it to be changed 17:10:52 masinter: that text is fine 17:11:17 did anyone else care? 17:11:29 ACTION: Noah to put health warning in "Booth Script" for formatting minutes 17:11:29 Created ACTION-703 - Put health warning in "Booth Script" for formatting minutes [on Noah Mendelsohn - due 2012-05-10]. 17:11:30 RESOLUTION: Minutes of 2012-04-26 are approved 17:11:38 http://www.w3.org/2001/tag/2012/04/26-minutes 17:11:48 as a use case, the interesting thing is what the health warning should say, to set an example for other health warnings 17:11:51 Topic: Administrative items 17:12:10 noah: we should review the DANE work 17:12:16 i've been talking to Philip Hallem-Baker (sp?) 17:12:23 ... Larry had suggested getting invited experts 17:12:27 based on what I know of TAMI etc. I think it could say a different thing… will follow up in email 17:12:34 q+ 17:12:41 masinter: I've been talking to Philip, who has a paper on an alternative method, and is critical of DANE 17:12:55 noah: we'd need someone in addition to him, to be an advocate for DANE, right? 17:13:18 ... Larry, would you sort out who should come and talk to us? 17:13:24 masinter: yes 17:13:30 ack next 17:13:47 Ashok: I've been following this, and it's still ongoing 17:13:55 ... it looks like there's hardly any agreement on direction 17:14:03 ... I'm wondering if it's too early to look at this 17:14:06 push date of action-697 out a couple more weeks 17:14:43 action-697 due 2012-05-16 17:14:43 ACTION-697 prepare overview of DANE for TAG consideration due date now 2012-05-16 17:15:02 masinter: it is early to come to conclusions 17:15:29 ... but even so, if it's chaos it's not unreasonable for us to see if we could contribute to resolving it 17:15:37 Ashok: then you would ask a couple of people? 17:16:06 masinter: yes, I think so, I haven't yet understood enough to know how to bring it to the TAG 17:16:22 ... so let's meet this week and see if we can make sense of it together 17:16:24 Ashok: ok 17:17:26 noah: ok, Larry will take next step with ACTION-697 17:17:29 Topic: Close pending Actions without discussion 17:17:43 s/let's/let's (Ashok and I)/ 17:18:24 noah: ACTION-636 17:18:43 I did move the document I was working on to the WIki 17:18:43 ... updating product page which closes out Mime and the Web work for now 17:19:39 no objections 17:19:50 agreed noah can close ACTION-636 17:20:27 ACTION-670? 17:20:27 ACTION-670 -- Noah Mendelsohn to update product priority list to mark MIMEWeb completed after final product page available -- due 2012-05-08 -- OPEN 17:20:27 http://www.w3.org/2001/tag/group/track/actions/670 17:22:24 Topic: ACTION-680: review of http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04 (note: should be the -06 version) 17:22:33 http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-06 17:22:40 i think -06 made changes in response to our comments 17:22:55 masinter: I think they have responded to our comments 17:23:06 ... the changes between -05 and -06 were the edits in response to our suggestions 17:23:06 Could we briefly list the things they did in response to our requests? 17:23:23 ... we need to publish Jeni's document as an RFC or an Architectural Recommendation on best practices for media type registrations 17:23:44 noah: this (media type regs) is a IETF document that will become a RFC or BCP, right? 17:23:49 masinter: yes, right 17:23:56 noah: do we need to do something else? 17:24:03 masinter: we started on best practices to fragment identifiers 17:24:11 ... we wanted them to refer to that normatively, but there wasn't time 17:24:16 ... but we still need to finish that document 17:24:23 ACTION-690? 17:24:23 ACTION-690 -- Jeni Tennison to sort next steps on Fragment Identifiers and Mime Types -- due 2012-04-17 -- OPEN 17:24:23 http://www.w3.org/2001/tag/group/track/actions/690 17:24:29 noah: right 17:24:45 ... Jeni has the action on what we should do 17:24:51 masinter: my opinion is we should finish it 17:25:07 and get it published as an architectural recommendation or else an IETF BCP 17:25:25 JT: The discussion for item 6 on the agenda is about how to take that forward, and what its scope should be. 17:25:32 i also had two other items with regard to media types which aren't currently covered 17:25:47 JT: I think at present it's got description, but the "best practices" aren't pitched right. 17:26:06 a) file extensions, which *are* a part of web architecture, mentioned in MIME reigistrations, but the registration process isnt currently useful 17:26:24 JT: I was going to propose to refocus on what should be put into mime type registrations relating especially to fragment identifiers 17:26:31 b) 'magic numbers', since sniffing is part of web architecture, but the MIME registry of magic numbers isn't 17:26:50 q+ to say yes, but don't lose back-story 17:27:15 ack next 17:27:16 ht, you wanted to say yes, but don't lose back-story 17:27:18 noah: ok, let's talk about TAG work, and then jump back to mime draft 17:27:42 ht: yes, I think what Jeni volunteered to do would be great 17:27:59 ... but don't lose the back story, put it in another document and reference it from the Best Practices document 17:28:06 noah: I agree, keeping the back story is good 17:28:07 i would be glad to help 17:28:32 NM: Do we need to set priorities relative your other work, Jeni? 17:28:58 JT: How to prioritize relative to copyright and linking 17:29:11 copyright + linking more important 17:29:14 LM: Both important. I'm willing to help with MIME draft if that will help 17:29:17 masinter: they're both important, I'm willing to help on mime draft, but I'll want direction 17:29:41 ht: since Ned won't reference the fragment identifier document, it takes the time pressure off 17:29:54 noah: he's reluctant to reference it because it's not there 17:30:17 what's the shortest time we could publish this? 17:30:29 ... the more we do things slowly, the more we're not good partners 17:30:43 ... this feels like something we could get something concrete out rapidly 17:31:14 I think the fragment identifier document is nearly done 17:31:45 I'm OK either way 17:31:53 JeniT: feels to me like we could do something moderately rapidly, good timing with media type reg. document 17:31:58 noah: any objections? 17:32:07 +1 17:32:10 ... none heard, so do fragid / media type higher priority 17:32:40 ... please bring product pages up to date 17:32:51 ... especially if I can put it in the report 17:33:04 JeniT: I will try to do that in next couple of days 17:33:28 masinter: do we need to push back on media fragments group? 17:33:50 ... at the web conference, I talked to Thomas, and they were saying it was a mistake when the group was chartered 17:34:08 ... we have a draft from a WG that the folks from the IETF thought was laughable 17:34:12 Please remind me what the concern was -- I wasn't at the meeting where this was discussed 17:34:12 ... there's a disconnect there 17:35:04 noah: what's the concern with what they've done? 17:35:19 masinter: they propose that fragids have a meaning that applies to all registrations of a top-level type 17:35:34 ... and that idea doesn't jibe with the folks who run the media type registries, and what they could enforce 17:36:30 q? 17:36:36 it relates to item 7, in that if we expect all future registrations of image/* to use the media fragments fragmentID scheme, the mime registration document should say so 17:37:00 q+ to talk about XML vs. image 17:37:06 ack next 17:37:07 noah, you wanted to talk about XML vs. image 17:37:26 noah: we might have something to say here, which is analogous to the generic processing debate 17:37:57 at one point, the rtsp scheme wanted to define fragment identifiers for URIs for taht scheme 17:37:58 ... we could say that there's a choice for the media type registrations to reference that spec 17:38:09 ... but if you do that, you can't have generic processors that understand all images 17:38:27 ... with XML, which is a +xml type which is slightly different, we wanted to share specs, but also have generic processing 17:38:33 ... with specific understanding of the subtype 17:38:46 ... that story, that trade-off, without choosing sides, might be useful 17:39:01 ... to point out that if it's just buy-in of media types one-by-one, you lose generic processing 17:39:09 ... because other media types might choose differently 17:39:29 ht: Yves story as Jeni described it is not consistent with the remarks in the current version of Jeni's document 17:39:36 ... about the possibility of inheritance from the top 17:39:56 ... the fact that Yves doesn't think it means that, and it's clear that it caused an aversion reaction from the IETF community 17:40:12 ... I think it's worth keeping in view the possibility of inheritance as in principle a coherent position 17:40:35 noah: it's interesting to talk about this in terms of the major type and the +ext syntax 17:40:43 q? 17:40:45 ... certainly there's generic processing you could do on text for example 17:40:57 s/inheritance as/inheritance 'from the top' as/ 17:41:00 http://lists.w3.org/Archives/Public/www-tag/2012May/0015.html 17:41:23 noah: the media fragment spec made some statements about web architecture that I found surprising 17:41:28 ... sent in email earlier 17:41:30 fragments don't have media types 17:41:43 ... they said fragments have the same media type as the original representation 17:41:50 ... I'd welcome getting comments back on this 17:41:57 masinter: fragments don't have media types 17:42:07 fragments aren't "retrieved" 17:42:09 noah: that spec says they do! 17:42:09 Quoting media types draft: A further requirement put on a URI fragment is that the media type of the 17:42:09 retrieved fragment should be the same as the media type of the primary 17:42:09 resource. 17:42:29 "retrieved fragment" doesn't have a media type 17:42:33 Fragments _could_ have media types, if the parent media type registration specifies that they do 17:42:35 ... I agree with Larry that they don't have a media type 17:42:48 ... it might be worth going through the spec to look at these 17:42:53 we went through this with http Range 17:43:18 JeniT: I could have a look as part of the fragid & media type work 17:43:19 ACTION-698? 17:43:19 ACTION-698 -- Noah Mendelsohn to schedule discussion of how to take forward the TAG concerns with respect to managing fragment identifer schemes, inheritance and overlap -- due 2012-05-01 -- PENDINGREVIEW 17:43:19 http://www.w3.org/2001/tag/group/track/actions/698 17:43:24 byte range retrieval... (need to look up) 17:43:26 close ACTION-698 17:43:26 ACTION-698 Schedule discussion of how to take forward the TAG concerns with respect to managing fragment identifer schemes, inheritance and overlap closed 17:43:31 ACTION-690? 17:43:31 ACTION-690 -- Jeni Tennison to sort next steps on Fragment Identifiers and Mime Types -- due 2012-04-17 -- OPEN 17:43:31 http://www.w3.org/2001/tag/group/track/actions/690 17:43:52 ACTION-690 Due 2012-05-05 17:43:52 ACTION-690 sort next steps on Fragment Identifiers and Mime Types due date now 2012-05-05 17:44:12 http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-19 17:44:18 noah: anything else on the media type registration draft? 17:44:37 masinter: there are two things in my original analysis that aren't within this 17:44:55 ... one is file extensions, which aren't part of the web, they're mentioned in several specifications 17:44:56 What do you think we/they should say about file extensions? 17:45:10 ... a recent thing in HTML5 in file upload that talks about file extensions 17:45:25 ... the media type registration lists extensions, but the lists don't correspond to what people use 17:45:34 ... this is a gap that neither W3C or IETF is working on 17:45:36 4.12. Additional Information 17:45:43 noah: do you have a concrete suggestion about what should be done? 17:45:53 SHOULD File name extension(s) commonly used on one or more platforms to 17:45:54 indicate that some file contains a given media type. 17:46:00 (quoting the draft) 17:46:04 masinter: I've been worried about this for years, and I'm trying to see if anyone else on the TAG is interested in pursuing this? 17:46:49 that the MIME registry for file extensions is incomplete, not useful,e tc. but W3C specs use file extensions, and they're getting *more* used in specs 17:47:11 noah: it's part of the work we just closed out on Mime and the Web 17:47:27 another thing in the same category are the 'magic numbers' 17:47:44 jar: is there a registry of file extensions? 17:47:55 masinter: there's no official registry of file extensions in IETF or W3C 17:48:04 q+ to mention 'file' 17:48:05 ... the packaging spec includes file extensions for use within packaged documents 17:48:22 (and of course, different OS's have at least somewhat different constraints on extensions, e.g. 3 char vs unbounded.) 17:48:23 ... we have a best practice that HTTP URIs with file extensions shouldn't mean anything 17:48:42 ... the media type registrations should include extensions 17:48:56 jar: would this be an IANA considerations thing? a request to make a registry? 17:49:01 masinter: we could make a registry 17:49:21 ht: there already is a registry, a hugely complex registry 17:49:29 ... in linux 17:49:41 there are multiple registries, apache filetypes 17:49:43 noah: that's not cross-OS 17:49:56 ht: there's an enormous degree of overlap, except with Windows 17:50:05 ... all the unix variants buy into it, including the Macs 17:50:12 noah: Windows has its own, and people hack it 17:50:24 ht: there is a registry, it's just not an IANA one 17:50:41 http://filext.com/ 17:50:49 noah: the IETF has a loose form, in that media type registrations can list extensions 17:50:52 is a web site dedicated to registering file extension 17:50:57 ... I just wonder if they might be checked for consistency with others 17:51:02 jar: that's not going to happen 17:51:14 noah: you mean if I gave a file extension of 'jpeg' then they wouldn't object? 17:51:36 masinter: there's a website http://filext.com/ 17:51:57 jar: the way I see these registraties is that the truth comes from IETF and IANA just does administration 17:52:04 FILExt is a database of file extensions and the various programs that use them. I 17:52:14 ... we could under IANA considerations ask them to start keeping a registry 17:52:17 i'm just pointing out that this is a part of "how the web works" that isn't standardized, and that disagreements about cause problems 17:52:23 ... I'm not saying it's a good idea, just it might logically make sense 17:52:30 and that use from W3C specs is increasing 17:52:30 ... but if the information is in other places, maybe it doesn't 17:52:37 noah: what should we do about this as the TAG? 17:52:51 put it on our list of "things we should do later" ? 17:53:15 masinter: maybe we need a list of things that webarch doesn't talk about 17:53:23 noah: what was the other one you had, Larry? 17:53:29 masinter: magic numbers and sniffing 17:53:44 ... I'm bringing these up because they are both in the media type reg document as something you could say 17:53:52 jar: they have a SHOULD, you have to justify not saying them 17:54:01 masinter: but it doesn't tell you why you would say it, or what the best practice is 17:54:13 noah: does the TAG need to engage on this? 17:54:23 ... couldn't an individual make comments on the draft? 17:54:39 ... what do you want them to do, and does it involve the TAG to get there? 17:54:52 masinter: I see people building things that don't work well because of inconsistencies in these areas 17:54:59 noah: but what should we do? 17:55:06 masinter: I'm ok with moving on 17:55:14 I don't know what else to do with those 17:55:23 ACTION-680? 17:55:23 ACTION-680 -- Jeni Tennison to lead TAG telcon review (rescheduled) of http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04 -- due 2012-04-24 -- PENDINGREVIEW 17:55:23 http://www.w3.org/2001/tag/group/track/actions/680 17:55:37 close ACTION-680 17:55:37 ACTION-680 Lead TAG telcon review (rescheduled) of http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04 closed 17:56:17 Topic: ISSUE-57 (HttpRedirections-57), ISSUE-63 (metadataArchitecture-63) and ISSUE-14 (HttpRange-14): httpRange-14 — URI Documentation Discovery 17:56:46 topic: httpRange-14 — URI Documentation Discovery 17:56:46 At one point in an AC meeting I argued for more "fixing the potholes" vs. "building bridges to nowhere" and that file extensions and magic numbers are potholes in the web architecture 17:57:04 http://www.w3.org/wiki/HTTPURIUseCaseMatrix 17:57:13 q+ 17:57:17 -JeniT 17:57:19 http://www.w3.org/wiki/HTTPURIUseCases 17:57:35 q? 17:57:39 q? 17:57:41 q- ht 17:57:56 ack next 17:58:53 AM: Jonathan, I have a small quibble. I'm tempted to look at 3rd row, see 1 fail, and say "ah ah". Then I go to the proposals and see nothing matching the left hand column entry "New status code" 17:58:58 JAR: Good point. 17:59:45 JeniT_ has joined #tagmem 17:59:55 JAR: That's an omission. Wasn't formatted as a change proposal, but we did get the proposal. I'll put on my "to do list" to document. The proposal is for something like an HTTP 209 status code meaning "what I'm giving you is a description, not a representation" 18:00:02 +??P1 18:00:20 I'm still talking to jonathan about the scenarios and the underlying assumptions that they seem to make (to me) 18:00:33 noah: have you got feedback on the matrix from the community? 18:00:40 NM: You asked the community to vet this. I'm feeling like you didn't get a lot of responses? 18:00:54 JAR: Yes, but for now, it only went to the www-tag list. 18:00:55 jar: I only really asked the TAG, and haven't really got feedback except from a couple of TAG members 18:01:14 Ashok: could you put in the left column a reference indicating the section in the other document? 18:01:42 q? 18:01:43 jar: yes, I will try 18:02:26 jar: if there are questions that people on this call have about the matrix, this might be a time to surface them, but email would also work 18:02:36 ... I'm not sure how to review this 18:03:06 noah: ideally this should lead to making a proposal 18:03:15 ... it might be that not all failures are equally bad for the community 18:03:30 ... so you might push forward to narrow discussion to just two or three 18:03:43 jar: we talked about forming a task group, and one has emerged 18:03:54 ... Henry, Jeni and I have been exchanging email for the past couple of weeks 18:04:02 ... we're working on a narrative for the issue behind the scenes 18:04:28 ... I have strong opinions about how to go at this 18:04:40 ... I'm trying to get support from Jeni and Henry on these ideas 18:04:51 ... they have strong opinions too, so we're going to try to get something between us 18:05:05 noah: the other thing I missed in the matrix, I wondered if there were things that it doesn't cover 18:05:33 ... for example, aside from use case J, I was looking for something that would break if there was a new status code 18:05:39 ... are all these deployable to some degree? 18:05:48 "deployable" has a scope. 18:05:50 jar: the question is who do we give veto power to 18:06:10 noah: what do proxies do if they see a status code they haven't seen before? 18:06:17 jar: I think it's specified in the HTTP spec 18:06:32 noah: doing some due diligence on what running code actually does would be a good idea 18:06:39 ... to see if the options are actually viable 18:06:58 ... many of these have fallen down when we look at what ISPs can do 18:07:10 jar: I don't know how to do that in the matrix 18:07:33 noah: I'm not saying how to format it, I'm saying do analysis early enough 18:07:40 jar: almost no one will accept a new status code 18:07:46 noah: but why? we need to capture that 18:08:03 ... it makes architectural sense to me, you say it fails only one use case 18:08:11 Ashok: browsers would have to implement it, right? 18:08:19 jar: they might treat it the same as a 200 18:08:37 ... one of the big complaints about the 303 is you have to do a song and dance around your server configuration, and that's what use case J is saying 18:08:52 ... maybe we should talk about the other goal 18:09:14 ... we have to think about how to generalise this 18:09:26 ... if this is an RDF-specific problem, we need to hand it off to people who care about RDF 18:09:37 ... draw some line to say what we think is good practice 18:09:57 ... there are some things that are TAG business, and others that are RDF business, and a lot of the proposals look like RDF business 18:10:11 ... we've been talking about use case M, HTTP consistency, which seems like a TAG issue 18:10:28 ... I have a proposal for how to do the hand off, but I want to wait for Henry and Jeni to agree or disagree about that 18:10:43 ... unless we want to talk about this on the call, maybe we should put it out to committee 18:10:49 Ashok: is this really a RDF problem? 18:10:54 jar: it depends on what you think the problem is 18:11:06 ... to me, it's a serious issue whether HTTP and RDF diverge 18:11:18 ... maybe it's ok if they diverge, but that suggests they should be careful in the language they use 18:11:25 ... so there isn't confusion about how web architecture works 18:11:28 For the record, http://mx.gw.com/mailman/listinfo/file is the mailing list which manages the magicnumbers/extensions 'registry'---there is no website for this, the closest there is is the README file from the 'file' package, e.g. http://hpux.connect.org.uk/hppd/hpux/Editors/file-5.11/readme.html 18:11:35 Ashok: suppose we took RDF off the table, here 18:11:40 ... what would we still have? 18:11:52 masinter: I don't think there would be things left 18:11:57 ht: there definitely would 18:11:59 i think this is a 'use of RDF' problem 18:12:07 q? 18:12:08 RDF doesn't have a problem, URIs don't have a problem 18:12:10 ... there are definitely things left that would matter 18:12:23 ... the language that important TAG members such as TimBL have used for years 18:12:27 ... is self-contradictory 18:12:38 ... if we care about clearing up a mess that we created, we have to fix that 18:12:44 ... and that would be true even if RDF didn't exist 18:12:48 it's people who want to turn "statements in RDF using URIs" into "statements about the real world" who want to take a URI and have it identify something in the real world 18:12:56 noah: I think on general principles, and given the TAG had this resolution years ago 18:13:15 ... I think it would be helpful to explain why it's not our business, if it isn't 18:13:22 absolutely 18:13:25 s/important TAG members/the TAG and TAG members/ 18:13:40 and the problem is that URIs were never intended as a general mechanism for identifying things int he real world 18:13:42 ... for example, Larry and I disagree about what HTTP status codes are used for 18:13:54 ... explaining what that answer is is very much in TAG's scope 18:14:03 ... especially as our last solution was to use a status code 18:14:11 people building ontologies think an ontology is a mechanism for turning idnetifiers for web resources into identifiers of concepts 18:14:21 ... I'd like to explain what the limits are of web architecture and their applicability to this problem 18:14:32 I also don't think we could just proffer a new status code as a solution without a story behind it 18:14:35 jar: it would be nice to get any bit of consensus we can on this 18:14:43 s/proffer/profer/ 18:14:49 s/Larry and I disagree/Larry and I didnt immedately agree/ 18:14:59 s/this/what's TAG business and what isn't/ 18:15:16 noah: if there are useful back-channel discussions happening, maybe we should hang loose for a while 18:15:29 ht: I think we have to work a bit longer towards convergence 18:15:40 ... I'm the major bottleneck, probably, but I'd like another week 18:15:53 q+ to talk about another approach 18:15:54 We're hearing that Jonathan, Henry and Jeni are working in the background to get some more clarity. Should we just hold off a couple of weeks and await progress? 18:16:00 Ashok: Henry, you've spoken about the language around content negotiation and so on being self-contradictory 18:16:13 ... do you have an idea how to fix that? 18:16:23 ht: no, I don't 18:16:35 ... I mentioned it because it's something I use to test proposed solutions 18:16:48 ... because I think 'it better solve this problem too' 18:16:51 ack next 18:16:53 masinter, you wanted to talk about another approach 18:16:58 ... the cardinality problem: how many resources are there? 18:17:21 -ht 18:17:27 masinter: I've been trying to pursue a different direction, where we have a mechanism for making statements in RDF 18:17:45 ... and an implicit assumption where you can use URIs to ground a statement in the real world 18:17:54 ... and the problem is the nature of the grounding is ambiguous 18:18:02 ... and we have given conflicting advice, using status codes and so on 18:18:22 ... the problems that we really want to talk about wrt publishing, linking, copyright, security, trust 18:18:38 ... are not easy to explain in a world where we presume that there is a common understanding about how a URI identifies something 18:18:52 ... and if you move to a different model, where you don't think about the truth of statement or their meaning 18:19:02 ... as something that's disembodied from the agent that is saying it or reading it... 18:19:07 ... and look at a speech act model 18:19:26 ... then you stop asking what the triple means, you look at intention 18:19:41 ... a speaker utters an RDF assertion using URIs, a receiver reads an interprets it, as a speech act 18:19:57 ... this is a different model, which is better suited to talking about the difference between copying something and linking to it 18:20:12 ... that you don't try to interpret statements independently of the context in which they are stated 18:20:31 ... this leaves httpRange-14 behind, because we're taking on a more complicated, less trusting model for communication 18:20:48 ... I've been trying to think about how to express the copyright & linking document we've been working on 18:20:55 ... if we were stating these things in RDF 18:20:57 This is the "choose based on context" proposal in the chart 18:21:02 ... and that gets you beyond the status code 18:21:17 noah: how much in RDF would have to be deprecated or turned off to use that new model? 18:21:34 masinter: we have systems that assume trust between communicators 18:21:43 ... you can't do induction unless you assume that everything is true 18:21:55 noah: so all the statements from DBPedia remain equally useful if we go down this path? 18:22:24 masinter: you have to put them into context that DBPedia is using, where maybe they intended you to look at 303 codes and maybe used something else 18:22:28 q? 18:22:38 ... it's part of a larger framework 18:22:51 noah: I'd be interested to see how far you could get on getting Tim to agree to this 18:23:01 masinter: I think I'm making some progress on him 18:23:09 jar: we have to figure out what problem we're trying to solve 18:23:15 ... we've had a hard time getting focus 18:23:31 ... these are all fine things to work on, but it's not what we started with 18:23:38 ... this isn't an issue for the linked data community 18:23:45 masinter: I think when you get to linked data in the real world 18:23:50 ... with government agencies publishing data 18:23:54 ... we will need a better model 18:23:55 +1 18:24:00 jar: but is that the TAG's problem? 18:24:11 ... that's a problem for linked data, and they will figure it out for themselves 18:24:20 ... right now we're doing design for nobody if we take this on 18:24:59 noah: maybe if you change the ground rules, the solutions are different 18:25:08 masinter: I think the question being asked isn't interesting 18:25:28 jar: this is why I want to get it out of the TAG 18:25:40 masinter: we can say we're working on something else which is more important 18:25:55 noah: we have to be careful about how we do this after 8 or 2 years 18:26:11 +TimBL 18:26:16 ... we could look really stupid, beating our heads on this for ages, and finally to say it's not our problem 18:26:21 ... I would have a problem with that 18:26:22 i think we should drop 'findings' more than 2 years old if we can't bring them to community consensus 18:26:31 ... why did this appear to be a problem for so long? 18:26:41 ... we should have figured out a long time ago that this wasn't our problem, if it's not 18:26:54 ... I think the answer is about how to use HTTP "properly" 18:26:59 ... and that is the TAG's problem 18:27:01 q+ 18:27:17 timbl: sorry for arriving late 18:27:23 ack next 18:27:37 ... having discussed this with jar just yesterday 18:27:52 ... I think the hope has been, for me, that the TAG would be able to describe an architecture that included linked data 18:28:04 ... the original architecture didn't: it was a hypertext system, it didn't include RDF 18:28:20 ... the problem has been partly that there's a small overlap between the TAG and the RDF community 18:28:39 ... a relatively small overlap in general between linked data and people doing things with HTTP 18:28:54 ... I think RDF should use HTTP properly 18:29:07 ... it may be that the niceties of how RDF works can't be discussed with non-RDF people 18:29:32 ... so we end up with an architecture that is consistent with HTTP, but is more detailed and refined 18:29:44 -Ashok_Malhotra 18:29:49 noah: one of the proposals that seems to have a low number of downsides is to use a new status code 18:30:05 ... I would have thought that the TAG should explain whether that's architecturally appropriate 18:30:15 ... the RDF community might separately settle on whether they want to do that 18:30:22 ... do you think that's more than what the TAG should be doing? 18:30:33 timbl: if the TAG can solve this, great, write it up 18:30:45 ... I regard httpRange-14 and the 303 header as a compromise 18:30:52 noah: we're discussing jar's matrix 18:31:26 ... one of the proposals is to use a new status code 18:31:30 207, 208, 209 18:31:56 refresh the page 18:31:57 ... I'm just probing because you seemed to be saying the TAG should back off because the communities were separate 18:32:15 ... I would say the TAG has a role to play to say whether it's an appropriate to use a status code for this 18:32:44 timbl: there are a lot of issues here where it's only the TAG who are chartered to do this 18:32:57 ... but I think it would also be reasonable to just make this work for linked data 18:33:24 ... if we had a new status code, we would have to explain how to do so, maybe push towards hash more strongly 18:33:36 ... still have to deal with simple OGP as well 18:33:47 ... there's valuable work to be done here 18:33:55 noah: we're at time 18:34:16 ... Jonathan, Henry and Jeni have been talking behind the scenes to move towards more clarity 18:34:24 ... I'm inclined to wait a week or two and see what happens 18:34:31 jar: agreed 18:34:47 timbl: I'd be happy to be brought up to date offline 18:35:02 masinter: when they come to a conclusion, they should bring it to us 18:35:13 ACTION-691? 18:35:14 ACTION-691 -- Jonathan Rees to prepare table as described in 2012-04-04 minutes, for TAG review -- due 2012-04-24 -- PENDINGREVIEW 18:35:14 http://www.w3.org/2001/tag/group/track/actions/691 18:35:22 close ACTION-691 18:35:22 ACTION-691 Prepare table as described in 2012-04-04 minutes, for TAG review closed 18:35:53 masinter: eliminate from consideration all but three rows 18:36:01 jar: I'm not sure we have standing to do that 18:36:05 noah: you could do it as a proposal 18:36:13 . ACTION: Jonathan with help from Jeni and Henry to try to identify next steps for moving forward on httpRange-14 18:36:34 . ACTION: Jonathan with help from Jeni and Henry to try to identify next steps for moving forward on httpRange-14 - Due 2012-05-15 18:36:38 ACTION: Jonathan with help from Jeni and Henry to try to identify next steps for moving forward on httpRange-14 - Due 2012-05-15 18:36:38 Created ACTION-704 - with help from Jeni and Henry to try to identify next steps for moving forward on httpRange-14 [on Jonathan Rees - due 2012-05-15]. 18:36:48 masinter: come back with the same number of rows as the number of people in the subgroup 18:37:19 -Masinter 18:37:23 I don't like any of the proposals, because I don't like the question 18:37:24 We are ADJOURNED. Informal discussion can continue. 18:37:37 rrsagent, draft minutes 18:37:37 I have made the request to generate http://www.w3.org/2012/05/03-tagmem-minutes.html JeniT 18:37:52 -Noah_Mendelsohn 18:37:54 -plinss 18:37:55 but at least if you're going to continue to ask the same question, come back with at most N rows, where N is the size of the subgroup 18:37:55 -Jonathan_Rees 18:38:01 -JeniT 18:38:09 TAG_Weekly()1:00PM has ended 18:38:10 Attendees were JeniT, Masinter, ht, plinss, Ashok_Malhotra, Jonathan_Rees, Noah_Mendelsohn, TimBL 18:38:54 s/the same number of rows/at most the number of rows/ 18:52:50 JeniT has joined #tagmem 19:11:50 JeniT has joined #tagmem 20:30:37 Zakim has left #tagmem 21:01:03 JeniT has joined #tagmem 21:28:57 jar has joined #tagmem 23:31:30 jar has joined #tagmem