IRC log of tagmem on 2012-06-14

Timestamps are in UTC.

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