00:02:56 rrsagent, draft minutes 00:02:56 I have made the request to generate http://www.w3.org/2012/06/14-tagmem-minutes.html JeniT 00:10:58 ht has joined #tagmem 00:32:57 Zakim has left #tagmem 01:29:30 jar has joined #tagmem 02:14:16 timbl has joined #tagmem 13:02:36 RRSAgent has joined #tagmem 13:02:36 logging to http://www.w3.org/2012/06/14-tagmem-irc 13:02:38 RRSAgent, make logs public 13:02:40 Zakim, this will be TAG 13:02:40 ok, trackbot; I see TAG_f2f()8:00AM scheduled to start 62 minutes ago 13:02:41 Meeting: Technical Architecture Group Teleconference 13:02:41 Date: 14 June 2012 13:02:53 scribe: Ashok 13:03:08 noahm has joined #tagmem 13:03:59 Topic: ISSUE-57: URI Documentation Discovery 13:07:16 TAG_f2f()8:00AM has now started 13:07:17 +Yves 13:07:42 jar: We will start with "parallel properties" proposal 13:08:00 ... we have slides and Wiki page 13:09:25 JT: We would like approval to pursue this as the technical direction 13:11:46 Technical proposal details: http://www.w3.org/wiki/TagIssue57Proposal26 13:12:09 -Yves 13:12:10 TAG_f2f()8:00AM has ended 13:12:10 Attendees were Yves 13:12:35 it's just a *proposal* for discussion, one among many possible 13:14:14 JT: Semantic Web / Web with import 13:14:34 s/Semantic Web/semantic web/ 13:14:55 s/import/impact/ ? 13:14:56 ... we care about how URIs are used with imported data 13:15:13 ... agents act on info that you put on the web 13:15:33 ... two use cases 13:16:01 ... properties associated with documents and 13:16:15 ... properties associate with things 13:16:34 ... could be any kinds of things --- not documents 13:17:13 ... they generally don't care about document propoerties 13:17:26 ... they want to get more properties about the thing 13:17:38 1+ to say that data things do care about the document it came from in 2 cases 1) trust from provenance and 2) error siuations 13:17:56 ... issues about trust, provenance, age etc. 13:18:06 q+ to say that data things do care about the document it came from in 2 cases 1) trust from provenance and 2) error siuations 13:18:15 s 13:19:18 JT: People uae URIs in XML/JSON as if they stand for things e.g. Wikipedia, etc 13:19:31 ... I characterize this as naive URI usage 13:19:45 ... also used in Microdata and RDFa 13:20:27 timbl_ has left #tagmem 13:20:33 ... alos applies where URIs are used for properties 13:20:33 q+ bob to say that when the URI is used in JSON say, there is no commitment to the RDF model and so limited damage 13:20:43 s/alos/also/ 13:21:03 ... easy to copy/paste from browser bar 13:21:44 JT: We want to distinguish these two uses of URIs 13:22:13 ... we want people who use URis in this naive way to move to a more sophisticated use of URis 13:23:33 ... URI identifies a document which corresponds to something 13:23:50 ... another term for this is that the URI denotes the thing 13:23:54 JT: We are calling this parallel properties 13:24:04 Sandro wrote about this "parallel properties" approach in 2010: http://decentralyze.com/2010/11/10/simplified-rdf/ 13:24:52 \JT: Example (get URI for example page later) 13:25:10 s/\JT/JT/ 13:26:33 The URIs denote to things or properties of things 13:26:56 s/to// 13:29:47 JT: Lay out the language "identifies","denotes", "describes" 13:30:39 ... the context determines whether URI determines its interpretation 13:31:03 ... We suggest interpretation depends on RDF properties 13:31:18 [wget http://schema.org/Person ... HTTP request sent, awaiting response... 200 OK ... Person' saved (18274 bytes) (text/html)] 13:32:04 ... dc:creator subject and object are documents 13:32:30 ... schema:nationality subject and object are things described by documents 13:34:52 ... s/documents/documents - must 303 on object or use #URI/ 13:35:35 JT: What do you get when you resolve a URI 13:35:50 ... document is what you get when you resolve a URI 13:36:16 ... Works acroess URI schemes and conneg variants 13:37:02 ... Non-successful resolution implies there is no document -- 303 to think described by document 13:37:30 ... single document may correspond to multiple things 13:37:58 ... media type / prop specifies which one 13:38:23 ... Non-existent documents can correspond to things 13:38:47 ... For merging of data, it helps to have a single main topic 13:41:32 JT: Anther example (get URI from Jeni) 13:41:44 s/Anther/Another/ 13:42:59 JT: URI corresponds to the country 13:43:27 ... schema properties indicate properties of that thing 13:46:47 JT: What we win 13:47:21 ... people can publish when using appropriate media types/vocabularies 13:47:41 ... consistent with RDF model and reasoning 13:48:21 ... Helps people who have published in a naive way to publish in a sophisticated way 13:48:42 q+ charlie to say disappointed in use of identifies" 13:48:51 ... Evolve to provide separate URIs for things 13:49:06 q+ dick to say this ismaybe RDF-ER 13:49:09 ... Details need to be worked out 13:49:36 ... RDF properties need to be defined 13:50:05 q+ egbert to say that the "correspondsTo " matches foaf:primarySubject 13:50:16 ... what do we do with existing vocabularies which have not be defined in this way 13:50:50 Moving to questions of clarification 13:50:58 q? 13:52:28 ht: That's "corresponds to" on the early slide, not "describes", yes? jt: yes 13:53:11 q+ to ask what this does for references not in a media-typed context 13:53:17 ht: schema:natinality subject and object are things "corresponded to" by documents 13:53:44 Tim: Asks about algorthm about parsing RDFa 13:53:52 tbl: Is there an algorithm for what you've described that's a modification of the RDFa algorithm 13:54:07 jt: No modification, the same algorithm 13:54:30 tbl: But that only gives you relations between documents, I want the relations between the things 13:55:12 tbl: Is the squares+circles diagram in your example an RDF graph 13:55:28 s/graph/graph?/ 13:55:28 JT: No same algorithm 13:58:18 Tim: How do I change my code 13:58:31 jar: You don't need to change your code 13:59:02 Tim: Is there a function that returns a RDF graph given a serialization? 13:59:06 jar: No 14:01:48 NM: This assumes references exist in a media type context 14:02:11 ... is this correct? 14:02:28 ... is there a solution where that is not the case 14:02:43 JT: No changes to how the Web works today 14:05:13 NM: [about context in the story] 14:06:38 HST: Coming back also to TBL's question: The examples we had in mind, which are the easier ones to understand, are 1) message is text/html, with URI in context a Person. Other contexts can be managed, but the story is more complicated 14:07:01 rrsagent, pointer 14:07:01 See http://www.w3.org/2012/06/14-tagmem-irc#T14-07-01 14:29:37 ht has joined #tagmem 14:30:13 Discussion between Jeni and Tim re translation of JSON to RDF. Depends on application? Determined by media type? 14:30:29 TAG_f2f()8:00AM has now started 14:30:30 +Yves 14:31:53 JT: The media-type tells you how to interpret the URI 14:32:08 + +1.617.715.aaaa 14:32:11 ... just pure JSON does not 14:32:49 ack next 14:32:50 timbl, you wanted to say that data things do care about the document it came from in 2 cases 1) trust from provenance and 2) error siuations 14:33:08 JT: For example JSON-LD provides the context 14:33:53 timbl: Need to localize source of error 14:34:06 ... also for provenannce 14:34:15 ack a 14:34:20 ack b 14:34:20 bob, you wanted to say that when the URI is used in JSON say, there is no commitment to the RDF model and so limited damage 14:34:48 (Tim will provide URI to slides later) 14:35:22 Tim: RDF does not have to define what JSON means 14:38:01 ack c 14:38:01 charlie, you wanted to say disappointed in use of identifies" 14:44:06 HT: I would rather not assume there is a primary topic in the graph 14:45:16 darobin has joined #tagmem 14:48:17 jar: Some vocabulary to help people think more rigorously is a good thing 14:50:48 ... you get consistenct through model theory 14:51:11 s/consistenct/consistency/ 14:51:20 q? 14:52:23 q+ noah2 to make a concrete proposal on documenting this 14:52:53 ack d 14:52:54 dick, you wanted to say this ismaybe RDF-ER 14:53:07 Charlie has been uses "identifies" for a long time 14:54:10 Dick is worrying whether this is RDF E-R 14:54:57 jar: No, it is adding information and clarifying the relationships 14:55:34 Tim: So, tabulator has to do some up-front forward chaining on these properties 14:56:42 ... I can hang an event handler that alerts me when I have a parallel property and I can then do some forward chaining on it 14:57:03 ack e 14:57:03 egbert, you wanted to say that the "correspondsTo " matches foaf:primarySubject 14:57:14 q? 14:58:02 timbl: So, what tabulator does, is that if it sees that a property is a "parallel" property, it can do some forward chaining via the implied property chain. 14:58:06 jar: yes 14:58:24 timbl: but then you end up with some extra gubbins in the graph that you don't care about it 14:58:31 jar: In order for tabulator to work, it need to know what subset of properties is the parallel ones. 14:59:07 noah: The subset has to be detectable in a discoverable way (by machine) 14:59:08 jar: yes 15:01:06 SO in practice, in tabulator, I can hang an event handler on a new statment { ?p a ParallelProperty } and when I get that i can hang an event handler on any new statement of the form { ?s PP ?o } for the given PP, and then from that I can then add the deduced from the primary topics of ?s and ?o, and so there will, thorgh smshing, end up with a reasonable graph about s' and o' , although alas much flotsam and jetsam from the arcs which were used to generate it, 15:01:06 als when I ask why the system beleives s' pp' o', I will get ":inference" rather than "document d". 15:01:16 jar: Do I have general agreement on my diagram with boxes {URI, protocol behavior, generic resource, RDF graph, topic}?... 15:01:21 jt: Let's talk about that later 15:01:52 s/primarySubject/primaryTopic/ 15:01:58 ack next 15:02:05 q? 15:02:07 noahm, you wanted to ask what this does for references not in a media-typed context 15:02:13 jar: I don't like calling it 'primary topic' for reasons I could go into, but we can defer that 15:02:14 jenit: no, egbert, corresponds to is not equivalent to primaryTopic 15:02:50 q+ 15:03:56 ht: Graph merging is easy if you know what the primary topic is 15:04:03 hst: +1 to avoiding "primary topic" 15:05:01 I suspect that "smshing" is what I think of as unification 15:05:19 q? 15:06:35 NM: You said media type was important ... I came away with the feeling that may not be so important 15:06:48 ... what do you JT think is the role of the media type 15:07:39 JT: Mapping from message to a knowledge represenation. If that has links to documents, can we make inferences and add some extra nodes 15:08:18 ... how you interpret depends on media type of the message 15:09:51 NM: Is your solution only applicable if you have a media type 15:10:18 HT: The media type gives you information you can make some inferences 15:12:01 JT: If you don't have a media type you cannot make the inferences 15:14:56 Tim: This is monotic ... it adds to RDF 15:15:17 s/monotic/monotonic/ 15:16:10 The media type *might* say that strings that look like URIs are actually to be interpreted in a completely different way 15:16:19 JT: We need that story that applies to other than RDF 15:17:27 NM: Could you provide an "Idiots Guide" as to how to use it. 15:17:32 Jar: Agree 15:17:49 q? 15:17:54 ack next 15:17:55 noah2, you wanted to make a concrete proposal on documenting this 15:18:15 jar: We will need two documents. A straightforward HOWTO, and then a (relatively) rigorous justification 15:18:30 JT: There is a simple way to explian this and then a more a rigorous way 15:19:45 AM: Do we need a vocabulary/ontology? Do we need to get agreement on this 15:20:01 JT: We getting to the procedural part 15:20:28 q- 15:21:24 s/explian/explain/ 15:22:16 jt: How we deal with rdf:type depends on default rule, etc… need to dive into technical details, maybe defer 15:23:02 NM: We have a proposal for direction. Who thinks this is promising? Should we pursue this solution? 15:23:36 jar: Two questions re rdf:type, whether the type's URI is interpreted (in the model theory) as a document or as a class, and whether the type is a type of documents or a type of things documents are about 15:24:05 Tim: This is a sweet spot. It mitigates issues one usecase has. 15:24:27 http://www.w3.org/wiki/HTTPURIUseCaseMatrix 15:25:01 ... perhaps 209 could be combined with this 15:25:30 timbl: Pursuing this means going through all of the use cases and saying what to do in each case 15:27:41 noah: Tim's response to pursuing parallel properties seems roughly positive 15:29:13 jar: Larry said it was good because it works for Linked Data and is protocol agnostic 15:29:24 NM: Next steps? 15:29:31 lm's requirements: works for community, works for protocols 15:29:34 (IIRC) 15:33:43 jar: projects document showing next steps 15:35:19 4 steps 15:35:48 - Report back to people who submitted change proposals 15:36:27 - Document presenting "how to guide" 15:36:37 - Document with careful semnatics 15:37:05 - Spin up a CG or something 15:37:10 s/semnatics/semantics/ 15:37:40 ... CG would start with tehse documents and run with them 15:37:50 s/tehse/these/ 15:39:08 Tim: To solve problem this way -- parallel properties 15:39:44 ... need to say this is not punning 15:40:45 Tim: Do parallel properties happen on subject and object 15:41:04 jar: Needs to be decide. We have a few design options 15:41:14 s/decide/decided/ 15:44:03 s/or something// 15:44:49 jar: are there any other things we need to do? 15:46:00 noah: this looks right, but we have to do it right to smooth the way 15:46:27 ... if we just drop it on people then they might unnecessarily be concerned 15:46:41 ... should we gradually socialise this? 15:47:07 jar, jenit: yes, we should, especially with potential CG members 15:47:22 noah: then we can see how that goes, and determine what to do from there 15:49:07 jenit: we need to write up an "it" to socialise people with, and the "it" is different for different people 15:49:27 timbl: there's updating a bunch of how to do linked data documents 15:49:48 jar: yes, particularly the 'standard hash URI pattern' 15:49:56 ... also the 200 with parallel properties pattern 15:50:19 ht: we need to look more carefully at what it'll look like when people adopt this and there are hash URIs around 15:50:29 ... we haven't looked at that enough 15:51:12 ... looking at how people who always use hash URIs interoperate with those that use parallel properties and so on 15:51:20 ... this needs to go in a primer 15:51:52 timbl: in a primer, you say use hash URIs and turtle 15:52:23 ht: I want to draft the bit at the end that says what to do when someone sends a graph that uses REHUs and you want to add statements to it, how do you do that? 15:53:12 ... people who follow Tim's directions need to interoperate with those who don't 15:53:36 ... perhaps that's part of the how to 15:54:01 timbl: there's a big warning that you shouldn't use schema.org properties with proper RDF 15:54:23 ... you could add an option to COOM (?) to strip out the original properties 15:54:36 jar: ideally a validator would be an integral part of the CG process 15:55:28 jenit: we need to get the community engaged in doing the backup work 15:56:04 timbl: when you create a quad store in Tabulator, you specify whether its a dumb store or one that does reasoning 15:56:18 ... maybe this smushing stuff is done in the latter level 15:57:03 maybe we need another level, or maybe the pp stuff is done whenever smuthing on FP and IFP is done. 15:57:13 s/uthi/ishi/ 15:57:37 jenit: do we draft something, gradually expose those to targetted people to? 15:57:50 ht: we should be up front that we're preparing documents to hand off to the CG 15:58:06 jar: we thought the TAG should stay involved in this, it's not a hand off 15:58:20 yes 15:58:41 noah: the TAG continues to have open issues in this area, and we are involved 15:59:03 ... and we hope the CG will just run with it, we hope, but if they run into the ground, we need to be there to help 15:59:26 jar: there's a good chance this will run into weeds if we just leave it to others 15:59:49 noah: the TAG has members with expertise and interest, we've spent energy on it 16:00:12 ... I don't want to make an in-advance commitment of TAG resources to it as such 16:00:27 jar: we have to say whether it's hand-off or delegation 16:01:01 noah: the TAG plays a role in every group 16:01:39 timbl: should the CG report back to us? 16:02:00 jar: we're concerned with architecture in constituencies who won't be involved in the CG 16:03:55 jenit: there's the RDF bits of the proposal, and the wider architectural bits 16:04:36 noah: the TAG expects to be involved in coordinating liaison with those concerned with wider issues, such as protocols 16:05:08 jar: there's the broader interoperability question, from protocols to OWL 16:05:21 ... and there's how that gets realised in RDF, which is the responsibility of the CG 16:05:35 ... I think only people from the linked data community will join the CG 16:05:51 noah: what should we be saying to them? 16:06:01 jar: we should bring the wider architectural definition to Rec 16:06:27 noah: so there would be investment in that bit of work 16:06:37 jar: I don't think that would need to be an RDF document 16:07:37 jenit: it's a Rec that substitutes for the httpRange-14 decision 16:08:28 jar: yes, something that supersedes httpRange-14 and its question, which in general terms explains how HTTP and OWL interoperate 16:08:41 ... and URI meaning or something 16:09:08 ... and the second one is presenting RDF model theory as it fits with that 16:16:40 Ashok has joined #tagmem 16:25:55 -Yves 16:29:17 Here is the file I projected during the preceding discussion: http://www.w3.org/2001/tag/2012/06/issue-57-notes.txt 16:43:23 - +1.617.715.aaaa 16:43:25 TAG_f2f()8:00AM has ended 16:43:25 Attendees were Yves, +1.617.715.aaaa 17:13:29 timbl has joined #tagmem 17:23:44 schema.org example from slides this morning http://www.w3.org/wiki/WebSchemas/ExternalEnumerations 17:26:48 scribenick: plinss 17:27:32 present +plh 17:29:16 topic: proliferation of uri schemes 17:29:47 NM: there have been a number of proposals from a number of groups 17:30:13 … there's a document coming from the ietf making it easier to invent schemes 17:30:31 http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg-04 17:30:54 Zakim has left #tagmem 17:31:17 ACTION-694? 17:31:17 ACTION-694 -- Noah Mendelsohn to work up simple intro to http+aes uri scheme and schedule discussion, possibly with PLH -- due 2012-06-05 -- OPEN 17:31:17 http://www.w3.org/2001/tag/group/track/actions/694 17:31:38 plh has joined #tagmem 17:31:39 http://www.w3.org/TR/webarch/#URI-scheme 17:31:45 -> http://www.w3.org/TR/html5/iana.html#web-scheme-prefix web+ scheme prefix 17:32:01 From Webarch: 17:32:02 While Web architecture allows the definition of new schemes, introducing a new scheme is costly. Many aspects of URI processing are scheme-dependent, and a large amount of deployed software already processes URIs of well-known schemes. Introducing a new URI scheme requires the development and deployment not only of client software to handle the scheme, but also of ancillary agents such as gateways, proxies, and caches. See [RFC2718] for other considerations 17:32:12 -> http://www.whatwg.org/specs/web-apps/current-work/#http+aes-scheme http+aes 17:32:32 NM: there's a direction in web arch that schemes are expensive and should be avoided 17:32:52 Zakim has joined #tagmem 17:33:26 PLH: aes in not in html space, it was a proposal from pixie and didn't get much traction 17:33:30 PLH: http+aes was a proposal from Ian Hickson. My perception is that it didn't get traction. 17:33:34 http://datatracker.ietf.org/doc/draft-farrell-decade-ni/ 17:34:04 TAG_f2f()8:00AM has now started 17:34:06 s/pixie/Hixie/ 17:34:06 +Yves 17:34:30 Peter grumbles about auto-correct 17:34:59 rrsagent, where am I? 17:34:59 See http://www.w3.org/2012/06/14-tagmem-irc#T17-34-59 17:36:05 + +1.617.715.aaaa 17:37:10 Quoting from RFC 4395bis [http://datatracker.ietf.org/doc/draft-ietf-iri-4395bis-irireg/?include_text=1], section 3.1: For these reasons, the unbounded 17:37:10 registration of new schemes is harmful. New schemes should have 17:37:10 utility to the Internet community beyond that available with already registered schemes. The registration document SHOULD discuss the 17:37:10 utility of the scheme being registered. 17:38:04 NM: here's a counter-example of no-one referencing our documents 17:38:41 PLH: http+aes is not in the html wg space 17:38:46 -> http://www.w3.org/TR/html5/iana.html#web-scheme-prefix web+ scheme prefix 17:39:30 … this is a attempt to simplify web intent 17:39:55 … it's a way for a web site to declare they have the means for example to edit an image 17:40:47 … it's a way for web application to declare they can perform certain kinds of actions 17:41:04 JT: an example would be sharing something on twitter 17:41:31 … you could have a single share button and your client knows which networks to share on 17:41:39 -> http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html Web Intents 17:42:20 … because you've visited a page (e.g. twitter) that has the web intent and says it can "do the share" 17:42:53 NM: which one has the web+ 17:43:01 JT: I don't know 17:43:20 jar_ has joined #tagmem 17:43:29 PLH: web+ was an attempt to try to harmonize registerProtocolHandler 17:43:29 -> http://dev.w3.org/html5/spec/system-state-and-capabilities.html#custom-handlers 17:44:10 timbl__ has joined #tagmem 17:44:10 NM: so you are registering a JS handler on your page? 17:44:31 JT: this is different from web intents but solves the same kind of issue 17:45:26 NM: so if gmail wanats to register as a handler for mailto: which page has this call? 17:46:15 timbl_ has joined #tagmem 17:46:36 timbl has joined #tagmem 17:47:16 timbl_ has left #tagmem 17:47:32 PLH: with web intents when the UA gets a request to share it pops up a dialog to ask the user which web apps to choose to do the share 17:48:01 … web+ is not a scheme, it'a prefix one can append on top 17:49:05 HT: where would web+ uris originate from? 17:49:48 TBL: they originate in something that wants to play music for example 17:50:10 HT: that's handled by registering content handlers not scheme handlers 17:53:11 NM: Gives an example of mailto:. The OS would normally launch Outlook or Thunderbird -- this allows you to redirect to GMail instead (I think) 17:54:23 I don't see why not to use data:mediatypewithregisteredhandler,parameters 17:54:50 HT - questions where web+ comes from and how it's used 17:54:51 http://www.w3.org/TR/html5/iana.html#web-scheme-prefix 17:56:54 HT: my understand of this is that it would not make sense to register web+x for any existing value of x, especially http: or ftp: 17:58:07 NM: schemes must be whitelisted or web+ to be registered as handlers 17:59:01 AM: what's behind this? 17:59:28 q? 17:59:31 PLH: that's why I started with web intent, more apps will be on the web rather than a desktop app 17:59:47 q+= timbl + jenit 18:00:08 queue=timbl,jenit 18:01:09 discussion of data: url and content handlers 18:01:26 data: seems a good alternative to web+ (doesn't help with the whitelisted schemes of course) 18:02:16 q? 18:02:21 ack next 18:02:49 TBL: if web apps are supposed to be first class processors, can a web app supply an intent? 18:03:26 … suppose you want to had one tab provide a bunch of services, it could open a local web server or... 18:03:47 PLH: there are the web+ things and the web intents things to do that 18:07:31 discussion about running services in a local browser 18:07:45 TBL: is it easy to provide a web intent in a web app? 18:09:09 discussion about handling web intent locally vs remote server 18:09:12 q? 18:09:13 q? 18:09:15 ack next 18:09:35 JT: how recently has the been discussion about web+? what's is status? 18:09:55 PLH: it's actively being worked in in the HTML wg 18:10:18 … there's an issue about coordination with IETF 18:10:50 YL: there's a discussion about web+ on the apps wg at IETF 18:11:07 JT: what about coordination with web apps and web intent 18:11:17 q+ to ask whether we should look at other schemes like enc; acct: ni: 18:11:19 PLH: I don't know about that 18:11:23 -> http://www.w3.org/html/wg/tracker/issues/189 Issue 189 18:11:39 ack next 18:11:40 noah, you wanted to ask whether we should look at other schemes like enc; acct: ni: 18:12:10 NM: we've heard about other schemes, do we want to look at them? 18:12:28 I forwarded: http://lists.w3.org/Archives/Public/www-tag/2012Jun/0062.html 18:12:33 about enc: 18:12:48 -> http://lists.w3.org/Archives/Public/public-html/2012Feb/0272.html Change proposal: Don't assign a special meaning to the prefix "web+" 18:13:23 -> http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-189 Disambiguate the web+ prefix definition from IANA registrations 18:14:22 JAR: this is the same as ni: 18:15:16 -> http://tools.ietf.org/html/draft-farrell-decade-ni-04 18:18:36 NM, TBL: ni: only specifies the hash for lookup 18:19:17 "making the case for acct:" http://hueniverse.com/2009/08/making-the-case-for-a-new-acct-uri-scheme/ 18:19:47 NM: the IETF mailing list has had a lot about the acct: scheme 18:19:51 http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05947.html 18:20:44 … acct: relates to web finger 18:21:01 acct: proposal in Webfinger draft: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-02#section-5 18:21:35 … this is a proposal that says http: uris aren't a convenient way to refer to people 18:21:53 … looks like an email address but isn't one 18:23:23 HT: this is designed to only be used in web finger (now web discovery), not in href's 18:25:01 noah: why wouldn't I put an acct: URI in an href? 18:25:13 ht: acct: has no semantics outside webfinger requests 18:25:31 ... the proposal is for things that only appear in webfinger exchanges 18:25:45 ... they're not addressing what happens if they escape into the wild 18:25:52 noah: then why use URIs? 18:26:05 ht: because everything else is URIs 18:26:10 timbl: they used to use email addresses 18:26:14 ht: they dropped that a few months ago 18:26:29 jar: not all accounts provide mailto addresses 18:26:37 ... for example, facebook 18:27:34 timbl: instead of mailto: they use acct:, so you don't imply there's an email address 18:27:47 ht: the two specs being merged are webfinger and simple web discovery 18:28:15 ... Paul Jones is the lead editor of both, and the merger is probably going to be called simple web discovery 18:28:56 ... because it's trying to be more generic than being about people, which 'finger' was about 18:29:07 ... the merged spec is about everything 18:29:15 ... for example you can make a request about an HTTP URI 18:29:23 jar: isn't this what well-known was about? 18:29:28 timbl: we should read this in more detail 18:30:00 ... the usage case for WebFinger was when you find an acct: or mailto: URL, the system will get an HTTP URL back 18:30:07 ht: that's the second step, yes 18:30:21 timbl: if the first HTTP URI gives you back RDF, then you're set 18:30:33 q? 18:31:28 NM: I'd like guidance from the group if the TAG should engage here or look at our general advice 18:32:27 JAR: I think this is web architecture, we should at least survey the extensibility points 18:33:06 … we should look at the problems first, then the solutions 18:35:06 AM: many of these schemes are about metadata discovery 18:36:14 JAR: people are just looking for how to solve a problem and not worrying about architecture 18:38:33 NM: I need to know how to move forward on this 18:38:57 JAR: I want someone to summarize this on www-tag 18:39:40 HT: I can do that, but not in the next 4 weeks 18:39:40 . ACTION: Henry to investigate possible TAG efforts on URI scheme proliferation and extension points 18:40:12 ACTION: Henry to investigate possible TAG efforts on URI scheme proliferation and extension points - Due 2012-08-01 18:40:12 Created ACTION-724 - investigate possible TAG efforts on URI scheme proliferation and extension points [on Henry Thompson - due 2012-08-01]. 18:41:51 NM: let's wrap this 18:43:04
18:43:19
18:44:19 s/
// 18:46:04 -Yves 19:17:44
19:18:05 topic: TAG effectiveness part 2 19:20:24 noah: is there anything people particularly want to say? 19:20:48 PL: I'll talk to people at CSS F2F and similar meetings. They ask "what's the TAG"? 19:20:57 PL: They don't know or care. 19:21:06 JAR: Do you know if they'd care if they did know? 19:21:11 PL: Not sure. 19:22:09 PL: There is a part of the W3C community that would welcome help. Their perception is TAG is off doing that "academic semweb stuff" 19:22:17 TBL: Ironic, exactly what we're not doing/ 19:22:44 q? 19:23:45 timbl: maybe we should approach WGs and ask them if they have architectural issues in their area 19:24:10 noah: we can sometimes go and shed a light on an architectural area in a WG, and that's welcomed 19:24:26 ... sometimes we try to stop WGs from doing things that have long-term negative impacts 19:24:40 ... if we go "here we are" many groups will say "are they gone yet?" 19:25:00 Ashok has joined #tagmem 19:25:05 timbl: I was suggesting that we go and ask them what architectural patterns they have found, and pull them together 19:25:31 noah: do you think they would be happy about having their primary work interrupted? 19:25:42 timbl: I think it will vary by group 19:26:16 q? 19:26:29 Ashok has joined #tagmem 19:26:29 ... suppose we use the chairs list? 19:26:44 ... ask someone to nominate an architecture dude within a group 19:26:59 ... someone who could answer the question, who we could talk to 19:27:14 ht: having been in the XML Core WG as well as the TAG has been a real help 19:28:02 ... a lot of WGs will just be silent 19:28:34 ... a few will say go away 19:28:43 ... and some will say, here's someone who will do it 19:29:02 noah: what if they're cheerful volunteers, who will take up our time? 19:29:18 ... this has worked best when TAG members read WG specs in detail 19:29:49 ... the risk is that the person understands their specs, but doesn't know about architecture 19:30:19 plinss: if they send someone who doesn't get webarch, we should take that as a educational opportunity 19:30:36 ... it would help us disseminate the TAG's message 19:30:47 noah: if we get a lot of people then we're in trouble 19:31:08 ... if I have 20 people calling me, it takes me a long time 19:31:17 plinss: I don't mean that you should be doing all this 19:31:40 timbl: could we have WGs allocated to TAG members? 19:31:56 ht: there are a lot of them 19:32:11 jar: what about a list of the problems to which an architecture would be a solution 19:32:15 ... like registry design 19:32:29 ... instead of coming up with an answer, maybe we list a bunch of the problems 19:32:49 ... ask them if they have one of these architectural problems, and then say we want to talk to them 19:32:59 noah: sounds like something we can engage the WG chairs with 19:33:14 ... I'm not sure we could characterise them 19:33:30 jar: I think we only talk about extensibility points and registry design 19:33:58 I asked whether we talked about anything else 19:34:24 noah: maybe we can craft a message to the chairs, to say that they should be watching for these things 19:34:46 ... perhaps part of the Rec approval process is that they check off against that list 19:36:10 jar: I've been thinking about this for a long time 19:36:17 ... there's a big distance between TAG and WGs 19:36:32 ... if the TAG had unlimited manpower, we'd review every spec through the process 19:36:38 ... as early as we could 19:36:41 ... but that's impossible 19:36:51 ... so is there a sweet spot? 19:37:04 ... if we say that there are particular things we'd review for 19:37:23 ... the WGs won't bring it to us, and they might not recognise that the problem is an architectural issue 19:37:45 noah: a lot of the filtering has to happen outside the TAG 19:38:06 jar: we might be able to ask if drafts create new namespaces, let us know 19:38:17 noah: perhaps this relates to improving education outreach 19:38:52 ... we'll tell them they should be thinking about X, and they might not understand what that is 19:39:11 ... if we put out more material to educate them, maybe it will help them recognise arch issues 19:39:34 jar: if we write something people want to read, it has to derive from the experience that's being accummulated within the community 19:39:46 ... we have to show that we're learning 19:40:06 noah: for some findings, there'll be a draft and the community will push back on it 19:40:15 ... that's always good, but it's hard to get that 19:44:08 noah: what should we do with this? 19:44:39 ht: I think the discussion we had about personal contact with WGs got some support, and we should do that 19:44:55 noah: I'd like some group of people to come up with a concrete proposal about how we take this forward 19:46:55 timbl: perhaps at TPAC, give a presentation on principles that have come up in the last 12 months 19:47:09 ... maybe new, maybe old 19:47:20 noah: we used to have 20 minutes every TPAC 19:47:31 ... that died when the standard presentations went from TPAC 19:47:40 ht: the standing slot was at the AC meeting 19:47:54 ... and they correctly decided to stop having the standard items 19:48:05 plinss: that sounds more like TAG status report 19:48:21 noah: in some cases that was quite technical 19:48:39 timbl: in early days we were playing catch up, writing up what people knew 19:48:52 ... nowadays the W3C is covering a lot more ground 19:49:14 ... I think the attitude of the TAG should be to ask for input of what people think 19:49:24 ... ask if people have arch issues that they want to flag 19:49:25 +1 19:49:30 +1 ! 19:49:42 noah: what at TPAC? 19:49:43 ask what the TAG can learn from what WGs are doing 19:49:50 timbl: use TPAC to feed them back 19:49:57 ... trying to highlight stuff that's new 19:50:59 ht: pilot with WGs but go out to CGs 19:51:08 noah: scaling to that number of people is difficult 19:51:22 jar: would it help to think of our role as a cross-bar 19:51:37 ... there's all this experience accummulating all over the place 19:51:45 noah: but that doesn't scale 19:51:55 jar: I know, that's what we're working on, how to do this economically 19:52:38 ... if the role of the TAG is phrased in a good appealing way, it invites engagement 19:53:21 ht: what about if instead of spending 15 minutes at the end of each TAG call looking at overdue actions, we spent that time looking at the mail coming in from our correspondents 19:53:28 noah: I do that before each meeting, there's been very little 19:53:45 ht: this is in the context of the architectural dudes 19:53:56 ... say we'll look at mail at each meeting 19:54:01 ... and we will get back to you 19:54:16 ... one of the responses is that there's another group talking about the same thing 19:54:28 noah: I get very nervous about logistics 19:54:35 ... about making promises we can't keep 19:54:43 ... how we relate this to our charter 19:55:01 ... our charter has a top-down feel, about documenting for the community principles of web architecture 19:55:17 ... where we can be collegial, fine, but we're not set up as a coordinating body 19:55:20 ht: yes we were 19:55:55 jar: we're having a trouble developing web architecture 19:56:07 ... we have to learn, and enlist the help of other people to learn what has to be said 19:56:15 noah: I don't know how to engage them much better 19:56:28 jar: telling them that the purpose of the TAG is to tell them what to do is not a good way to do it 19:56:41 Ashok: there's a fear that the TAG person is an oversight person 19:56:57 jar: another way to think of it is to say that webarch is a hypothesis and we're trying to test it 19:57:17 ... if the data shows the architecture is wrong, then we need to correct it 19:57:25 ... set expectations, say that's what we want to do 19:57:40 ... they feel there's a purpose to the interaction 19:57:58 noah: how would we do that? 19:58:31 plinss: we reach out to the groups to say that we're here to help 19:58:48 noah: will someone create a draft of an email to the chairs? 19:59:01 jar: one way to frame it is as a study, as a test of the hypothesis 19:59:08 ... we have to plan how we're going to gather the data 19:59:15 s/we're here to help/we need your help building web arch/ 19:59:23 ... someone needs to draft the study plan 19:59:30 noah: right, and doing that would be helpful 20:00:31 Ashok: the theory I have is that each of us would have to get fairly expert on four or five or eight WG specs 20:00:35 ... which is hard work 20:00:39 ht: you know, you don't 20:01:00 application directorate reviewer list at ietf 20:01:08 ... my experience on the AppsDR reviewer list 20:01:15 ... once a quarter I get an RFC to review 20:01:26 ... that's a lot of work, I get asked to review stuff involving XML 20:01:36 ... but everyone watches everything that goes by 20:01:47 ... I cherry-pick, skim these things 20:01:56 ... like the acct: example, it's not that hard 20:02:04 ... if your goal is not participate, but to keep an eye open 20:02:14 ... you don't miss everything 20:02:21 ... it doesn't take an enormous amount of time 20:02:33 jar: I'm suggesting something easier than a review 20:02:41 ... if we can list our five concerns, and only look for those things 20:03:07 noah: ht's talking about a model where we do the review, you're talking about where the WGs are doing the filtering 20:03:36 jenit: we need someone to do a draft study plan 20:03:50 noah: I'd like some people to be owners of all this discussion 20:04:15 ... to summarise it, come back with ideas, or help us assess these concerns 20:04:25 ... then when there's a specific proposal like the one that jar's made 20:04:36 ... then identify what can be done to help the TAG make the decision 20:04:48 ... I'm open to pursuing all that 20:05:09 ... I don't want to do all that, and drop everything aside from that 20:07:10 jenit: I am glad to do the next step in trying to gather what we've learned from the overall analysis of opportunities to improve TAG effectiveness 20:09:21 ACTION: Jeni, with help from Peter, to create big picture overview coming out of analysis of TAG effectiveness 20:09:21 Sorry, couldn't find user - Jeni, 20:09:36 ACTION: Jeni with help from Peter, to create big picture overview coming out of analysis of TAG effectiveness 20:09:36 Created ACTION-725 - With help from Peter, to create big picture overview coming out of analysis of TAG effectiveness [on Jeni Tennison - due 2012-06-21]. 20:10:47 jar: I'd be happy to pull out a list of architectural issues of things that we might be able to share with WGs 20:11:02 noah: this might be a big time sink 20:11:15 ... getting consensus might not be easy 20:11:36 ... it could cover versioning etc 20:11:59 jar: I'm talking about going through webarch ToC and trying to get a set of questions 20:12:04 noah: also include accepted Findings 20:12:17 ... more recent statement of what the TAG thinks we should be worrying about 20:12:35 jar: yes, I will 20:13:06 . ACTION jar to make a list of questions to which webarch and the findings suggest answers to 20:14:41 . ACTION jar to make a list of questions to which webarch and the findings suggest answers to, as input to possible 'study design' and/or communication to chairs etc. 20:17:31 noah: we will have a call next week, to at least talk about handing off publishing & linking to someone else 20:17:36 ACTION jar to make a list of questions to which webarch and the findings suggest answers to, as input to possible 'study design' and/or communication to chairs etc. 20:17:36 Created ACTION-726 - Make a list of questions to which webarch and the findings suggest answers to, as input to possible 'study design' and/or communication to chairs etc. [on Jonathan Rees - due 2012-06-21]. 20:17:46 ... and probably not have meetings the following two weeks 20:18:10 plinss: I cannot make July 12th 20:18:24 noah: please send summer schedules 20:18:32 ... no calls on 28th June, 5th July 20:18:40 ADJOURNED 20:19:08 minutes roll ups are: 20:19:21 Minutes rollup Tues: Henry, Wed: Jeni, Thurs: Peter 20:45:18 jar has joined #tagmem 20:50:38 - +1.617.715.aaaa 20:50:39 TAG_f2f()8:00AM has ended 20:50:39 Attendees were Yves, +1.617.715.aaaa 20:51:06 JeniT has joined #tagmem 20:54:08 jar has joined #tagmem 21:03:05 ht has joined #tagmem 21:28:18 Zakim has left #tagmem 23:20:08 JeniT has joined #tagmem