Draft minutes of the Thurs 14th June 2012 TAG F2F

Hello,

the draft minutes from Thursday 14th June 2012 TAG F2F meeting are available at:

 http://www.w3.org/2001/tag/2012/06/14-minutes

and reproduced in text below.

Regards,

Peter

----


[1]W3C

    [1] http://www.w3.org/

- DRAFT -

  This is version has not been approved as a true record of the
  TAG's meeting and there is some risk that individual TAG
  members have been misquoted. This transcript should typically
  not be quoted, except as necessary to arrange for correction
  and approval.

Technical Architecture Group Face to Face
14 Jun 2012

See also: IRC log
Attendees

Present
    Tim Berners-Lee, Jeni Tennison, Jonathan Rees, Ashok Malhotra, Henry Thompson, Peter Linss, Noah Mendelsohn, Philippe Le Hegaret (partial), Yves Lafon (partial, via phone)
Regrets
    Larry Masinter, Robin Berjon
Chair
    Noah Mendelsohn
Scribe
    Ashok Malhotra, Peter Linss, Jeni Tennison

Contents

    Topics
        ISSUE-57: URI Documentation Discovery
        proliferation of uri schemes
        TAG effectiveness part 2
    Summary of Action Items

<trackbot> Date: 14 June 2012

<scribe> scribe: Ashok
ISSUE-57: URI Documentation Discovery

jar: We will start with "parallel properties" proposal
... we have slides and Wiki page

JT: We would like approval to pursue this as the technical direction

<jar> Technical proposal details: http://www.w3.org/wiki/TagIssue57Proposal26

<jar> it's just a *proposal* for discussion, one among many possible

JT: semantic web / Web with import

<timbl> s/import/impact/ ?

JT: we care about how URIs are used with imported data
... agents act on info that you put on the web
... two use cases
... properties associated with documents and
... properties associate with things
... could be any kinds of things --- not documents
... they generally don't care about document propoerties
... they want to get more properties about the thing

<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

JT: issues about trust, provenance, age etc.

<timbl> s

JT: People uae URIs in XML/JSON as if they stand for things e.g. Wikipedia, etc
... I characterize this as naive URI usage
... also used in Microdata and RDFa
... also applies where URIs are used for properties
... easy to copy/paste from browser bar
... We want to distinguish these two uses of URIs
... we want people who use URis in this naive way to move to a more sophisticated use of URis
... URI identifies a document which corresponds to something
... another term for this is that the URI denotes the thing
... We are calling this parallel properties

<jar> Sandro wrote about this "parallel properties" approach in 2010: http://decentralyze.com/2010/11/10/simplified-rdf/

JT: Example (get URI for example page later)

The URIs denote things or properties of things

JT: Lay out the language "identifies","denotes", "describes"
... the context determines whether URI determines its interpretation
... We suggest interpretation depends on RDF properties

<ht> [wget http://schema.org/Person ... HTTP request sent, awaiting response... 200 OK ... Person' saved (18274 bytes) (text/html)]

JT: dc:creator subject and object are documents
... schema:nationality subject and object are things described by documents
... s/documents/documents - must 303 on object or use #URI/
... What do you get when you resolve a URI
... document is what you get when you resolve a URI
... Works acroess URI schemes and conneg variants
... Non-successful resolution implies there is no document -- 303 to think described by document
... single document may correspond to multiple things
... media type / prop specifies which one
... Non-existent documents can correspond to things
... For merging of data, it helps to have a single main topic
... Another example (get URI from Jeni)
... URI corresponds to the country
... schema properties indicate properties of that thing
... What we win
... people can publish when using appropriate media types/vocabularies
... consistent with RDF model and reasoning
... Helps people who have published in a naive way to publish in a sophisticated way
... Evolve to provide separate URIs for things
... Details need to be worked out
... RDF properties need to be defined
... what do we do with existing vocabularies which have not be defined in this way

Moving to questions of clarification

ht: That's "corresponds to" on the early slide, not "describes", yes? jt: yes

ht: schema:natinality subject and object are things "corresponded to" by documents

Tim: Asks about algorthm about parsing RDFa

tbl: Is there an algorithm for what you've described that's a modification of the RDFa algorithm

jt: No modification, the same algorithm

tbl: But that only gives you relations between documents, I want the relations between the things
... Is the squares+circles diagram in your example an RDF graph?

JT: No same algorithm

Tim: How do I change my code

jar: You don't need to change your code

Tim: Is there a function that returns a RDF graph given a serialization?

jar: No

NM: This assumes references exist in a media type context
... is this correct?
... is there a solution where that is not the case

JT: No changes to how the Web works today

NM: [about context in the story]

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

Discussion between Jeni and Tim re translation of JSON to RDF. Depends on application? Determined by media type?

JT: The media-type tells you how to interpret the URI
... just pure JSON does not

<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

JT: For example JSON-LD provides the context

timbl: Need to localize source of error

timbl: also for provenannce

<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

(Tim will provide URI to slides later)

Tim: RDF does not have to define what JSON means

<Zakim> charlie, you wanted to say disappointed in use of identifies"

HT: I would rather not assume there is a primary topic in the graph

jar: Some vocabulary to help people think more rigorously is a good thing
... you get consistency through model theory

<Zakim> dick, you wanted to say this ismaybe RDF-ER

Charlie has been uses "identifies" for a long time

Dick is worrying whether this is RDF E-R

jar: No, it is adding information and clarifying the relationships

Tim: So, tabulator has to do some up-front forward chaining on these properties
... 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

<Zakim> egbert, you wanted to say that the "correspondsTo " matches foaf:primaryTopic

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.

jar: yes

timbl: but then you end up with some extra gubbins in the graph that you don't care about it

jar: In order for tabulator to work, it need to know what subset of properties is the parallel ones.

noah: The subset has to be detectable in a discoverable way (by machine)

jar: yes

<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,

<timbl> als when I ask why the system beleives s' pp' o', I will get ":inference" rather than "document d".

jar: Do I have general agreement on my diagram with boxes {URI, protocol behavior, generic resource, RDF graph, topic}?...

jt: Let's talk about that later

<Zakim> noahm, you wanted to ask what this does for references not in a media-typed context

jar: I don't like calling it 'primary topic' for reasons I could go into, but we can defer that

jenit: no, egbert, corresponds to is not equivalent to primaryTopic

ht: Graph merging is easy if you know what the primary topic is

hst: +1 to avoiding "primary topic"

<ht> I suspect that "smshing" is what I think of as unification

NM: You said media type was important ... I came away with the feeling that may not be so important
... what do you JT think is the role of the media type

JT: Mapping from message to a knowledge represenation. If that has links to documents, can we make inferences and add some extra nodes
... how you interpret depends on media type of the message

NM: Is your solution only applicable if you have a media type

HT: The media type gives you information you can make some inferences

JT: If you don't have a media type you cannot make the inferences

Tim: This is monotonic ... it adds to RDF

<jar> The media type *might* say that strings that look like URIs are actually to be interpreted in a completely different way

JT: We need that story that applies to other than RDF

NM: Could you provide an "Idiots Guide" as to how to use it.

Jar: Agree

<Zakim> noah2, you wanted to make a concrete proposal on documenting this

jar: We will need two documents. A straightforward HOWTO, and then a (relatively) rigorous justification

JT: There is a simple way to explain this and then a more a rigorous way

AM: Do we need a vocabulary/ontology? Do we need to get agreement on this

JT: We getting to the procedural part

jt: How we deal with rdf:type depends on default rule, etc... need to dive into technical details, maybe defer

NM: We have a proposal for direction. Who thinks this is promising? Should we pursue this solution?

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

Tim: This is a sweet spot. It mitigates issues one usecase has.

<jar> http://www.w3.org/wiki/HTTPURIUseCaseMatrix

Tim: perhaps 209 could be combined with this

timbl: Pursuing this means going through all of the use cases and saying what to do in each case

noah: Tim's response to pursuing parallel properties seems roughly positive

jar: Larry said it was good because it works for Linked Data and is protocol agnostic

NM: Next steps?

<jar> lm's requirements: works for community, works for protocols

<jar> (IIRC)

jar: projects document showing next steps

4 steps

- Report back to people who submitted change proposals

- Document presenting "how to guide"

- Document with careful semantics

- Spin up a CG

scribe: CG would start with these documents and run with them

Tim: To solve problem this way -- parallel properties
... need to say this is not punning
... Do parallel properties happen on subject and object

jar: Needs to be decided. We have a few design options

jar: are there any other things we need to do?

noah: this looks right, but we have to do it right to smooth the way
... if we just drop it on people then they might unnecessarily be concerned
... should we gradually socialise this?

jar, jenit: yes, we should, especially with potential CG members

noah: then we can see how that goes, and determine what to do from there

jenit: we need to write up an "it" to socialise people with, and the "it" is different for different people

timbl: there's updating a bunch of how to do linked data documents

jar: yes, particularly the 'standard hash URI pattern'
... also the 200 with parallel properties pattern

ht: we need to look more carefully at what it'll look like when people adopt this and there are hash URIs around
... we haven't looked at that enough
... looking at how people who always use hash URIs interoperate with those that use parallel properties and so on
... this needs to go in a primer

timbl: in a primer, you say use hash URIs and turtle

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?
... people who follow Tim's directions need to interoperate with those who don't
... perhaps that's part of the how to

timbl: there's a big warning that you shouldn't use schema.org<http://schema.org> properties with proper RDF
... you could add an option to COOM (?) to strip out the original properties

jar: ideally a validator would be an integral part of the CG process

jenit: we need to get the community engaged in doing the backup work

timbl: when you create a quad store in Tabulator, you specify whether its a dumb store or one that does reasoning
... maybe this smushing stuff is done in the latter level

<timbl> maybe we need another level, or maybe the pp stuff is done whenever smishing on FP and IFP is done.

jenit: do we draft something, gradually expose those to targetted people to?

ht: we should be up front that we're preparing documents to hand off to the CG

jar: we thought the TAG should stay involved in this, it's not a hand off

<timbl> yes

noah: the TAG continues to have open issues in this area, and we are involved
... 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

jar: there's a good chance this will run into weeds if we just leave it to others

noah: the TAG has members with expertise and interest, we've spent energy on it
... I don't want to make an in-advance commitment of TAG resources to it as such

jar: we have to say whether it's hand-off or delegation

noah: the TAG plays a role in every group

timbl: should the CG report back to us?

jar: we're concerned with architecture in constituencies who won't be involved in the CG

jenit: there's the RDF bits of the proposal, and the wider architectural bits

noah: the TAG expects to be involved in coordinating liaison with those concerned with wider issues, such as protocols

jar: there's the broader interoperability question, from protocols to OWL
... and there's how that gets realised in RDF, which is the responsibility of the CG
... I think only people from the linked data community will join the CG

noah: what should we be saying to them?

jar: we should bring the wider architectural definition to Rec

noah: so there would be investment in that bit of work

jar: I don't think that would need to be an RDF document

jenit: it's a Rec that substitutes for the httpRange-14 decision

jar: yes, something that supersedes httpRange-14 and its question, which in general terms explains how HTTP and OWL interoperate
... and URI meaning or something
... and the second one is presenting RDF model theory as it fits with that

<jar> Here is the file I projected during the preceding discussion: http://www.w3.org/2001/tag/2012/06/issue-57-notes.txt

schema.org<http://schema.org> example from slides this morning http://www.w3.org/wiki/WebSchemas/ExternalEnumerations

<plinss> scribenick: plinss
proliferation of uri schemes

NM: there have been a number of proposals from a number of groups
... there's a document coming from the ietf making it easier to invent schemes

<jar> http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg-04

<noah> ACTION-694?

<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

<trackbot> http://www.w3.org/2001/tag/group/track/actions/694

<noah> http://www.w3.org/TR/webarch/#URI-scheme

<plh> web+ scheme prefix

<noah> From Webarch:

<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

<plh> http+aes

NM: there's a direction in web arch that schemes are expensive and should be avoided

PLH: aes in not in html space, it was a proposal from Hixie and didn't get much traction

<scribe> scribenick: noah

PLH: http+aes was a proposal from Ian Hickson. My perception is that it didn't get traction.

<jar> http://datatracker.ietf.org/doc/draft-farrell-decade-ni/

<noah> Peter grumbles about auto-correct

<ht> 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

<ht> registration of new schemes is harmful. New schemes should have

<ht> utility to the Internet community beyond that available with already registered schemes. The registration document SHOULD discuss the

<ht> utility of the scheme being registered.

NM: here's a counter-example of no-one referencing our documents

PLH: http+aes is not in the html wg space

<plh> web+ scheme prefix

PLH: this is a attempt to simplify web intent
... it's a way for a web site to declare they have the means for example to edit an image
... it's a way for web application to declare they can perform certain kinds of actions

JT: an example would be sharing something on twitter
... you could have a single share button and your client knows which networks to share on

<plh> Web Intents

JT: because you've visited a page (e.g. twitter) that has the web intent and says it can "do the share"

NM: which one has the web+

JT: I don't know

PLH: web+ was an attempt to try to harmonize registerProtocolHandler

<plh> HTML5 6.5 System state and capabilites

NM: so you are registering a JS handler on your page?

JT: this is different from web intents but solves the same kind of issue

NM: so if gmail wanats to register as a handler for mailto: which page has this call?

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
... web+ is not a scheme, it'a prefix one can append on top

HT: where would web+ uris originate from?

TBL: they originate in something that wants to play music for example

HT: that's handled by registering content handlers not scheme handlers

<scribe> scribenick: 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)

<jar> I don't see why not to use data:mediatypewithregisteredhandler,parameters

HT - questions where web+ comes from and how it's used

<plh> http://www.w3.org/TR/html5/iana.html#web-scheme-prefix

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:

NM: schemes must be whitelisted or web+ to be registered as handlers

AM: what's behind this?

PLH: that's why I started with web intent, more apps will be on the web rather than a desktop app

discussion of data: url and content handlers

<jar> data: seems a good alternative to web+ (doesn't help with the whitelisted schemes of course)

TBL: if web apps are supposed to be first class processors, can a web app supply an intent?
... suppose you want to had one tab provide a bunch of services, it could open a local web server or...

PLH: there are the web+ things and the web intents things to do that

discussion about running services in a local browser

TBL: is it easy to provide a web intent in a web app?

discussion about handling web intent locally vs remote server

JT: how recently has the been discussion about web+? what's is status?

PLH: it's actively being worked in in the HTML wg
... there's an issue about coordination with IETF

YL: there's a discussion about web+ on the apps wg at IETF

JT: what about coordination with web apps and web intent

PLH: I don't know about that

<plh> Issue 189

<Zakim> noah, you wanted to ask whether we should look at other schemes like enc; acct: ni:

NM: we've heard about other schemes, do we want to look at them?

<noah> I forwarded: http://lists.w3.org/Archives/Public/www-tag/2012Jun/0062.html

<noah> about enc:

<plh> Change proposal: Don't assign a special meaning to the prefix "web+"

<plh> Disambiguate the web+ prefix definition from IANA registrations

JAR: this is the same as ni:

<plh>

NM, TBL: ni: only specifies the hash for lookup

<JeniT> "making the case for acct:" http://hueniverse.com/2009/08/making-the-case-for-a-new-acct-uri-scheme/

NM: the IETF mailing list has had a lot about the acct: scheme

<noah> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05947.html

NM: acct: relates to web finger

<noah> acct: proposal in Webfinger draft: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-02#section-5

NM: this is a proposal that says http: uris aren't a convenient way to refer to people
... looks like an email address but isn't one

HT: this is designed to only be used in web finger (now web discovery), not in href's

<scribe> scribenick: JeniT

noah: why wouldn't I put an acct: URI in an href?

ht: acct: has no semantics outside webfinger requests
... the proposal is for things that only appear in webfinger exchanges
... they're not addressing what happens if they escape into the wild

noah: then why use URIs?

ht: because everything else is URIs

timbl: they used to use email addresses

ht: they dropped that a few months ago

jar: not all accounts provide mailto addresses
... for example, facebook

timbl: instead of mailto: they use acct:, so you don't imply there's an email address

ht: the two specs being merged are webfinger and simple web discovery
... Paul Jones is the lead editor of both, and the merger is probably going to be called simple web discovery
... because it's trying to be more generic than being about people, which 'finger' was about
... the merged spec is about everything
... for example you can make a request about an HTTP URI

jar: isn't this what well-known was about?

timbl: we should read this in more detail
... the usage case for WebFinger was when you find an acct: or mailto: URL, the system will get an HTTP URL back

ht: that's the second step, yes

timbl: if the first HTTP URI gives you back RDF, then you're set

NM: I'd like guidance from the group if the TAG should engage here or look at our general advice

JAR: I think this is web architecture, we should at least survey the extensibility points
... we should look at the problems first, then the solutions

AM: many of these schemes are about metadata discovery

JAR: people are just looking for how to solve a problem and not worrying about architecture

NM: I need to know how to move forward on this

JAR: I want someone to summarize this on www-tag

HT: I can do that, but not in the next 4 weeks

<noah> . ACTION: Henry to investigate possible TAG efforts on URI scheme proliferation and extension points

<noah> ACTION: Henry to investigate possible TAG efforts on URI scheme proliferation and extension points - Due 2012-08-01 [recorded in http://www.w3.org/2012/06/14-tagmem-minutes.html#action01]

<trackbot> Created ACTION-724 - investigate possible TAG efforts on URI scheme proliferation and extension points [on Henry Thompson - due 2012-08-01].

NM: let's wrap this

<br duration='20min'>

</br>
TAG effectiveness part 2

<scribe> scribenick: JeniT

noah: is there anything people particularly want to say?

PL: I'll talk to people at CSS F2F and similar meetings. They ask "what's the TAG"?
... They don't know or care.

JAR: Do you know if they'd care if they did know?

PL: Not sure.
... There is a part of the W3C community that would welcome help. Their perception is TAG is off doing that "academic semweb stuff"

TBL: Ironic, exactly what we're not doing/

timbl: maybe we should approach WGs and ask them if they have architectural issues in their area

noah: we can sometimes go and shed a light on an architectural area in a WG, and that's welcomed
... sometimes we try to stop WGs from doing things that have long-term negative impacts
... if we go "here we are" many groups will say "are they gone yet?"

timbl: I was suggesting that we go and ask them what architectural patterns they have found, and pull them together

noah: do you think they would be happy about having their primary work interrupted?

timbl: I think it will vary by group
... suppose we use the chairs list?
... ask someone to nominate an architecture dude within a group
... someone who could answer the question, who we could talk to

ht: having been in the XML Core WG as well as the TAG has been a real help
... a lot of WGs will just be silent
... a few will say go away
... and some will say, here's someone who will do it

noah: what if they're cheerful volunteers, who will take up our time?
... this has worked best when TAG members read WG specs in detail
... the risk is that the person understands their specs, but doesn't know about architecture

plinss: if they send someone who doesn't get webarch, we should take that as a educational opportunity
... it would help us disseminate the TAG's message

noah: if we get a lot of people then we're in trouble
... if I have 20 people calling me, it takes me a long time

plinss: I don't mean that you should be doing all this

timbl: could we have WGs allocated to TAG members?

ht: there are a lot of them

jar: what about a list of the problems to which an architecture would be a solution
... like registry design
... instead of coming up with an answer, maybe we list a bunch of the problems
... ask them if they have one of these architectural problems, and then say we want to talk to them

noah: sounds like something we can engage the WG chairs with
... I'm not sure we could characterise them

jar: I think we only talk about extensibility points and registry design

<jar> I asked whether we talked about anything else

noah: maybe we can craft a message to the chairs, to say that they should be watching for these things
... perhaps part of the Rec approval process is that they check off against that list

jar: I've been thinking about this for a long time
... there's a big distance between TAG and WGs
... if the TAG had unlimited manpower, we'd review every spec through the process
... as early as we could
... but that's impossible
... so is there a sweet spot?
... if we say that there are particular things we'd review for
... the WGs won't bring it to us, and they might not recognise that the problem is an architectural issue

noah: a lot of the filtering has to happen outside the TAG

jar: we might be able to ask if drafts create new namespaces, let us know

noah: perhaps this relates to improving education outreach
... we'll tell them they should be thinking about X, and they might not understand what that is
... if we put out more material to educate them, maybe it will help them recognise arch issues

jar: if we write something people want to read, it has to derive from the experience that's being accummulated within the community
... we have to show that we're learning

noah: for some findings, there'll be a draft and the community will push back on it
... that's always good, but it's hard to get that
... what should we do with this?

ht: I think the discussion we had about personal contact with WGs got some support, and we should do that

noah: I'd like some group of people to come up with a concrete proposal about how we take this forward

timbl: perhaps at TPAC, give a presentation on principles that have come up in the last 12 months
... maybe new, maybe old

noah: we used to have 20 minutes every TPAC
... that died when the standard presentations went from TPAC

ht: the standing slot was at the AC meeting
... and they correctly decided to stop having the standard items

plinss: that sounds more like TAG status report

noah: in some cases that was quite technical

timbl: in early days we were playing catch up, writing up what people knew
... nowadays the W3C is covering a lot more ground
... I think the attitude of the TAG should be to ask for input of what people think
... ask if people have arch issues that they want to flag

<jar> +1

+1 !

noah: what at TPAC?

<jar> ask what the TAG can learn from what WGs are doing

timbl: use TPAC to feed them back
... trying to highlight stuff that's new

ht: pilot with WGs but go out to CGs

noah: scaling to that number of people is difficult

jar: would it help to think of our role as a cross-bar
... there's all this experience accummulating all over the place

noah: but that doesn't scale

jar: I know, that's what we're working on, how to do this economically
... if the role of the TAG is phrased in a good appealing way, it invites engagement

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

noah: I do that before each meeting, there's been very little

ht: this is in the context of the architectural dudes
... say we'll look at mail at each meeting
... and we will get back to you
... one of the responses is that there's another group talking about the same thing

noah: I get very nervous about logistics
... about making promises we can't keep
... how we relate this to our charter
... our charter has a top-down feel, about documenting for the community principles of web architecture
... where we can be collegial, fine, but we're not set up as a coordinating body

ht: yes we were

jar: we're having a trouble developing web architecture
... we have to learn, and enlist the help of other people to learn what has to be said

noah: I don't know how to engage them much better

jar: telling them that the purpose of the TAG is to tell them what to do is not a good way to do it

Ashok: there's a fear that the TAG person is an oversight person

jar: another way to think of it is to say that webarch is a hypothesis and we're trying to test it
... if the data shows the architecture is wrong, then we need to correct it
... set expectations, say that's what we want to do
... they feel there's a purpose to the interaction

noah: how would we do that?

plinss: we reach out to the groups to say that we need your help building web arch

noah: will someone create a draft of an email to the chairs?

jar: one way to frame it is as a study, as a test of the hypothesis
... we have to plan how we're going to gather the data
... someone needs to draft the study plan

noah: right, and doing that would be helpful

Ashok: the theory I have is that each of us would have to get fairly expert on four or five or eight WG specs
... which is hard work

ht: you know, you don't

<jar> application directorate reviewer list at ietf

ht: my experience on the AppsDR reviewer list
... once a quarter I get an RFC to review
... that's a lot of work, I get asked to review stuff involving XML
... but everyone watches everything that goes by
... I cherry-pick, skim these things
... like the acct: example, it's not that hard
... if your goal is not participate, but to keep an eye open
... you don't miss everything
... it doesn't take an enormous amount of time

jar: I'm suggesting something easier than a review
... if we can list our five concerns, and only look for those things

noah: ht's talking about a model where we do the review, you're talking about where the WGs are doing the filtering

jenit: we need someone to do a draft study plan

noah: I'd like some people to be owners of all this discussion
... to summarise it, come back with ideas, or help us assess these concerns
... then when there's a specific proposal like the one that jar's made
... then identify what can be done to help the TAG make the decision
... I'm open to pursuing all that
... I don't want to do all that, and drop everything aside from that

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

<plinss> scribenick: JeniT

<scribe> ACTION: Jeni, with help from Peter, to create big picture overview coming out of analysis of TAG effectiveness [recorded in http://www.w3.org/2012/06/14-tagmem-minutes.html#action02]

<trackbot> Sorry, couldn't find user - Jeni,

<scribe> ACTION: Jeni with help from Peter, to create big picture overview coming out of analysis of TAG effectiveness [recorded in http://www.w3.org/2012/06/14-tagmem-minutes.html#action03]

<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].

jar: I'd be happy to pull out a list of architectural issues of things that we might be able to share with WGs

noah: this might be a big time sink
... getting consensus might not be easy
... it could cover versioning etc

jar: I'm talking about going through webarch ToC and trying to get a set of questions

noah: also include accepted Findings
... more recent statement of what the TAG thinks we should be worrying about

jar: yes, I will

<jar> . ACTION jar to make a list of questions to which webarch and the findings suggest answers to

<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.

noah: we will have a call next week, to at least talk about handing off publishing & linking to someone else

<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.

<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].

noah: and probably not have meetings the following two weeks

plinss: I cannot make July 12th

noah: please send summer schedules
... no calls on 28th June, 5th July

ADJOURNED

minutes roll ups are:

<noah> Minutes rollup Tues: Henry, Wed: Jeni, Thurs: Peter
Summary of Action Items
[NEW] ACTION: Henry to investigate possible TAG efforts on URI scheme proliferation and extension points - Due 2012-08-01 [recorded in http://www.w3.org/2012/06/14-tagmem-minutes.html#action01]
[NEW] ACTION: Jeni with help from Peter, to create big picture overview coming out of analysis of TAG effectiveness [recorded in http://www.w3.org/2012/06/14-tagmem-minutes.html#action03]
[NEW] ACTION: Jeni, with help from Peter, to create big picture overview coming out of analysis of TAG effectiveness [recorded in http://www.w3.org/2012/06/14-tagmem-minutes.html#action02]

[End of minutes]

Received on Wednesday, 27 June 2012 20:03:07 UTC