See also: IRC log
<trackbot> Date: 08 October 2012
LM: There are 2 dated links
<Larry> http://www.w3.org/2001/tag/doc/governanceFramework-2012-10-08.html
<Larry> http://www.w3.org/2001/tag/doc/governanceFramework-2012-07-19.html
LM: The earlier version was based on work I had done with some other folks. Publishing and Linking was framed as an example of how regulation interacts with architecture, but set out the bigger picture.
... I got feedback that the section on governance areas said either too little or too much. It wasn't long enough to really define "Privacy" and "Copyright", but said enough to get into trouble. So I cut them them way down, so now it's a short document. The intro is similar to the P&L document (borrowed from here to there). We added an Audience section. Why are we doing this? We hope that technical understanding can help legislators make better laws. Details are now just a bulleted list
... Section 4.2 talks about where policies and technology interacts.
NM: 2 questions. What is the success criteria? Is it almost complete or just a table of contents of items that need to be fleshed out?
LM: Final document should not be more than 50% larger
... The goal is to encourage W3C to take up other areas where there is conflict between technology and policy.
... There is ongoing discussion about ITU and other bodies re. Internet governance ... connectivity, net neutrality, etc.
... But the governance issues are lot broader e.g. cyberbullying.
<ht> Wrt conflict between regulations, compare the two things linked from the following page: http://www.ed.ac.uk/schools-departments/information-services/about/policies-and-regulations/statutory-notices
Ashok: Use of Social Media to mobilize opinion
NM: It would be good if the introduction answerred my questions
<noah> NM: Two questions: 1) what are the success criteria for the document? 2) is it 75% complete as it stands, or is this going to include comprehensive discussion in each area?
JeniT: This would be a good subject to have this as a page in the TAG space that we could link future work from.
LM: 1) get people thinking about the issues 2) it's maybe 75% of the size I'd expect -- it's an intro to get people thinking.
... Not sure if this work completely fits in with what the TAG does.
<noah> NM: I think the document needs to more explicitly state its goals
LM: it's a good way to broaden the discussion started by the P&L document
<noah> LM: OK, good point. Make sure it's in the minutes.
<noah> NM: Done
<Larry> not sure it fits entirely within the TAG's remit
HT: Would be good to have Daniel Dardellier come talk to us about govenance
<Larry> the word "governance" is used here with a much broader meaning than is typical in the current Internet community discussions
HT: his perspective would be useful
<ht> ITU holding 1st ever "World Conference on International Telecommunications" (WCIT): http://www.itu.int/en/wcit-12/Pages/newsroom.aspx
<ht> December, 2012
LM: We could go thru the doc section by section
NM: I not convinced whether a document that just whets your appetite is a good idea.
... I'm willing to think about this
<Larry> missing acknowledgement
LM: I responded to comments by contracting section 4
<ht> http://www.itu.int/en/wcit-12/Documents/draft-future-itrs-public.pdf
HT: I put a link to the ITU meeting in Dubai ... the above is their base document
LM: I have not addressed comment on use of word "Governance" . We are talking about a much broader set of issues
... I happy with the intro ... it has been carefully reviewed
Section 2 spells out the goals of the document
Section 3 talks abput Governance requirements constrain Architecture ... some examples would help here
NM: Section 4 is too brief
JeniT: Can we add pointers to other sources here?
NM: Need more detail in Section 4
Ashok: I want to see examples of where policy influences architecture and vice versa
LM: Started to think about jurisdictional differences in policy ... how does that influence international businesses
... e.g. authentication, what material is illegal etc.
... when we move into a position where your action on a device can have global effects
<ht> Wrt ITU again, and their proposed Regulation: http://www.itu.int/en/wcit-12/Documents/draft-future-itrs-public.pdf, see e.g. the first item on Page 29, which explicitly puts Internet traffic within their scope
LM: We need guidelines for legal dept and project managers ... responibilities are distributed
NM: It's a valuable area but what are we contributing
LM: When i showed it to people I got feedback that it was useful and we should keep working on it
... Needed to be complete ... missing, for example, security.
Tim: There has been pushback from folks saying TAG does not do Policy
LM: This is a bridge between the technologists and the policy folks
NM: Maybe a different title
LM: In 4.2 we talk about other documents like the P&L we may want to work on
Tim: What about fairness, growth
... these are things governments worry about
... What are technical properties that enable fairness
LM: Something about no monopolies, open markets
... antitrust issues
NM: The P&L document is really about explaining technology for policy makers
LM: This is the inroductory framework and P&L is first volume
NM: What are the other pillars that sit next to P&L
LM: We could publish as a note and presenting it to the AC
NM: Should we do this with the AB?
Tim: Lot of interesting work on the bulleted points ... these need to be mentioned.
HT: We should focus on section 3. That's our business
Tim: I see the world as being a set of protocols and each protocol is a mixture of technical and social
... linking to stuff involves a social aspects
... breaks when people link on how to make a bomb. So we need constraints both social and technical.
... Historically geeks and lawyers have danced around each other ...
... not formed by pieces coming together
NM: The Web and facebook have both technical and social aspects
... We need to fill the gaps between technology and society
<Larry> see http://dx.doi.org/10.1080/13691180903473814 (The Interpenetration of Technical and Legal Decision-making for the Internet")
Tim: Re. email the original thinking was that this was a research network and should be used only for research
... when the use policy was relaxed it turned out that some issues such as spam were not addressed.
LM: People seem to be uncertain as to where to go with this
AM: Can we mention the relevant technical issues under each bullet in section 4
NM: We need success criteria to decide whether to go forward with this document
<Larry> What would have to happen to this document before you would be happy to see the TAG work on it?
Tim: Your list here is sort of like the IETF saying you need a Security Considerations section in each RFC
... with P&L we had clear example of misunderstandings re. Linking and Embedding
NM: Do you have what you need to move ahead?
LM: I'd like a poll on whether we should go forward with this document.
HT: I'm very concerned about redoing work that has been done elsewhere at greater length
... s/is/in/
... section 3 in scope and should be grounded in existing policy studies, start with discussion with Danny Wietzner
PL: It's an interesting document ... agree with Henry ... maybe the W3C should concerned with this rather than the TAG
YL: The TAG should stick to technical matters
... works on how architecture of Web impacts policy and how policy impacts Web Architecture
JeniT: Section 3 really useful ... good summary of areas of concern
... explain technical concepts to policy makers
... need links to existing work
Tim: Prefer a view where the system is designed holistically. Privacy is a property of some systems ... provides invariants on which other systems depend
... Similarly, copyright, accessibily are properties of this system
... As a list of things to watch out for is reasonable
... I would not like future architecture to be done piecemeal
... useful as a checklist
... I'm worrying about doing architecture from this matrix ... for example accessibility be added on because some govt. wants it
... What the document is trying to say is not very well defined.
<timbl> Askok: What I would do is take the bullets and talk about tech areas which influence them.
<noah> AM: I have mentioned: I would take the bullets, and speak of technical areas that impact security, copyright, etc.
<timbl> ... and then find where others have talked bout these things.
<noah> AM: Difficult part is to find what others have already done
<timbl> ... As a very practical thing to go forward with this.
NM: I've expressed some concerns about the goals. Not sure we need a document that does not stand on it's own
... this is like an intro to other work we need to do
... I'm reserving judgement ... perhaps you could add some technical depth
LM: I have got some useful feedback ... need to think about how to go further ... perhaps a blog post.
NM: Not saying "we don't want to see this ever again"
LM: I will work further on the document.
Break for 20 minutes
HT: Background http://www.w3.org/wiki/TagIssue57Proposal27/Background
... This is a starting point for the perspective Jeni, Jonathan and I have taken
... it is a 20,000 foot level set
... if you think its wrong we need to worry
... Distributed extensibility begets incompatible extensions
... this is by design
... XML does not control the tags used. You can design the meaning of the tags you use
... XML has a mitigation i.e namespaces
LM: I need more context
HT: This is in aid to improving the situation re. HTTP Range-14 resolution
... We are building towards a proposal
... we have 3 documents, this document, the primer and a detailed proposal
... Rec track for primer and technical document
<Larry> "underspecification" is a value judgment, not specified as much as expected
HT: Sometimes, like in the case of RDF, extensions are incompatible ... usually this is not a problem
... problems arise when incompatible extensions are expected to interoperate
<Larry> disagree with 'require' in "Interoperability requires keeping track of which extension is intended." -- keeping track is one way, there are other ways
HT: Obvious way is to keep track of which use is expected
<Larry> yes, it is "one obvious way"
HT: Otherwise you will get incorrect conclusions
... Many ways to keep track of which extension is intended
... Proposal is to make distinctions via the immediate context
... we cannot get agreement on what the URIs mean ... but we can get
agreement on what sentences using URIs mean
... We will put the burden of identification on the meaning of properties
LM: Who has to agree on the meaning?
JeniT: The crucial thing is where the URI is used ... is it referring to the content or description of the content
... we are concerned whether an app using the URI does the right thing
<Larry> the core goal of "my statements mean what i think they mean" can't be accomplished with a universal understanding, "Everyone who can hear my sentence will think the sentence means the same thing"
<jar> there is no way to control what someone else understands in any situation
<jar> saying that agreeing on meaning of sentences instead of words is not an improvement, is a straw man
<jar> what another agent thinks something means is unmeasurable, undetectable, a private matter, not in the scope of any spec
<jar> specs only govern tests of conformance. whether an agent conforms to a given spec.
<jar> so, masinter, "my statements mean what i think they mean" cannot be a goal
<jar> at least not in a spec
<jar> sorry for the irc-only comments, i wanted to get them written down, don't let them interrupt conversation. i couldn't get in on voice.
<jar> will try to restrain myself
JeniT: The aim of this paper is why there is confusion, mostly they don't need to care about it and when they do what they should do about it
... not specific to RDF
... addresses people who are writing data and what they should care about
Jeni goes thru the document: http://www.w3.org/2001/tag/doc/uri-usage-primer-2012-10-03/
Tim: David Booth said that all we need to worry about is RDF ... in that RDf is creating the problem
<jar> that's not correct
<jar> the json case is interesting.
HT: If you write XML or JSON you always say what the URIs mean
<jar> if we can give advice on that one, then the rdf case will follow ... rdf is harder though, so start with json
JeniT: Section 3 introduces Landing Pages which are pages about something else
... they don't have to HTML. Maybe JSON or XML or RDF that describes what is it that they are talking about
... sometimes the properties get mixed up ... they could apply to the page or the content
... If the data is about a person then it's clear what the properties refer to
<jar> timbl: e.g. phone number and assistant's phone number
Section 4 describes Data Normalization
Section 5 says not always possible to normalize
HT: People don't always normalize
<Larry> http://www.iana.org/assignments/link-relations/link-relations.xml
<Larry> based on http://tools.ietf.org/html/rfc5988
<ht_home> TBL commenting on the 'implied properties' diagram
JeniT: 5.2 talks about when a Landing Page describes more than one thing
... 5.3 talks about why these distinctions are particularly important
... 5.4 is about how you find the documentation
... 6 is about recommendations about data producers and data consumers
... say what appliactions can do with URIs ... when they dereference what they can expect
<jar> something about appending to get URIs in various doc formats, XML, turtle, etc.
((Discussion of namespace URIs))
NM: namespace names can have a fragment in the name
HT: Using a string which is a relative URI is deprecated
JeniT: 6.1.1 talks a metaformats such as RDF and says they should document how the the URIs are interpreted
<jar> don't talk about identification please. identification is not testable
<jar> reference is not testable. please don't use the word
<jar> 'identification' and 'reference' have no place in normative language
<jar> similarly 'meaning'
<jar> as soon as these words are uttered, people start arguing.
NM: Henry said URI refers only to one thing but sometimes it refers to other things
<jar> just stop please.
NM: we shall discuss in detail in the main proposal document
<jar> please let's not get into REST
<jar> please let's just talk about JSON
HT: Please wait till we get to Proposal 27
<jar> please let's get consensus on JSON first. then we can figure out what to do about REST, identification, reference, REST, meaning, etc etc.
NM: Need to be rigorous about terminology
<jar> there is NO WAY TO BE RIGOROUS ABOUT IDENTIFICATION
<jar> Just don't talk about!
<jar> I am not going to speak up. I am on the queue. I want Jeni to finish
<ht_home> JAR is channeling Wittenstein
<timbl> Nothing, jar, is testable
<jar> timbl, I disagree with that.
<noah> No, I'm saying we can tell stories at different levels, and not use terminology that's unnecessarily ambiguous. I think I'd like to see a bit of terminology used consistently for just the REST bit of this: time varying sequence of representations, etc. We can on top of that have a set of terminology for the proposal 27 story (when used in the property (indirectly) identifies)
JeniT: 6.2 talks what conclusions you can draw if you are a consumer of the data
<jar> timbl, that is the same as saying there is no truth.
<Larry> everything is testable, it's just that most tests give inconclusive results
JeniT: 6.3 talks about Publishing data
<noah> btw: the JSON case IS a rest case. The JSON itself, and the typical URIs it references, are typically retrieved with GET
JeniT: section 6 needs more work
<ht_home> Noah, REST is not an agreed vocabulary, we don't want to depend on assuming it is
<jar> lm: asking about link relations
LM: What about Link Relations, what about XMP?
<jar> XMP (or the doc formats that use it) is underspecified because it doesn't answer this question.
<jar> yes
LM: Link Relations would be another usecase to discuss
<Zakim> jar, you wanted to In JSON, this has to do with the relation between the property value and the @id value? Or is @id just another property.
jar: The approach in this document is good ... it avoids trigger words that would cause us to rathole
... can we get consensus on the advice and then test against various usecases ... start with JSON
... RDF is complicated because it has entailment
... RDF would be the final test
<Larry> XMP uses rdf:about=""
<jar> So, talk about XMP first, put off RDF in general.
HT: We should not import terminology from REST. REST is not well specified and it would cause confusion
<jar> Let's go bottom up.
<jar> what you're saying doesn't even have agreed meaning
<Larry> just testing the document about other things I think about, it looks ok
NM: To me this implies that what a URI implies is where it is used
<jar> you're not even making a point
<jar> stop being deep
<jar> we're ONLY talking about how to write specs please
NM: REST gives same answer where the URI is used. I'm reluctant to lose that
JAR: Don't go there
NM: I think this is an important point
JAR: Identification does not occur in the document
<JeniT> /me jar, you're breaking up a little
<jar> If the document talks about 'identification' or a function from URIs to things that would be an error in the document
Tim: We are talking about something over which there has been a great deal of debate and people have been burnt
<jar> context is always important
<jar> as Larry keeps saying. I agree totally
Tim: They are saying it depends only on the property
NM: I want a function from a URI to something that is completely context independent
... losing that is very deep
<jar> that's impossible, Noah
<jar> and irrelevant
HT: We tried to do that and we failed ... others have tried and failed
JAR: People havee been trying to do that for 120 years and failed
HT: We set out to solve a smaller problem
<jar> webarch is wrong.
<jar> and not the subject of this exercise
HT: There are different constituencies that recognize the words differently
NM: I would like to see if we can reconcile with WebArch
<jar> "URIs identify" is patently false. Could be true (enough) in some cases. Empirically false for http: URIs
<JeniT> timbl: I want to use an analogy between classical and quantum mechanics
Tim: It's like classical mechanics and Quantum Mechanics
<jar> My procedural advice, to put off the hard questions until the easier ones are answered, is being totally ignored
<ht_home> TimBL channeling Pat Hayes !
<jar> we should all channel Pat Hayes
Tim: Pl. wait until they get to the end of the document
<JeniT> <lunch>
<ht_home> Break for lunch
Lunch break till 1:20
<JeniT> discussing http://www.w3.org/wiki/TagIssue57Proposal27
ht: this is an attempt to work out detailed RDF semantics for parallel properties
... the proposal is algebraic and succinct
... this is the hardest part of the problem ...
... begining with a simple case initially
<jar> is everyone on board with this presentation or are some people going to tune out?
<jar> little point in going through this if someone is going to disagree with premises at the end
ht: going to focus on disambiguation between landing page and the work
... This is the crucial problem.
<noah> From the proposal:
<noah> "Claim: We'll never agree on what the disputed URIs (the GET/200 ones) identify. "
<jar> context is still important for sentences, larry. I ack that
ht: we're just going to focus on what the sentences (triples) mean, without having to agree on the story
<jar> right
<noah> Just to record here what I said this morning: I want eventually >NOT< now, to make sure that we don't go too far in throwing out the fundamentally good advice in Web arch about use of URIs to (excuse the loaded term, but it's what Web Arch uses), "Identify" things.
ht: the way we're going to do this is to explore three distinct communities of practice, with respect to use of URIs as the subjects of RDF triples.
<noah> I don't think that means throwing out or even much changing proposal 27. I do think it means recommitting to a lot of the spirit of the good advice in Web arch, and about URIs (as, ahem, identifiers) remaining one of the three pillars of Web architecture
ht: now looking at the example scenario
<jar> larry, thanks for scribing. my task (later) is to convince you that i'm in complete agreement with you on everything you've said so far
HT: ((explains Interpretation 1, Interpretation 2, "Neutral" Interpretation))
... OMF (Our Mutual Friend) might be an 'information resource' or maybe not, doesn't matter
<jar> the "landing page" could be either the rep or the resource.. doesn't matter. move along.
<jar> red herring
ht: but LP can be thought of, in REST turns, as a resource
... two functions, 'ptopic' and 'lp'
<noah> should say lp maps from thing described (possibly a person) to landing page
noah: if the LP was about a person, then OMF would be a person, and ptopic is a function from document to a person
((agreement))
<jar> P maps what's identified to its author.
noah: "URI interpreted as" confuses me
<jar> what 'P' identifies maps something (e.g. something that's identified by another URI) to its author
ht: P is a URI that is uncontested as a property for indicating authorship
noah/timbl: "interpreted" is a term of art? ((discussion))
ashok: Are 'has creator' and 'created by' special, or could i use other words?
ht: any property that is ambiguous would work as part of the setup
((discussion of why moving from Moby Dick to Dickens))
ht: given all of this, can we define properties where members of all three camps can say "landing page by Tomlinson, book by Dickens"
... ((reviewing chart))
... U vs. Interpretation 1, 2, 3; P is creator property
... Now we get to the magic
... "we need a Q, such that U Q T means LP is by Tomlinson, and an R, such that U R D means OMF is by Dickens
... working backwards, Q and R are different functions for Interpretation 1, 2, and 3
<jar> yes
noah: ((question about domain of Q and R))
<jar> noah is correct, the might have disagreements over truth of sentences involving domains and ranges (if they don't pull this trick again when they talk about domains and ranges)
ht: we have a URI, we do a GET, we get a page whose author ...
tbl: Q and R are different URIs; the future of data on the web relies on those two not getting overlap
<jar> I would say, the future of RDF interoperability, in the absence of agreement on "identification" (which has not been forthcoming)
<jar> not "the future of data on the web" since we have seen that the JSON case doesn't rely on "identification"
<jar> if the web depended on "identification" the present would be in awful shape
ht: ((reviewing diagrams))
ht: we need the TAG to define two predicates, M and N, which relate properties that apply respectively to landing pages and things denoted by landing pages to undisputed properties, then I document Q bearing the M relation to P and R bearing the N relation to P.
noah: are you looking for people to understand today, or to just agree if this is the right direction?
noah: which is it?
jar: depends on what you mean by 'evaluate'
ht: Jar, do we have a name for URIs whose interpretation varies by community
jar: no.
... not really needed in RDF semantics
ht: this then leads to a processing model
noah: P is "dc:creator"
jar: "you might use them with hash URIs, but we decided to defer that"
ht: in this paper "disputed URI" is a hashless retrieval-enabled URI, for which a GET returns 200
tbl: ... Q and R don't have to be hashless
<jar> you can think of M and N as cancellation operators. they cancel out the disagreements
tbl: when you define Q
ht: anyone who wants to publish interoperable properties will define them this way
... M and N are fixed URIs, they serve the documentation requirement
... it's M and N that allow interoperability by appearing in definitions
tbl: do you mean inverse?
noah: they take care of the fact that some communities do indirection one place and not the other
tbl: you're saying P is undisputed?
<jar> we're positing that.
ht: dc:creator means the author of an authorable thing is ...
tbl: they didn't say whether it should be like U or like Q
ht: if you don't do this, you have to assume they were caught in an infinite regress
Jeni: it would be better if you didn't use dc:creator
ht: p never indirects, it's always direct
... creator is always direct
noah: dc:creator are ok in this example
ht: it's crucial when we get to the tabulator, which is what any application needs to do, when you find any property declared by M to map to some direct property, you should assume there's a real landing page out there, and in the wild what you're going to find is Q
noah: users have to say Q
<jar> dc:creator might be used with hash URIs. no problem with that
ht: users only have to say Q if they are making
assertions about disputed URIs.
... That's why we're not done yet
... We would like it to be the case people can use Q and R with URIs that return 303 ...
noah: they can't use dc:creator
tbl: in the schema.org world
noah: that's what i guess and i was mixing it with branding.
... dc:creator is what people expect to use;
asking that they learn another property may be an impediment to adoption
jar: we tried to get consensus on that and failed ((the idea that hashless http: URIs refer to the documents whose 'representations' you 'get'))
noah: think about it ... we have for 10 years
noah: in the future people will invent Q's and R's
tbl: dc:creator was used since [a long time ago]
<jar> it's been used without transparency - without any spec for what it means
<jar> it's only a problem when you use dc:creator with a subject written as a disputed URI. all other cases (#, 303) are fine
tbl: Facebook created OGP ontology, and started to stick something in their metadata and schema.org did something
tbl: ... we can keep going. if people get into namespaces, then instead of kicking
... dc:creator applies to the page. if you want to introduce something about the subject of the thing the page is about, then that would remove the syntax
<jar> timbl is considering other parts of the context where the distinction could be drawn?
noah: their story gets better over time, in principle
ht: If i'm building an ontology in a greenfield, there
are two possible authoring approached, per Interp 1 and 2
... I write some RDF about what i care about, say, Italian opera
... i'm going to define a vocabulary that I will use to identify the
composer and singers I know
... i'll use new URIs for them that will be in my namespace
... I want to encode what I write so everyone can use it, so I'll
follow Jeni's advice and use the parallel property approach
... Whenever i want to assert something about a composer, say, I'll
use the parallel properties, as it were Q and R.
... But my information about my properties will be asserted
about the direct properties that those map to, about
P as it were.
noah: is M one level or to the bottom
<Stuart> FWIW: I think we are talking about the identification of 'things' and 'descriptions of things'. The proposal on the table seems to be about creating two variants of a property, say 'creator' which we call 'topic(creator)' for speaking of a 'thing' and 'meta(creator)' for speaking about a 'description of a thing'.
noah: if i have a landing page that talks about another page ...
jar: ... the very last on the page
ht: The remaining problem is: can we use Q and R across
the board, since that will ease adoption
... As it stands, we're still left with possible issues with 303 and hash URIs
... For now we can't get away from saying you should use the good
old-fashioned direct properties with # and 303.
... The rest of the document is about trying to fix this. Can we get
tick boxes in all the rows
... I.e. so that the right thing happens if you use one of these
so-called parallel properties (P or Q) with a # or 303
<Stuart> I guess (again FWIW) I would prefer a world in which we can speak clearly about a subject ('thing' or 'description of thing') with 'simple' propeties - but that flies in the face of the premise of the discussion (that <U> is disputed).
<jar> The question at the end of the proposal27 page, is whether hash URIs interoperate with M- and N-properties.
ashok: if i have a hashless URI in my hand, how do I know if it is retrieval enabled?
noah: and is that time-invarient
noah: are all hashless URIs retrieval enabled?
ht: you can't tell if you'll get a 200 or a 303
jar: part of the continuation of this exercise.... i think larry's point that 303 and 200 shouldn't be treated separately that 303 and 200 shouldn't be treated separately is a good one, but now there is substantial 'legacy' use of 303 in RDF
noah: so our solution is more advice?
ht: the simple story I told above, if you ask what does it mean if someone uses a parallel property with a 303 URI, the answer is, as far as we've gotten, it doesn't give the right answer
ashok: would it help if you said all hashless URIs are disputed
jar: reiterating, for the TAG, Jeni's document is important
ht: So Jeni's doc't and Proposal 27 as we've just looked at them don't answer the procedural question. We asked for proposals, and set a process in place. Jeni's document doesn't meet the requirements for a proposal, does it?
jar: basically, it asserts agreeing what disputed URIs identify
none of the proposals address the real problem. The key issue is technical interoperability, which has priority over identificaiton.
ht: i'm not sure jeni's document as it stands encompases all that you said, some of it is in the background
jar: there's more work to be done.
ht: i had scrolled down as far as processing model for
identifying and working with parallel properties
... Why does this work for, say Tim, who's a member of community 1,
regardless of whether the original triples were written by
himself, or someone from community 2?
<jar> might want to look at http://www.w3.org/2001/tag/2012/09/issue57/U at some point...
ht: how does it work if a member of community 2 passes
something to someone in community 1?
It works because there are two places where the
interpretation is involved, and they effectively cancel each
other out.
tbl: Ian is identity, N is identity?
<jar> For timbl, M is identity. For Ian, N is identity.
<jar> Tim thinks Q = P
tbl: [Right,] for me, [M] is identity
... [Q M P]
jar: at [the mid] point you'll have different stories
<jar> _:1 will be the same for Tim and Ian
but for different reasons for the two
tbl: the problem is with the tabulator, it will pull in a landing page, and conclude that there is something
ht: it better have access this to the Q M P triple.
tbl: for some unnamed thing _1 for some unnamed thing P
<jar> ?p [will] be dc:creator
<jar> ?p will usually be named, doesn't matter. In the example it is
2 hr) ht: we haven't talked about F*. F* is the name of the thing you're composed with, it's either ID or landing page or primary_topic/subject_o). In your case, this is, F* is identity
<jar> To Tim, F* is the identity
<noah> Time check 10 mins
tbl: i know there is something ....
<JeniT> we use 'Tim' and 'Ian' as standins for perceived communities
ht: ian has to have written Q M P, with a concrete value for P
<jar> These deduction rules work for everyone
tbl: the problem is Ian will create R and document R
jar: this only works for interoperable content
<jar> (We should ack that Ian is a stand-in for a point of view. We are not referring to him personally)
jar: If time is limited, we need to talk about how to respond to the call for change proposals. It seems to me we still need to help people work out the technical details.
Noah: real problem getting enough community consensus
... To get a sense of the room, who feels that this is worth investing more
time in
... I need to look hard at the relationship with AWWW.
<jar> abstain
noah: first choice [6 in favor]
ashok: I want to think about it a bit
noah: it would be nice to come out of here with a direction
<jar> I want TAG agreement that the direct path to interoperability, that of agreeing on what these things identify, has failed. That failure is the entire motivation for this approach.
stuart: will this require me to change anything?
<jar> . RESOLUTION: The direct path to interoperability, that of agreeing on what hashless http: URIs things identify, has failed. Therefore the approach of Jeni's "URIs in Data" and proposal 27 should be pursued.
Jeni: 303 is OK
noah: if you were to come across shorthand properties ... not proven [scribe didn't catch this well]
<timbl> There is an interesting subclass of InformationResource which is a domain of principalTopic : Document which has a single principle topic.
<ht> HST's take on what JAR said was his proposed resolution of the RFP exercise is: "The outcome of our review of the responses to our call for change proposals is to underscore that no consensus exists or can be reached on a story about a global unambiguous interpretation of hashless URIs. Rather than continue to pursue such consensus, we will instead seek a technical solution to the resulting interoperability problems."
<jar> I think 303 is fine for RDF, but agree with reservations on whether it works for the architecture overall.
stuart: this will be hard ....
tbl: worry we're build more crud on top of crud
<jar> No, we're removing crud from existing crud.
timbl: it's better than that because ...
... a movement to outflank the whole issue ... talking about the subject of the thing to the thing itself
[scribe didn't catch this well]
<jar> HT's wording is consistent with, and better than, mine.
ht: because the net net is to say, trying to capture
JAR's position, that the outcome to our review was to
underscore that there is no agreement on what [hashless http:] URIs globally
and unambiguously identify, and we're going to stop trying to
get it
... instead we'll provide some technical advice for some interoperability problems
<jar> Amend: hashless http: URIs
ashok: when I'm starting, I have a URI, we have to ... XXX ... [scribe didn't catch this well]
<timbl> timbl: It is good to prepare also a way of making this unnecessary by allowing in HTML and maybe even turtle a very clear syntax for giving information about the principal topic of the document in the document, like a <subject> ... </subject> element within the <head> element, within which all metadata (links, etc) is taken to be about the subject of the page, not the page itself.
ht: all you have to do is faithfully implement in your
processors your community's understanding
... the crucial thing is that you don't need to know where things come
from, just trust that M and N in property metadata will let
you compensate. M and N are going to become concrete, then all you need to do is trust things with M's and N's.
ht: When i find hashless URIs I'm going to have to be careful. Following Ora Lassila's example, we need to collect and exploit provinence information. Then it will be easy for you to say
<timbl> We found people wouldn't mind their Ps and Qs and just hope they like M&Ns.
LM: A substantial part of the community is trying to push us toward operational defitions of URI/URL, etc.
... These things are recipes, grounded in <a @href>, somewhat modified in <img @src>. You don't need to try to read semantics into RFC 3986. You just agree a set of processing steps.
... It's a big chunk of the community, and they look to the TAG for leadership.
LM: I see that this is an important problem for a community, but am dismayed that it continues to take so much time. We had an agenda entry. I was hoping to get a plan for driving a stake into the heart of this. And now I think I see another plan for 6 months of work.
LM: I like the first part of the proposed resolution.
... I'll agree that the efforts to agree on interop of hashless URIs have failed. OK.
... Then the suggestion to pursue Jeni's solution and proposal 27. And I say "Not here". We have higher priorities.
... We do not need to go to this level. Besides, I think there are many problems; the diagrams in the charts are confusing, and perhaps imply that things are identified which in fact are not.
TBL: We have some code that works, but some that screws up.
LM: I have code that talks about metadata, authors, etc. It works fine without all this. And those wanting to link data, sites like Flickr and Facebook, are not waiting for us to do this.
<jar> the code doesn't work fine. they are looking to us. maybe it's not our job and we should refer them elsewhere.
HT: Sorry, they don't interop. That may be OK with them, but they don't interop.
<jar> We need to say AWWW may be right as a matter of principle, and false as a matter of fact.
NM: I am sympathetic to a lot of what LM says
<LM:> i think the architecture of URLs is important, but the mass of the community that needs work on URLs don't need THIS work.
NM: I find these sessions difficult to chair -- this is, in my view, very important, and the TAG is the right place to work on it, but we are not making the kind of progress we need given its importance.
LM: we need work on comparison of URLs effecitvely, we need work on registerProtocolHandler and the security properties, we need work possibly on data in URLs
<jar> I am completely sympathetic with LM. I think the conclusion is correct, even if its justification is wrong on some of the facts.
NM: Why is it any more likely now than a year ago that we are converging
NM: I'm only happy with pushing this forward if we also agree to go back to AWWW and review everything we say about identity, and either revise it or re-iterate that it stands despite our new take. There was real value in that advice, and we shouldn't throw it away.
TBL: I don't think that much of that will change.
<jar> But I can use a URI to identify a single thing, but have no way to coordinate with someone else whether what I use it to identify, is what someone else is going to use it for.
<jar> AWWW advice is not operational. Doesn't tell anyone how to coordinate.
<jar> There's a serious mistake in AWWW. That should be fixed.
<Stuart> Aside: the great global graph will always evaluate 'false'. The web is inherently an inconsistent place. Robust clients will always need to take a 'sceptical' disposition - provenance is important. Provenance on the basis of request (or responding URI - content-location:) is part of the story. ... but in the long run we will need more in order to live in an inherently incosistent world.
NM: I'd mostly like to show that most of what's in AWWW on identity is still good advice, if perhaps not completely rigorous in the edge cases. The general advice, e.g. not to identify two things with one URI, is great advice even if we don't in all case rigorously define when you have two things.
TBL: I'd like to see something discussing 303 wrt this
proposal
... Not everyone has to read it, but it needs to be done
TBL: I agree with LM that other things are important, but a community came to us and complained loudly about this issue, and we owe it to them to respond
LM: A large part of the world approaches URLs entirely operationally, and the use of URLs in data as a problem of some other community than the "Web". We've accepted the deprecation of XML as not on the critical path of the Web, not on the critical path of HTML, not relevant to the majority of W3C's audience. Let's accept that for URI semantics.
NM: Stipulate that's all true, TBL, if we're not ever going to converge we have to agree to stop at some point
LM: We convened a task force on XML-HTML unification, and we decided not to pursue the topic further.
... This isn't the end of XML, but it's implicitly no longer on the main strategic Web path going forward, we're not pursuing it. I can't see the community that cares about this issue as anywhere near the importance of the community that cared about HTML / XML convergence.
LM: Why can't we do that for this issue?
<LM:> why don't we accept that resolving this problem isn't central to web architecture?
JT: To wrap this, we need to go to the community, discuss background, tell the story about limits on agreeing on what URIs identify.
JT: I think we should pursue the primer document and take it to conclusion
JT: The stuff around what RDF itself does is the responsibility of the RDF working group.
JT: The primer makes clear that specs in general, therefore RDF in particular, must take responsibility for requiring URI documentation
JT: And then the more detailed work on proposal 27 goes to the RDF community as our contribution to helping them do that job
jt: the work JAR has done should be given to the RDF community
... that would be my "getting out of it" strategy
noah: is this something we could be done with the primer in 6 months
Jeni: I think the RDF community will need some guidance
jar: the important thing is coordination of URIs in documents ... if you're documenting something, you have to say what you mean
... It sounds like we're getting closer to being on the same page
<noah> jar: if you want to get communication, you need agreement on <context>?
jar: the main architectural issue is that you have to agree on meaning, not specifying what URIs identify. You need transparency
LM: There's more ambiguity than use/mention. There's whether you mean it now vs. forever. Do you mean just the HTML or the transcluded content. etc?
<jar> registries and specs are how you get transparency. that hasn't been achieved in rdf. we need to admit that.
jeni: proposal is to go back to the community with the argument made in the background section, to pursue over the next 6 months the publication of the primer as a recommendation, and to shelf the decision about how this applies to RDF to the RDF community
<jar> . go back to community with the argument in background page. to pursue pub of primer (URIs in data as rec). to hand rdf off to rdf wg.
JT: Proposal: 1) go back to community with perspective in background section; 2) publish primer as a rec in 6 months; 3) move responsibility for RDF bits to RDF WG
Noah: except for my concern about the arch document
ashok: have we had any feedback in the community?
<jar> Arch doc is wrong or at least fatefully incomplete, and "should" be amended. that's separate
Jeni: generally, it's ok
<ht> Maybe we do need to call out the difference between the two qualitatively different kinds of 'ambiguity': the lp/ptopic one, which is specific to URIs, and the whole host of hayes/booth/etc. ambiguities which arise for almost any kind of referring expression.
ht: My guess is that the people paying attention will not push back. No one left standing wants to win, people just don't want to lose
timbl: I'm worried about going into the RDF working
group. it's taken a long time for these three people to come to
a working situation, even being on the TAG together
... I think the danger when it hits the RDF working group, there's a tendency to go off into philosophical tangents
<jar> Broader coordination on URI "meaning" would have been good. (For new URI schemes it would be great.) It's too late for that, the space has been populated noninteroperably.
timbl: RDF working group comes to it from a model theory ... we should push on it a bit, should we do more work before handling ... i'd like to see an example from schema.org and rdf examples [scribe didn't catch this well]
<larry> jeni mentioned that the primer would turn into a rec. would it make sense ....
<jar> (Can we push on application of RDF to the web, as Tim suggests, without doing more work? - maybe we can do this via a use case.)
<noah> . PROPOSAL: 1) Go back to community with perspective from background section on what URIs can or can't be known to identify 2) publish URIs in Data primer as a rec 3) publish a note base on proposal 27 with intention to transition to RDF WG, all by April 1 2013
<jar> ... I don't even want to do it as a note ... I'd rather spend time with Ivan and Sandro talking through it with them
<noah> . PROPOSAL: 1) Go back to community with perspective from background section on what URIs can or can't be known to identify as the response to change proposals 2) publish URIs in Data primer as a rec 3) publish a note base on proposal 27 with intention to transition to RDF WG, all by April 1 2013
<ht> JAR, not sure what you mean by "application of RDF to the web" ?
<jar> ht, I think I'll have to explain that later.
<noah> PROPOSAL: 1) Go back to community with perspective from background section on what URIs can or can't be known to identify as the response to change proposals 2) publish URIs in Data primer as a rec 3) publish a note base on proposal 27 with intention to transition to RDF WG, all by April 1 2013
<noah> RESOLUTION: 1) Go back to community with perspective from background section on what URIs can or can't be known to identify as the response to change proposals 2) publish URIs in Data primer as a rec 3) publish a note base on proposal 27 with intention to transition to RDF WG, all by April 1 2013
<noah> Agreed without dissent
RESOLUTION: 1) Go back to community with perspective from background section on what URIs can or can't be known to identify as the response to change proposals 2) publish URIs in Data primer as a rec 3) publish a note base on proposal 27 with intention to transition to RDF WG, all by April 1 2013
<jar> I was muted
<ht> ACTION: Henry with help from JAR and JT to produce a publishable version of Issue57Proposal27 (http://www.w3.org/wiki/TagIssue57Proposal27), due 2012-12-31 [recorded in http://www.w3.org/2012/10/08-tagmem-irc]
<trackbot> Created ACTION-751 - With help from JAR and JT to produce a publishable version of Issue57Proposal27 (http://www.w3.org/wiki/TagIssue57Proposal27), due 2012-12-31 [on Henry Thompson - due 2012-10-15].
<ht> trackbot, action-571 due 2012-12-31
<trackbot> ACTION-571 Write up comments on microdata and RDFa due date now 2012-12-31
<ht> trackbot, action-751 due 2012-12-31
<trackbot> ACTION-751 With help from JAR and JT to produce a publishable version of Issue57Proposal27 (http://www.w3.org/wiki/TagIssue57Proposal27), due 2012-12-31 due date now 2012-12-31
Noah: asked for room Monday morning & Friday afternoon
... TAG members will probably meet? No formal TAG meeting
Larry, Peter, Ashok, Henry, Tim, Jeni (Only plenary day)
noah: couple of weeks ago, note from Jeff about joint meeting with TAG at TPAC, roughly half the tag, explore options
... does anyone wants to say about their plans
4 positions up for election, including Robin's
ashok: couple of things: should we stand up and speak about TAG work. I've offered every year for 4-5 years, but maybe situation with election
Jeni: Robin suggests lightning talks
<jar> ACTION jar (with help from HT and JT) to draft the TAG's response to the ISSUE-57 change proposal
<trackbot> Created ACTION-749 - With help from HT and JT to draft the TAG's response to the ISSUE-57 change proposal [on Jonathan Rees - due 2012-10-15].
<jar> process initiated on 29 February 2012, based on
<jar> http://www.w3.org/wiki/TagIssue57Proposal27/Background and F2F minutes
<jar> of 8 October 2012.
<jar> oops.
<jar> multi-line
<jar> editing action
jeni: 5-minute lightning talk, this is what we're working on, these are the positions that are available
noah: normally been my custom make sure we have a status report
... quarterly is too frequently, i've been working on the product pages, when you give the lightning talk, tell people the web page
larry: ...
... two communities ... members, public. lightning talk on election
ht: doing lightning talk is excellent idea, pointless to ask for 15 minutes
jeni: half-day AC on tuesday, half-day on thursday
"Getting more security/network protocol/IETF experience on the TAG would also be helpful. Know any other candidates?"
s/Jenni/Jeni/
<ht> "The TPAC2012-Committee is planning the day"
<ht> http://www.w3.org/wiki/TPAC2012-Committee
1) promote past work & dashboard 2) recruit volunteers 3) get feedback on documents 4)
<Yves> http://www.w3.org/wiki/TPAC2012/SessionIdeas
<noah> 4) hilite http://www.w3.org/2001/tag/products/ as "Dashboard" to track what TAG is doing and has done
<ht> HST wants to show 3 slides: Publishing and Linking; Frag-ids; Participate, review, stand for the c'ttee
4) solicit ideas for topics to take up
ok
<Yves> http://www.w3.org/wiki/TPAC2012
<noah> ACTION: Noah to contact Ian about TAG participation in TPAC -- see minutes of 8 Oct late afternoon [recorded in http://www.w3.org/2012/10/08-tagmem-irc]
<trackbot> Created ACTION-750 - Contact Ian about TAG participation in TPAC -- see minutes of 8 Oct late afternoon [on Noah Mendelsohn - due 2012-10-15].
<noah> Convey sense that 5 mins might be right on general TAG issues
<noah> JT: 5 mins at plenary for everyone (Jeni) 5 mins AC (Henry or Larry)
<noah> ACTION-563?
<trackbot> ACTION-563 -- Noah Mendelsohn to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F -- due 2012-11-01 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/563
noah: background on tracking high priority items for Jeff
emphasis on things Jeff wouldn't have noticed otherwise
jeni: http 2.0 stuff
noah: what's the issue?
larry: candidate to including working on web performance, benchmarking, HTTP performance
tbl: 3986 forking, URLs, registerProtocolHandler
<noah> Jonathan: I'll call on you...I think it may be something to disucss w/Jeff, who has already reached out. I don't think it's in THIS list, which is to alert to technical issues he's missing.
<Zakim> jar, you wanted to ask is 'TAG effectiveness' something to raise with Jeff?
larry: not worth teasing out all the related issues of URL issues
noah: Jeff's mainly on technical issues
<noah> LM: Red flag for me: It seems to me that Web security is in crisis. Exponential growth in attacks, outpacing expertise to address.
ht: mnot observed that he thought that as apocalyptically that the security train wreck was gathering speed. The security APIs and the security architecture has been lost sight of
... there's nobody looking at security at the highest level
<jar> http://www.computer.org/portal/web/csdl/doi?doc=abs/html/mags/sp/2005/06/j6003.htm
ht: his colleague was saying "black web" and "white web", one is "credit cards are known", vs. people who can be billed
<jar> It was Butler Lampson, and the colors were "red" and "green"
<ht> Well, on the day it was zuwei, wasn't it?
<ht> I guess he credited Butler
<jar> zewei chen (of Akamai)
<noah> LM: I see security reviews getting lost between IETF and W3C. Attacks cross abstraction boundaries.
<noah> TBL: makes a least power argument that it's hard to prove properties of URIs if the specifications for URIs are imperative
tbl: if you have one group defining syntax of URLs, and another group defining a turing machine for processing, then the mismatch becomes an exposure because the groups don't agree on syntax
... talking about "language of least power"
noah: also there are stuff you would tend to design during the design phase
... also things we thought were secure aren't falling apart
<noah> NM: are we organized to respond to threats, whether in new specs or not.
<noah> LM: performance is multi-level.
<ht> For Lampson on red and green webs, see http://research.microsoft.com/en-us/um/people/blampson/slides/accountabilityandfreedom.ppt
<noah> Great paper on layering and performance: http://portal.acm.org/citation.cfm?id=13677.13678
<noah> LM: Speculating on cloud stuff...ashok?
ashok: headlights thing... they wanted to do some cloud standards, and I discouraged. Cloud security is a whole different thing, there have been some interesting attacks
<noah> AM: Some earlier things came up, but W3C role seemed unclear to me. Cloud security is a whole different thing. Some attacks: co-locating VMs and causing buffer overflows.
noah: share hosting, someone running on the same machine -- one little leak, someone reinstalls your whole environment
<noah> ACTION-563?
<trackbot> ACTION-563 -- Noah Mendelsohn to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F -- due 2012-11-01 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/563
<JeniT> ACTION: Jeni to update URIs in data primer based on discussion at Tuesday F2F [recorded in http://www.w3.org/2012/10/08-tagmem-irc]
<trackbot> Created ACTION-752 - Update URIs in data primer based on discussion at Tuesday F2F [on Jeni Tennison - due 2012-10-15].
<noah> ACTION: Larry to do first draft of technical issues list for Jeff - Due 2012-10-22 [recorded in http://www.w3.org/2012/10/08-tagmem-irc]
<trackbot> Created ACTION-753 - do first draft of technical issues list for Jeff [on Larry Masinter - due 2012-10-22].
<Ashok> Butler Lampson's slides --- slide 16 Notes
<timbl> "Red-Green is our name for the creation of two different environments for each user in which to do their computing. One environment is carefully managed to keep out attacks – code and data are only allowed if of known trusted origin – because we know that the implementation will have flaws and that ordinary users trust things that they shouldn’t. This is the “Green” environment; important data is kept in it. But because lots of work, and lots of entertainment, requires accessing things on the Internet about which little is known, or is even feasible to know, regarding their trustworthiness (so it can not be carefully managed), we need to provide an environment in which this can be done – this is the “Red” environment. The Green environment backs up both environments, and when some bug or user error causes the Red environment to become corrupt, it is restored to a previous state (see the recovery slide); this may entail loss of data, which is why important data is kept on the Green side, where it is less likely to be lost. Isolation between the two environments is enforced using IPsec." -- Butler Lapson Op.cit.
<jar> think: two computers connected via IP (NOT IPsecC or shared memory)
<noah> Time check - 3 mins
<timbl> http://www.apps.ietf.org
<jar> (hmm, maybe got that s/// wrong.)
adjourned for day