IRC log of tagmem on 2012-10-08

Timestamps are in UTC.

08:09:34 [RRSAgent]
RRSAgent has joined #tagmem
08:09:34 [RRSAgent]
logging to
08:09:39 [Yves]
trackbot, start meeting
08:09:41 [trackbot]
RRSAgent, make logs public
08:09:43 [trackbot]
Zakim, this will be TAG
08:09:43 [Zakim]
ok, trackbot; I see TAG_f2f()3:00AM scheduled to start 69 minutes ago
08:09:43 [Ashok]
scribenick Ashok
08:09:44 [trackbot]
Meeting: Technical Architecture Group Teleconference
08:09:44 [trackbot]
Date: 08 October 2012
08:10:13 [Ashok]
Topic Governance Framework
08:10:28 [Ashok]
LM: There are 2 dated links
08:10:35 [masinter]
08:11:04 [masinter]
08:12:10 [Ashok]
The earlier version is based on work I had done with some other folks re. Publishing and Linking was an example of how regulation interacts with architecture
08:12:21 [Ashok]
... what's the igger picture
08:12:37 [Ashok]
08:13:16 [Ashok]
LM: I got feedback that it said too little or too much ... too short to be an intro
08:13:32 [Ashok]
... so I cut them them way down
08:13:53 [Ashok]
LM: It's a short document
08:14:11 [Ashok]
LM: Intro is similar to the P&L document
08:14:30 [Ashok]
... then there is an Audience section
08:14:38 [Ashok]
... why are we doing this
08:15:00 [Ashok]
... technical understanding can help legislators make better laws
08:15:17 [Ashok]
... detials are now just a bulleted list
08:15:30 [Ashok]
08:15:59 [Ashok]
LM: 4.2 talks about where policies and technology interacts
08:18:48 [Ashok]
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
08:19:07 [Ashok]
LM: Final document should not be more than 50% larger
08:19:51 [Ashok]
... goal is to encourage W3C to take up other areas where there is conflict between technology and policy
08:20:36 [Ashok]
LM: There is ongoing discussion about ITU and other bodies re. Governance ... connectivity, net neutrality, etc.
08:20:57 [Ashok]
LM: But issues are lot broader e.g. cyberbullying
08:21:42 [ht]
Wrt conflict between regulations, compare the two things linked from the following page:
08:21:48 [JeniT]
q+ to make a suggestion
08:21:59 [Ashok]
Ashok: Use of Social Media to mobilize opinion
08:22:36 [Ashok]
NM: It would be good if the introduction answerred my questions
08:23:20 [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?
08:23:31 [Ashok]
JeniT: This would be a good subject to have this as a page in the TAG space that we could link future work from
08:23:31 [JeniT]
08:23:54 [noah]
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
08:23:57 [Ashok]
LM: Not sure if this work fits in with what the TAG does
08:23:57 [JeniT]
08:24:18 [noah]
NM: I think the document needs to more explicitly state its goals
08:24:32 [Ashok]
... it's a good way to broaden the discussion started by the P&L document
08:24:32 [noah]
LM: OK, good point. Make sure it's in the minutes.
08:24:36 [noah]
NM: Done
08:24:40 [masinter]
not sure it fits entirely within the TAG's remit
08:24:53 [noah]
08:25:15 [Ashok]
HT: Would be good to have Daniel Dardellier come talk to us about govenance
08:25:20 [masinter]
the word "governance" is used with a much broader meaning than is typical in the Internet community
08:25:31 [Ashok]
... his perspective would be useful
08:31:09 [ht]
ITU holding 1st ever "World Conference on International Telecommunications" (WCIT):
08:31:21 [ht]
December, 2012
08:32:58 [Ashok]
LM: We could go thru the doc section by section
08:33:49 [Ashok]
NM: I not convinced whether a document that just whets your appetite if a good idea
08:34:01 [Ashok]
... I'm willing to think about this
08:34:18 [masinter]
missing acknowledgement
08:34:58 [Ashok]
LM: I responded to comments by contracting section 4
08:35:40 [ht]
08:36:16 [Ashok]
HT: I put a link to the ITU meeting in Dubai ... the above is their base document
08:38:06 [Ashok]
LM: I have not addressed comment on use of word "Governance" . We are talking about a much broader set of issues
08:38:37 [Ashok]
LM: I happy with the intro ... it has been carefully reviewed
08:38:56 [Ashok]
Section 2 spells out the goals of the document
08:39:41 [Ashok]
Section 3 talks abput Governance requirements constrain Architecture ... some examples would help here
08:40:13 [Ashok]
NM: Section 4 is too brief
08:40:35 [Ashok]
08:41:07 [Ashok]
JeniT: Can we add pointers to other sources here?
08:41:51 [Ashok]
NM: Need more detail in Section 4
08:43:35 [Ashok]
Ashok: I want to see examples of where policy influences architecture and vice versa
08:44:31 [Ashok]
LM: Started to think about jurisdictional differences in policy ... how does that influence international businesses
08:45:29 [noah]
08:45:44 [noah]
08:45:48 [noah]
q- ashok
08:46:06 [Ashok]
... e.g. authentication, what material is illegal etc.
08:46:40 [Ashok]
... when we move into a position where your action on a device can have global effects
08:47:04 [ht]
Wrt ITU again, and their proposed Regulation:, see e.g. the first item on Page 29, which explicitly puts Internet traffic within their scope
08:47:43 [Ashok]
LM: We need guidelines for legal dept and project managers ... responibilities are distributed
08:48:22 [Ashok]
NM: It's a valuable area but what are we contributing
08:48:53 [Ashok]
LM: When i showed it to people I got feedback that it was useful and we should keep working on it
08:49:26 [Ashok]
LM: Needed to be complete ... misiing for example security
08:49:55 [Ashok]
Tim: There has been pushback from folks saying TAG does not do Policy
08:50:18 [Ashok]
LM: This is a bridge between the technologists and the policy folks
08:50:28 [Ashok]
NM: Maybe a different title
08:51:15 [Ashok]
LM: In 4.2 we talk about other documents like the P&L we may want to work on
08:51:35 [Ashok]
Tim: What about fairness, growth
08:51:53 [Ashok]
... these are things goevernments worry about
08:52:20 [Ashok]
08:52:47 [Ashok]
Tim: What are technical properties that enable fairness
08:53:06 [Ashok]
LM: Something about no monopolies, open markets
08:53:29 [Ashok]
... antitrust issues
08:54:01 [Ashok]
NM: The P&L document is really about explaining technology for policy makers
08:54:47 [Ashok]
LM: This is the inroductory framework and P&L is first volume
08:55:28 [Ashok]
NM: What are the other pillars that site next to P&L
08:55:44 [Ashok]
08:56:59 [Ashok]
LM: We could publish as a note and presenting it to the AC
08:57:15 [Ashok]
NM: Should we do this with the AB?
08:58:34 [Ashok]
Tim: Lot of interesting work on the bullted points ... these need to be mentioned
08:59:33 [Ashok]
HT: We should focus on section 3. That's our business
09:00:51 [Ashok]
Tim: I see the world as being a set of protocols and each protocol is a mixture of technical and social
09:01:16 [masinter]
09:01:26 [Ashok]
... linking to stuff involves a social aspect
09:02:00 [Ashok]
... breaks when people link on how to make a bomb. So we need constraints both social and technical.
09:02:57 [Ashok]
Tim: Historically geeks and lawyers have danced around each other ...
09:03:20 [Ashok]
... not formed by pieces coming together
09:03:55 [Ashok]
NM: The Web and facebook have both technical and social aspects
09:04:27 [masinter]
"Not long after computer scientists first began working on the technical design of the network that ultimately became known as the Internet, in 1969, they began to document their discussions, information shared, and decisions made in a series of documents known as the Internet requests for comments that is still being used for this purpose 40 years later. A comprehensive inductive reading of these documents reveals that legal and policy
09:04:27 [Ashok]
NM: We need to fill the gaps between technology and society
09:04:27 [masinter]
issues were often raised or confronted in the course of resolving technical problems. In many of these instances, the technical decisions that resulted had law-like effects in the sense that they constrained or enabled the ways in which users can communicate and can access and use information over the Internet, whether or not such decisions supported or subverted legal decision-making, and whether or not legal decision-makers understood
09:04:27 [masinter]
the societal implications of the technical decisions that were being made. This is one of the two ways in which technical and legal decision-making have become interpenetrated. The literature on legal engagement with problems generated by the technical features of the Internet is vast. This article appears within the nascent literature on technical engagement with legal problems. It does so in an effort to contribute to the building of
09:04:33 [masinter]
a shared epistemic and decision-making space that involves both the technical and the legal communities."
09:05:22 [Ashok]
Tim: Re. email the original thinking was that this was a research network and should be used only for research
09:05:57 [Ashok]
... when the use policy was relaxed it turned out that some issues such as spam were not addressed.
09:07:11 [Ashok]
LM: People seem to be uncertain as to where to go with this
09:07:41 [Ashok]
AM: Can we mention the relevant technical issues under each bullet in section 4
09:08:11 [Ashok]
NM: We need success criteria to decided whether to go forward with this document
09:08:24 [Ashok]
09:09:21 [masinter]
what would have to happen to this document before you would be happy to see the TAG work on it?
09:10:49 [Ashok]
Tim: Your list here is sort of like the IETF saying you need a Security Considerations section in each RFC
09:11:25 [Ashok]
... with P&L we had clear example of misunderstandings re. Linking and Embedding
09:12:18 [Ashok]
NM: Do you have what you need to move ahead?
09:12:40 [Ashok]
LM: I need a poll on whether we should go forward with this document
09:13:16 [Ashok]
HT: I'm very concerned about redoing work that has been done elsewhere is greater length
09:13:53 [Ashok]
... s/is/in/
09:14:32 [Ashok]
... section 3 in scope and should be grounded by discussion with Danny Wietzner
09:15:21 [Ashok]
PL: It's an interesting document ... agree with Henry ... maybe the W3C should concerned with this rather than the TAG
09:15:38 [Ashok]
YL: The TAG should stick to technical matters
09:16:28 [Ashok]
... works on how architecture of Web impacts policy and how policy impacts Web Architecture
09:17:00 [Ashok]
JeniT: Section 3 really useful ... good summary of areas of concern
09:17:34 [Ashok]
... eplain technical concepts to policy makers
09:17:44 [Ashok]
09:17:55 [Ashok]
... need links to existing work
09:19:06 [Ashok]
Tim: Prefer a view where the system is designed holistically. Privacy is a property of some systems ... provides invariants on which othet
09:19:15 [Ashok]
09:19:22 [Ashok]
sytems depend
09:20:14 [Ashok]
... Similarly, copyright, accessibily are properties of this system
09:20:48 [Ashok]
... As a list of things to watch out for is reasonable
09:21:14 [darobin]
darobin has joined #tagmem
09:21:22 [Ashok]
... I would not like future architecture to be done piecemeal
09:21:34 [Ashok]
... useful as a checklist
09:22:29 [Ashok]
... I'm worrying about doing architecture from this matrix ... for example accessibility be added on because some govt. wants it
09:22:57 [Ashok]
Tim: What the document is trying to say is not very well defined.
09:23:11 [ht]
s/elsewhere is/elsewhere at/
09:23:23 [timbl]
Askok: What I would do is take the bullets and talk about tech areas which influence them.
09:23:28 [noah]
AM: I hav mentioned: I would take the bullets, and speak of technical areas that impact security, copyright, etc.
09:23:35 [timbl]
…. and then find where others have talked bout these things.
09:23:44 [noah]
AM: Difficult part is to find what othrs hav already done
09:23:48 [timbl]
… As a very practical thing to go forward with this.
09:23:55 [ht]
s/grounded by/grounded in existing policy studies, start with/
09:24:25 [Ashok]
NM: I've expressed some concerns about the goals. Not sure, we need a document that does not stand on it's own
09:24:43 [Ashok]
... this is like an intro to other work we need to do
09:25:33 [Ashok]
... I'm reserving judgement ... perhaps you could add some technical depth
09:26:13 [Ashok]
LM: I have got some useful feedback ... need to think about how to go further ... perhaps a blog post
09:26:51 [Ashok]
NM: Not saying "we don't want to see this ever again"
09:27:05 [Ashok]
LM: I will work further on the document
09:27:36 [Ashok]
Break for 20 minutes
09:43:11 [Ashok]
09:44:29 [Ashok]
Topic: Documenting meaning of individual IRIs (ISSUE-57)
09:45:37 [Ashok]
HT: Background
09:50:45 [Ashok]
HT: This is a starting point for the perspective Jeni, Jonathan and I have taken
09:50:58 [Ashok]
... it is a 20,000 foot level set
09:51:12 [Ashok]
... if you think its wrong we need to worry
09:51:51 [Ashok]
HT: Distributed extensibility begets incompatible extensions
09:52:06 [Ashok]
... this is by design
09:53:20 [Ashok]
... XML does not control the tags used. You can design the meaning of the tags you use
09:54:08 [Ashok]
... XML has a mitigation i.e namespaces
09:54:20 [Ashok]
LM: I need more context
09:54:51 [Ashok]
HT: This is in aid to improving the situation re. HTTP Range-14 resolution
09:55:16 [Ashok]
HT: We are building towards a proposal
09:55:57 [Ashok]
... we have 3 documents, this document, the primer and a detailed proposal
09:56:18 [Ashok]
HT: Rec track for primer and technical document
09:58:10 [masinter]
"underspecification" is a value judgment, not specified as much as expected
09:59:22 [Ashok]
HT: Sometimes, like in the case of RDF, extensions are incompatible ... usually this is not a problem
10:00:03 [Ashok]
... problems arise when incompatible extensions are expected to interoperate
10:00:42 [masinter]
disagree with 'require' in "Interoperability requires keeping track of which extension is intended." -- keeping track is one way, there are other ways
10:01:18 [jar]
jar has joined #tagmem
10:01:29 [Ashok]
HT: Obvious way is to keep track of which use is expected
10:01:52 [masinter]
yes, it is "one obvious way"
10:02:33 [Ashok]
HT: Otherwise you will get incorrect conclusions
10:04:08 [Ashok]
HT: Many ways to keep track of which extension is intended
10:06:41 [Ashok]
HT: Proposal is to make distinctions via the immediate context
10:07:39 [Ashok]
... we cannot get agreement on what the URIs mean ... but we can get agreement on what the sentences mean
10:07:59 [masinter]
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"
10:08:40 [jar]
there is no such thing as universal understanding.
10:08:42 [Ashok]
HT: We will put the burden of identification on the meaning of properties
10:09:01 [Ashok]
LM: Who has to agree on the meaning
10:09:06 [jar]
there is no way to control what someone else understands in any situation
10:10:02 [jar]
saying that agreeing on meaning of sentences instead of words is not an improvement, is a straw man
10:11:24 [jar]
what another agent thinks something means is unmeasurable, undetectable, a private matter, not in the scope of any spec
10:11:34 [Ashok]
JeniT: The crucial thing is where the URI is used ... is it referreing to the content or description of the content
10:11:45 [jar]
specs only govern tests of conformance. whether an agent conforms to a given spec.
10:12:08 [Ashok]
... we are concerned whether an app using the URI does the right thing
10:13:08 [jar]
so, masinter, "my statements mean what i think they mean" cannot be a goal
10:14:32 [jar]
at least not in a spec
10:15:59 [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.
10:16:33 [jar]
will try to restrain myself
10:18:49 [Ashok]
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
10:20:02 [Ashok]
... not specific to RDF
10:20:02 [Ashok]
... addresses people who are writing data and what they should care about
10:20:04 [timbl_]
timbl_ has joined #tagmem
10:20:14 [ht_home]
ht_home has joined #tagmem
10:20:28 [JeniT_]
JeniT_ has joined #tagmem
10:20:32 [masinter`]
masinter` has joined #tagmem
10:20:54 [Ashok]
Jeni goes thru the document:
10:21:39 [Ashok]
The primer is at
10:26:02 [Ashok]
Tim: David Booth said that all we need to worry about is RDF ... in that RDf is creating the problem
10:27:46 [jar]
that's not correct
10:27:55 [jar]
the json case is interesting.
10:28:15 [Ashok]
HT: If you write XML or JSON you always say what the URIs means
10:28:24 [jar]
if we can give advice on that one, then the rdf case will follow… rdf is harder though, so start with json
10:28:25 [Ashok]
10:29:17 [Ashok]
JeniT: Section 3 introduces Landing Pages which are pages about something else
10:31:06 [Ashok]
... they don't have to HTML. Maybe JSON or XML or RDF that describes what is it that they are talking about
10:31:58 [Ashok]
... sometimes the properties get mixed up ... they could apply to the page or the content
10:32:46 [Ashok]
JeniT: If the data is about a person then it's clear what the properties refer to
10:34:24 [jar]
timbl: e.g. phone number and assistant's phone number
10:35:41 [Ashok]
Section 4 describes Data Normalization
10:36:52 [Ashok]
Section 5 says not always possible to normalize
10:37:28 [Ashok]
HT: People don't always normalize
10:38:21 [jar]
q+ jar to In JSON, this has to do with the relation between the property value and the @id value? Or is @id just another property.
10:38:26 [jar]
10:38:58 [Larry]
10:39:58 [Larry]
based on
10:43:47 [ht_home]
TBL commenting on the 'implied properties' diagram
10:44:16 [Ashok]
Ashok has joined #tagmem
10:46:05 [Ashok]
JeniT: 5.2 talks about when a Landing Page describes more than one thing
10:47:58 [Ashok]
JeniT: 5.3 talks about why these distinctions are particularly important
10:49:12 [Ashok]
... 5.4 is about how you find the documentation
10:50:18 [Ashok]
JeniT: 6 is about recommendations about data producers and data consumers
10:50:51 [Ashok]
... say what appliactions can do with URIs ... when they dereference what they can expect
10:52:12 [jar]
something about appending to get URIs in various doc formats, XML, turtle, etc.
10:52:39 [Ashok]
Discussion of namespace URIs
10:53:04 [Ashok]
NM: namaspec names can have a fragment in the name
10:53:25 [Ashok]
HT: Using a string which is a relative URI is deprecated
10:54:42 [Ashok]
JeniT: 6.1.1 talks a metaformats such a RDF and says they should document how the the URIs are used
10:54:55 [Ashok]
10:55:31 [jar]
don't talk about identification please. identification is not testable
10:56:22 [jar]
reference is not testable. please don't use the word
10:56:37 [jar]
'identification' and 'reference' have no place in normative language
10:56:43 [jar]
similarly 'meaning'
10:57:11 [jar]
as soon as these words are uttered, people start arguing.
10:57:15 [Ashok]
NM: Henry said URI refers only to one thing but sometimes it refers to other things
10:57:19 [jar]
just stop please.
10:57:33 [Ashok]
... we shall discuss in detail in the main proposal document
10:57:56 [jar]
please let's not get into REST
10:58:04 [jar]
please let's just talk about JSON
10:58:22 [Ashok]
HT: Please wait till we get to Proposal 27
10:58:35 [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.
10:59:08 [Ashok]
NM: Need to be rigorous about terminology
10:59:14 [jar]
10:59:24 [jar]
Just don't talk about!
11:00:20 [jar]
I am not going to speak up. I am on the queue. I want Jeni to finish
11:00:29 [ht_home]
JAR is channeling Wittenstein
11:00:38 [timbl]
Nothing, jar, is testable
11:00:53 [jar]
timbl, I disagree with that.
11:01:29 [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)
11:01:35 [Ashok]
JeniT: 6.2 talks what conclusions you can draw if you are a consumer of the data
11:01:39 [jar]
timbl, that is the same as saying there is no truth.
11:01:51 [Larry]
everything is testable, it's just that most tests give inconclusive results
11:02:24 [Ashok]
JeniT: 6.3 talks about Publishing data
11:02:29 [noah]
btw: the JSON case IS a rest case. The JSON itself, and the typical URIs it references, are typically retrieved with GET
11:02:36 [Ashok]
... section 6 needs more work
11:02:45 [ht_home]
Noah, REST is not an agreed vocabulary, we don't want to depend on assuming it is
11:03:02 [ht_home]
zakim, q?
11:03:02 [Zakim]
I see jar on the speaker queue
11:03:26 [jar]
lm: asking about link relations
11:03:35 [Ashok]
LM: What about Link Relations, what about XMP?
11:04:08 [jar]
XMP (or the doc formats that use it) is underspecified because it doesn't answer this question.
11:04:49 [jar]
11:04:58 [Ashok]
LM: Link Relations would be another usecase to discuss
11:05:01 [ht_home]
ack jar
11:05:01 [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.
11:05:47 [Ashok]
jar: The approach in this document is good ... it avoid trigger words that would cause us to rathole
11:06:23 [Ashok]
... can we get consensus on the advice and then test against various usecases ... start with JSON
11:06:40 [Ashok]
... RDF is complicated because it has entailment
11:06:48 [Ashok]
... RDF would be the final test
11:07:04 [Larry]
XMP uses rdf:about=""
11:07:24 [jar]
So, talk about XMP first, put off RDF in general.
11:07:27 [Ashok]
HT: We should not import terminology from REST. REST is not well specified and it woukld cause confusion
11:07:29 [jar]
Let's go bottom up.
11:08:05 [jar]
what you're saying doesn't even have agreed meaning
11:08:08 [Larry]
just testing the document about other things I think about, it looks ok
11:08:10 [Ashok]
NM: To me this implies that what a URI implies is where it is used
11:08:15 [jar]
you're not even making a point
11:08:43 [jar]
stop being deep
11:09:05 [jar]
we're ONLY talking about how to write specs please
11:09:18 [Ashok]
NM: REST gives same answer where the URI is used. I'm reluctant to lose that
11:09:34 [Ashok]
JAR: Don't go there
11:09:56 [Ashok]
NM: I think this is an important point
11:10:22 [Ashok]
JAR: Identification does not occur in the document
11:10:46 [JeniT]
/me jar, you're breaking up a little
11:10:54 [jar]
If the document talks about 'identification' or a function from URIs to things that would be an error in the document
11:11:38 [Ashok]
Tim: We are taling about something over which there has been a great deal of debate and people have been burnt
11:11:49 [Ashok]
11:12:16 [jar]
context is always important
11:12:24 [jar]
as Larry keeps saying. I agree totally
11:12:39 [Ashok]
Tim: They are saying it depends only on the property
11:12:59 [jar]
that's impossible, Noah
11:13:08 [jar]
and irrelevant
11:13:19 [Ashok]
NM: I want a function from a URI to something that is completly context independent
11:13:29 [Ashok]
... losing that is very deep
11:14:05 [Ashok]
HT: We tried to do that and we failed ... others have tried and failed
11:14:33 [Ashok]
JAR: People hav been trying to do that for 120 years and failed
11:14:40 [Ashok]
11:14:56 [Ashok]
HT: We set out to solve a smaller problem
11:15:19 [jar]
webarch is wrong.
11:15:34 [jar]
and not the subject of this exercise
11:16:08 [Ashok]
HT: There are different constituencies that recognize the words differently
11:16:17 [JeniT]
11:16:46 [Ashok]
NM: I would like to see if we can reconcile with WebArch
11:17:04 [jar]
"URIs identify" is patently false. Could be true (enough) in some cases. Empirically fase for http: URIs
11:17:14 [jar]
11:17:16 [JeniT]
timbl: I want to use an analogy between classical and quantum mechanics
11:17:37 [Ashok]
Tim: It's like classical mechanics and Quantum Mechanics
11:17:50 [jar]
My procedural advice, to put off the hard questions until the easier ones are answered, is being totally ignored
11:18:47 [ht_home]
TimBL channeling Pat Hayes !
11:18:57 [jar]
we shoulda ll channel Pay Hayes
11:19:16 [jar]
s/a ll/ all/
11:20:46 [Ashok]
Tim: Pl. wait until they get to the end of the document
11:20:57 [JeniT]
11:21:14 [ht_home]
Break for lunch
11:21:20 [Ashok]
Lunch break till 1:20
11:23:08 [Larry`]
Larry` has joined #tagmem
11:23:09 [ht]
ht has joined #tagmem
11:57:43 [jar]
s/Pay H/Pat H/
12:05:13 [masinter]
masinter has joined #tagmem
12:17:39 [Stuart]
Stuart has joined #tagmem
12:18:22 [jar]
how was lunch?
12:19:39 [Larry]
scribenick: Larry
12:19:57 [Larry]
Topic: Documenting meaning of individual IRIs (ISSUE-57)
12:21:13 [jar]
ok. will dial
12:21:34 [Larry]
12:21:46 [Ashok]
Ashok has joined #tagmem
12:22:35 [Larry]
ht: this is an attempt to work out detailed RDF semantics for parallel properties
12:22:48 [Larry]
ht: the proposal is algebraic and succinct
12:23:35 [JeniT]
12:24:31 [Larry]
... this is the hardest part of the problem ...
12:25:08 [Larry]
... begining with a simple case initially
12:25:22 [jar]
is everyone on board with this presentation or are some people going to tune out?
12:25:32 [Larry]
... going to focus on disambiguation between landing page and the work
12:25:52 [jar]
little point in going through this if someone is going to disagree with premises at the end
12:25:55 [Larry]
... This is the crucial problem.
12:26:29 [noah]
From the proposal:
12:26:31 [noah]
"Claim: We'll never agree on what the disputed URIs (the GET/200 ones) identify. "
12:27:09 [jar]
context is still important for sentences, larry. ack that
12:27:29 [Larry]
ht: we're just going to focus on what the sentences (triples) mean, without having to agree on the story
12:27:44 [jar]
12:27:49 [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.
12:27:57 [jar]
s/ack that/I ack that/
12:28:36 [Larry]
... the way we're going to do this is ... (missing, something about personal context, 3 communities)
12:29:01 [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
12:30:28 [Larry]
ht: now looking at the example, Scenario
12:30:47 [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
12:33:00 [Larry]
HT: ((explains Interpretation 1, Interpretation 2, "Neutral" Interpretation))
12:34:39 [Larry]
ht: OMF might be an 'information resource' or maybe not, doesn't matter
12:34:52 [jar]
the "landing page" could be *either* the rep or the resource.. doesn't matter. move along.
12:35:02 [jar]
red herring
12:35:32 [Larry]
... but LP can be thought of, in REST turns, a resource
12:35:49 [Larry]
... two functions, 'ptopic' and 'lp'
12:36:29 [noah]
should say lp maps from thing described (possibly a person) to landing page
12:36:57 [Larry]
noah: if the LP was about a person, then OMF would be a person, and ptopic is a function from document to a person
12:37:23 [Larry]
12:37:50 [jar]
P maps what's identified to its author.
12:38:37 [Larry]
noah: "URI interpreted as" confuses me
12:38:58 [jar]
what 'P' identifies maps something (e.g. something that's identified by another URI) to its author
12:39:08 [Larry]
ht: P is a URI that appears in ... interpreted in RDF semantics
12:40:10 [Larry]
noah/timbl: "interpreted" is a term of art? discussion
12:40:43 [Larry]
ashok: Are 'has creator' and 'created by' special, or could i use other words?
12:41:12 [Larry]
ht: any property that is ambiguous would work as part of the setup
12:42:13 [Larry]
((discussion of why moving from Moby Dick to Dickens))
12:42:55 [Larry]
ht: given all of this, can we define properties where members of all three camps can say "landing page by Tomlinson, book by Dickens"
12:43:42 [Larry]
ht: ((reviewing chart))
12:44:13 [Larry]
ht: U vs. Interpretation 1, 2, 3; P is creator property
12:46:05 [Larry]
ht: Now we get to the magic
12:47:06 [Larry]
... "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
12:47:50 [Larry]
solving backwards, Q and R are different functions for Interpretation 1, 2, and 3
12:48:06 [jar]
12:49:25 [Larry]
noah: ((question about domain of Q and R))
12:49:28 [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)
12:50:30 [Larry]
tbl: Q and R are different URIs; the future of data on the web relies on those two not getting overlap
12:51:01 [jar]
I would say, the future of RDF interoperability, in the absence of agreement on "identification" (which has not been forthcoming
12:51:02 [Larry]
ht: we have a URI, we do a GET, we get a page whose author ...
12:51:04 [jar]
12:51:38 [jar]
not "the future of data on the web" since we have seen that the JSON case doesn't rely on "identification"
12:52:35 [jar]
if the web *depended* on "identification" the *present* would be in awful shape
12:52:45 [Larry]
ht: ((reviewing diagrams))
12:53:42 [Larry]
noah: are you looking for people to understand today, or to just agree if this is the right direction
12:54:45 [Larry]
ht: we need the TAG to define two predicates which relate properties that apply respectively to landing pages and things denoted by landing pages, then I document Q bearing the M relation to P ?
12:55:55 [Larry]
noah: ... something something ... which is it?
12:56:32 [Larry]
jar: depends on what you mean by 'evaluate'
12:58:57 [Larry]
ht: Jar, do we have a name for URIs whose XX varies by community
12:59:04 [Larry]
jar: no.
12:59:16 [Larry]
jar: not really needed in RDF semantics
12:59:44 [Larry]
ht: this then leads to a processing model
12:59:53 [Larry]
noah: P is "dc:creator"
13:00:29 [Larry]
jar: "you might use them with hash URIs, but we decided to defer that"
13:01:14 [Larry]
ht: in this paper "disputed URI" is .. XXX
13:01:34 [Larry]
tbl: ... Q and R don't have to be hashless
13:01:45 [jar]
you can think of M and N as cancellation operators. they cancel out the disagreements
13:01:46 [Larry]
... when you define Q
13:02:06 [Larry]
ht: anyone who wants to publish interoperable properties will define them this way
13:02:33 [Larry]
ht: M and N are fixed URIs, they serve the documentation requirement
13:02:46 [Larry]
ht: it's M and N that XXX by definition
13:03:13 [Larry]
jar: they can't allow ... XXX ... something something ..
13:03:30 [Larry]
tbl: do you mean inverse?
13:03:54 [Larry]
noah: they take care of the fact that some communities do indirection one place and not the other
13:04:32 [Larry]
tbl: you're saying P is undisputed?
13:04:42 [jar]
we're positing that.
13:05:14 [Larry]
ht: dc:creator means the author of an authorable thing is ...
13:05:32 [Larry]
tbl: they didn't say whether it should be like U or like Q
13:05:52 [Larry]
ht: if you don't do this, you have to assume they were caught in an infinite regress
13:06:15 [Larry]
Jeni: it would be better if you didn't use dc:creator
13:06:46 [Larry]
ht: p never indirects, it's always direct
13:07:05 [Larry]
ht: creator is always direct
13:07:22 [Larry]
noah: dc:creator are ok in this example
13:08:20 [Larry]
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 the...
13:08:32 [Larry]
ht: in the wild what you're going to find Q
13:08:45 [Larry]
noah: users have ot say Q
13:08:49 [jar]
dc:creator might be used with hash URIs. no problem with that
13:08:58 [Larry]
ht: users only have to say Q if ... XXX ...
13:09:05 [Larry]
ht: and that's why we're not done yet
13:09:29 [Larry]
ht: we would like it to be the case people can use Q and R with URIs that return 303 ...
13:09:36 [Larry]
noah: they can't use dc:creator
13:09:49 [Larry]
tbl: in the world
13:10:10 [Larry]
jar: noah asks the interesting question if ... XXX ...
13:10:25 [Larry]
noah: that's what i guess and i was mixing it with branding.
13:10:50 [Larry]
noah: dc:creator is what people ... XXX ... that may be an impediment to adoption
13:11:09 [Larry]
jar: we tried to get consensus on that [???] and failed
13:11:14 [Larry]
noah: think about it
13:11:20 [Larry]
jar: we have for 10 years
13:11:36 [Larry]
noah: in the future people will invent Q's and R's
13:11:59 [Larry]
tbl: dc:creator was used since ((long time))
13:12:10 [jar]
it's only a problem when you use dc:creator with a subject written as a disputed URI. all other cases (#) are fine
13:12:27 [Larry]
tbl: Facebook created OGP ontology, and started to stick something in their metadata
13:12:36 [Larry]
and did something
13:12:38 [jar]
it's been used *without transparency* - without any spec for what it means
13:13:07 [Larry]
tbl: ... we can keep going. if people get into namespaces, then instead of kicking
13:14:00 [Larry]
tbl: 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
13:14:21 [jar]
timbl is considering other parts of the context where the distinction could be drawn?
13:14:25 [Larry]
noah: their story gets better over time, in principle lllll
13:15:02 [Larry]
ht: if you're starting in a green field and you want to use disputed URIs, then ... all applies to the direct properties.
13:15:13 [Larry]
The URIs that you write in triples
13:15:45 [Larry]
ht: If i'm building an ontology in a greenfield, there are two classes about authoring ... i write a paragraph about what i care about
13:16:05 [Larry]
ht: I'm going to take about 30 yeaers ...
13:16:35 [Larry]
ht: i'm going to define a vocabulary that will use ... so I know .. i'll use compose... all those URIs will be in my namespace
13:16:56 [Larry]
ht: I want to encode so everyone can use them, so these all have to be parallel properties
13:17:18 [Larry]
ht: whenever i want to say about the properties ...
13:17:28 [Larry]
noah: is M one level or to the bottom
13:17:51 [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'.
13:17:54 [Larry]
noah: if i have a landing page that talks about another page ...
13:18:27 [Larry]
jar: ... the very last on the page
13:19:00 [Larry]
ht: my question is: can we use Q and R across the board, look at interoperability
13:19:35 [Larry]
ht: everyone will agree about how to write it and ...
13:19:46 [Larry]
ht: as it stands, we're still left ... hash URIs
13:20:02 [Larry]
ht: you should use the good old-fashioned direct properties.
13:20:38 [Larry]
ht: the rest of the document is about ... can we get tick boxes ... so that the right thing happens if you use write and use one of these so-called parallel properties
13:20:45 [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).
13:20:52 [jar]
The question at the end of the proposal27 page, is whether hash URIs interoperate with M- and N-properties.
13:21:03 [Larry]
ashok: if i have a hashless URI in my hand, how do I know if it is retrieval enabled
13:21:19 [Larry]
noah: and is that time-invarient
13:21:46 [Larry]
jar: the way i use the word, hashless URIs aren't ....
13:22:00 [Larry]
noah: are all hashless URIs retrieval enabled
13:22:22 [Larry]
ht: you can't tell if you'll get a 200 or a 303
13:23:04 [Larry]
jar: part of the continuation of this exercise.... i think larry's point that 303 and 200 shouldn't be treated separately ... legacy has ....
13:23:15 [Larry]
noah: so our solution is more advice?
13:23:41 [Larry]
ht: the story i told ... what does it mean if someone ...
13:24:05 [Larry]
ht: by a 303 URI, and the answer is, as far as we've gotten, it doesn't give the right answer
13:24:24 [Larry]
ashok: would it help if you said all hashless URIs are dsputed
13:25:13 [Larry]
ht: i don't think it would be useful to try to put something ...
13:25:32 [Larry]
ht: I think we need to switch...
13:25:39 [jar]
13:26:10 [jar]
Meaning of sound in unknown to me
13:26:25 [jar]
s/sound/the sound/
13:27:35 [Larry]
jar: reiterating, for the TAG, Jeni's document is important
13:28:02 [Larry]
jar: how does it apply more generally ... the central TAG documents, Jeni's ...
13:28:49 [Larry]
ht: doesn't answer the procedural answers. We asked for proposals, and set a practice. Jeni's document doesn't meet the requirements for a proposal, does it?
13:29:12 [Larry]
jar: basically, it asserts agreeing what disputed URIs identified....
13:29:31 [Larry]
... you just don't, and assume, RDF and Interoperability.
13:30:13 [Larry]
jar: all the proposals we received ... none of these things, there's a different way out, the key issue is technical interoperability, has priority over identificaiton.
13:31:04 [Larry]
ht: i'm not sure jeni's document as it stands encompases all that you said, some of it is in the background, some of that is ....
13:31:36 [Larry]
jar: there's more work to be done, how do you apply the something and data idea where you're forced something that you're something ...
13:31:56 [Larry]
ht: i had scrolled down as far as processing model of....
13:32:17 [Larry]
ht: Why does this work for Tim, who's a member of community 1...
13:32:42 [jar]
might want to look at at some point...
13:33:09 [Larry]
ht: how does it work if a member of communmity 2 passes something to someon e in community 1 ... it works because there are ... an implicit Q M ? P in the first box of the processing model
13:33:25 [jar]
Tim thinks Q = P
13:33:48 [Larry]
tbl: Ian is identity, N is identity?
13:33:58 [Larry]
ht: Q and R are never identity
13:34:09 [Larry]
tbl: for me, n is identity
13:34:17 [Larry]
13:34:23 [jar]
For timbl, M is identity. For Ian, N is identity.
13:34:27 [Larry]
ht: how can we get the same result
13:34:47 [Larry]
jar: at this point you'll hve different stories
13:35:13 [jar]
_:1 will be the same for Tim and Ian
13:35:28 [jar]
but for different reasons for the two
13:35:48 [Larry]
tbl: the problem is with the tabulator, it will pull in a landing page, and conclude that there is something
13:36:01 [Larry]
ht: it better have access this to that
13:36:23 [jar]
?p can be dc:creator
13:36:32 [Larry]
tbl: for some unnamed thing _1 for some unnamed thing P
13:36:57 [jar]
?p will usually be named, doesn't matter. In the example it is
13:37:51 [Larry]
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 tdb (subject owned). In your case, this is, F* is uh ... Q is ...
13:38:27 [jar]
To Tim, F* is the identity
13:38:30 [noah]
Time check 10 mins
13:38:50 [Larry]
tbl: i know there is something ....
13:39:01 [JeniT]
we use 'Tim' and 'Ian' as standins for perceived communities
13:39:07 [Larry]
ht: ian has to have written this, with a value for P
13:39:11 [jar]
These deduction rules work for everyone
13:39:35 [Larry]
tbl: the problem is Ian will create R and document R
13:40:11 [Larry]
jar: this only works for interoperable content
13:40:48 [Larry]
ht: it's the property P that is the author, somewhat oddly
13:41:02 [Larry]
when I write You R Dickens, what I care is that something is
13:41:48 [Larry]
... in the relationship P for...
13:41:55 [Larry]
Jeni: they all 303
13:42:07 [jar]
(We should ack that Ian is a stand-in for a point of view. We are not referring to him personally)
13:43:04 [Larry]
jar: if time is limited we need to talk. it just seems to me that Tim or whoever hasn't worked out the technical details
13:43:38 [Larry]
jar: I guess what i want is an admission ... the background sheets....
13:44:08 [Larry]
... we've something that, this has led to interoperability problems ...
13:44:19 [Larry]
... in the absence identification ...
13:44:31 [Larry]
... our claim that URI's identify ...
13:44:45 [Larry]
Noah: real problem getting enough community consensus
13:45:14 [Larry]
noah: sense of the room, who feels that this is.... i need to look hard ...
13:45:21 [jar]
13:45:27 [Larry]
noah: first choice ... 6 ...
13:45:41 [Larry]
ashok: I want to think about it a bit
13:45:53 [Larry]
noah: it would be nice to come out of here with a direction
13:46:38 [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.
13:46:40 [Larry]
noah: first is let's assume for the moment that this is ... change propopsals and synthesize
13:47:24 [Larry]
stuart: will this require me to change anything
13:47:33 [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.
13:48:01 [Larry]
Jeni: 303 is OK
13:48:15 [Larry]
noah: if you were to come across shorthand properties ... not proven
13:48:17 [timbl]
There is an interesting subclass of InformationResource which is a domain of principalTopic : Document which has a single principle topic.
13:48:27 [ht]
HST's take on what JAR said was his proposed resolution of the RFP exercise is: "The effect of 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."
13:48:35 [jar]
I think 303 is fine for RDF, but agree with reservations on whether it works for the architecture overall.
13:48:37 [Larry]
stuart: this will be hard ....
13:48:54 [Larry]
tbl: worry we're build more crud on top of crud
13:49:10 [ht]
s/effect of our call/outcome of our review of the responses to our call/
13:49:14 [jar]
No, we're removing crud from existing crud.
13:49:24 [Larry]
timbl: it's better than that because ...
13:49:49 [Larry]
timbl: a movement to outflank the whole issue ... talking about the subject of the thing to the thing itself
13:50:41 [jar]
HT's wording is consistent with, and better than, mine.
13:50:50 [Larry]
ht: because the net net is to say ... i tried to capture Jonathan ... the coutcome to our review .. was to underscore what URIs globally and ambiguously identify, and we're going to stop trying
13:51:16 [Larry]
ht: instead we'll provide some technical advice for some interoperabilitie problems
13:51:25 [jar]
Amend: hashless http: URIs
13:51:26 [noah]
13:51:30 [Larry]
13:51:36 [noah]
13:52:00 [Larry]
ashok: when I'm starting, I have a URI, we have to ...
13:52:00 [timbl]
timbl: It is good to prepare also a way of making this unnecessary by allowing in HTML and maybe even hurt;le 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.
13:52:18 [Larry]
ht: all you have to do is faithfully realize in your processors your communities
13:52:28 [noah]
Did you mean hurt;/e ==> turtle?
13:52:42 [Larry]
ht: the crucial thing is that you don't need to know where things come from, just trust that M and N
13:52:55 [Larry]
M and N are going to become concrete, you know what the data ....
13:52:56 [timbl]
13:53:06 [Larry]
all you need to do is trust htings with M's and N's
13:53:20 [noah]
...and the bad news is that the scribing script will probably trip over that ;
13:54:02 [Larry]
ht: when i find hashsless URIs... Ora ... talk about a lot... we have a certain amount of provinence information, it will be easy for you to say that i've learned that triples from this source
13:54:19 [timbl]
We found people wouldn't mind their Ps and Qs and just hope they like M&Ns.
13:54:26 [noah]
ack next
13:55:15 [noah]
LM: A substantial part of the community is trying to push us toward operational defitions of URI/URL, etc.
13:56:02 [ht]
s/from this source/from this source uses a) retrieval-enabled hashless URIs, i.e. 'disputed' URIs and b) does not document them using M and N, so I'm not going to trust or use triple from it/
13:56:04 [noah]
LM: These things are recipes, grounded in <a @href>, somewhat modified in <img @src>. You don't need RFC 3986. You just agree a set of processing steps.
13:56:20 [noah]
LM: It's a big chunk of the community, and they look to the TAG for leadership.
13:57:21 [noah]
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.
13:57:33 [noah]
LM: I like the first part of the proposed resolution.
13:58:16 [noah]
LM: I'll agree that the efforts to agree on interop of hashless URIs have failed. OK. Then the suggestion to pursue Jeni's solution. Not here. We have higher priorities.
13:59:14 [noah]
LM: I'm not sure we need to go to this level. Besides, the diagrams in the charts are confusing, and perhaps imply that things are identified which in fact are not.
13:59:56 [noah]
TBL: We have some code that works, but some that screws up.
14:00:15 [noah]
LM: I have code that talks about authors, etc. It works fine without all this. Flickr is not looking for us to do this.
14:00:31 [jar]
the code *doesn't* work fine. they *are* looking to us. maybe it's not our job and we should refer them elsewhere.
14:00:47 [noah]
HT: Sorry, they don't interop. That may be OK with them, but they don't interop.
14:00:52 [noah]
ack next
14:01:32 [Larry]
14:01:42 [jar]
We need to say AWWW may be right as a matter of principle, and false as a matter of fact.
14:01:45 [ht]
NM: I am sympathetic to a lot of what LM says
14:01:58 [Larry]
i think the architecture of URLs is important, but the mass of the community that needs work on URLs don't need THIS work
14:02:30 [ht]
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
14:02:34 [Larry]
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
14:02:50 [jar]
I am completely sympathetic with LM. I think the conclusion is correct, even if its justification is wrong on some of the facts.
14:02:50 [ht]
NM: Why is it any more likely now than a year ago that we are converging
14:04:16 [DKA]
DKA has joined #tagmem
14:04:16 [ht]
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
14:04:50 [ht]
TBL: I don't think that much of that will change
14:04:51 [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.
14:05:05 [jar]
AWWW advice is not operational. Doesn't tell anyone how to coordinate.
14:05:24 [ht]
s/our new take/our new take. There was real value in that advice, and we shouldn't throw it away/
14:05:45 [jar]
There's a serious mistake in AWWW. That should be fixed.
14:05:54 [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.
14:05:59 [noah]
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.
14:06:33 [ht]
TBL: I'd like to see something discussing 303 wrt this proposal
14:06:55 [ht]
... Not everyone has to read it, but it needs to be done
14:07:00 [JeniT]
14:07:48 [ht]
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
14:08:00 [Larry]
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.
14:08:43 [ht]
NM: Stipulate that's all true, TBL, if we're not ever going to converge we have to agree to stop at some point
14:09:40 [ht]
LM: We convened a task force on XML-HTML unification, and we concluded to allow HTML to go ahead w/o XML
14:10:07 [ht]
... This isn't the end of XML, but it's implicitly no longer on the main strategic Web path going forward
14:10:08 [noah]
ack next
14:10:35 [ht]
LM: Why can't we do that for URLs?
14:11:05 [Larry]
why don't we accept that resolving this problem isn't central to web architecture
14:11:37 [noah]
JT: To wrap this, we need to go to the community, discuss background, tell the story about limits on agreeing on what URIs identify.
14:11:55 [noah]
JT: I think we should pursue the primer document and take it to conclusion
14:12:13 [noah]
JT: The stuff around what RDF itself does is the responsibility of the RDF working group.
14:12:45 [noah]
JT: The primer is therefore something we can give to the RDF least to indicate what needs to be sorted out
14:13:11 [noah]
HT: Noah completely mis-scribed that
14:13:29 [Larry]
jt: the work JAR has done should be given to the RDF community
14:13:40 [Larry]
jt: that would be my "getting out of it" strategy
14:13:52 [ht]
JT: The primer makes clear that specs in general, therefore RDF in particular, must take responsibility for requiring URI documentation
14:14:02 [Larry]
noah: is this something we could be done with the primer in 6 months
14:14:23 [ht]
JT: And then the more detailed work on proposal 27 goes to the RDF community as our contribution to elping them do that job
14:14:34 [ht]
14:14:53 [Larry]
Jeni: I think the RDF community will need some guidance
14:16:14 [Larry]
jar: the important thing is coordination of URIs in documents ... if you're documenting something, you have to say what you mean
14:17:17 [Larry]
jar: It sounds like we're getting closer to being on the same page
14:17:44 [noah]
jar: if you want to get communication, you need agreement on <context>?
14:17:46 [Larry]
jar: the main architectural issue is that you have to agree on meaning, not specifying... you need transparency
14:17:47 [Larry]
14:17:54 [JeniT]
14:17:59 [noah]
ack next
14:18:00 [noah]
ack next
14:18:25 [noah]
LM: There's more ambiguity than use/mention. It's do you mean it now vs. forever. Do you mean just the HTML or the transcluded content. etc.
14:19:05 [jar]
registries and specs are how you get transparency. that hasn't been achieved in rdf. we need to admit that.
14:19:05 [Larry]
14:20:07 [Larry]
jeni: proposal is to go back to the community with the argument made in the background sectionk, 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
14:20:16 [jar]
. go back to comty with the argument in background page. to pursue pub of primer (URIs in data as rec). to hand rdf off to rdf wg.
14:20:25 [noah]
JT: Proposal: 1) go back to community with perspectiv in background section 2) publish primer as a rec in 6 month 3) move responsibility for RDF bits to RDF WG
14:20:33 [Larry]
Noah: except for my concern about the arch document
14:20:54 [Larry]
ashok: have we had any feedback in the community?
14:20:57 [jar]
Arch doc is wrong or at least fatefully incomplete, and "should" be amended. that's separate
14:21:02 [Larry]
JEni: generally, it's ok
14:21:17 [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.
14:21:18 [timbl]
14:21:45 [Larry]
ht: my guess is that the people paying attention... no one left standing wants to win, people just don't want to lose
14:21:58 [noah]
ack next
14:22:59 [Larry]
timbl: I'm worried about going into the RDF working group. it's taken a long time for the three people to come to a working situation, even being on the tag... I think the danger when it hits the RDF working group, there's a tendency to go off into philosophical tangents
14:23:02 [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.
14:24:10 [Larry]
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 form and rdf examples
14:24:35 [Larry]
jeni mentioned that the primer would turn into a rec. would it make sense ....
14:27:15 [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.)
14:27:48 [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 intension to transition to RDF WG, all by April 1 2013
14:27:49 [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
14:28:38 [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 intension to transition to RDF WG, all by April 1 2013
14:29:09 [ht]
JAR, not sure what you mean by "application of RDF to the web" ?
14:29:42 [jar]
ht, I think I'll have to explain that later.
14:29:56 [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 intension to transition to RDF WG, all by April 1 2013
14:30:13 [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 intension to transition to RDF WG, all by April 1 2013
14:30:23 [noah]
Agreed without dissent
14:30:42 [Larry]
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 intension to transition to RDF WG, all by April 1 2013
14:30:42 [Larry]
14:31:19 [Larry]
. ACTION: Larry & others to request time at RDF working group to discuss
14:33:12 [jar]
I was muted
14:53:09 [DKA]
DKA has joined #tagmem
15:01:27 [Ashok]
rrsagent, pointer?
15:01:27 [RRSAgent]
15:03:17 [Larry]
topic: TPAC
15:04:40 [Larry]
Noah: asked for room Monday morning & Friday afternoon
15:04:56 [Larry]
Noah: TAG members will probably meet? No formal TAG meeting
15:05:18 [Larry]
Larry, Peter, Ashok, Henry, Tim, Jenni (Only plenary day)
15:06:03 [Larry]
noah: couple of weeks ago, note from Jeff about joint meeting with TAG at TPAC, roughly half the tag, explore options
15:06:35 [Larry]
noah: does anyone wants to say about their plans
15:07:22 [Larry]
4 positions up for election, including Robin's
15:08:30 [Larry]
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
15:08:47 [Larry]
Jeni: Robin suggests lightning talks
15:08:47 [jar]
ACTION jar with help from HT and JT to draft the TAG's response to the ISSUE-57 change proposal
15:08:48 [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].
15:08:48 [jar]
process initiated on 29 February 2012, based on
15:08:49 [jar] and F2F minutes
15:08:50 [jar]
of 8 October 2012.
15:08:56 [jar]
15:08:59 [jar]
15:09:14 [jar]
editing action
15:09:21 [Larry]
jeni: 5-minute lightning talk, this is what we're working on, these are the positions that are available
15:09:35 [Larry]
noah: normally been my custom make sure we have a status report
15:10:10 [Larry]
noah: quarterly is too frequently, i've been working on the product pages, when you give the lightning talk, tell people the web page
15:10:23 [Larry]
larry: ...
15:11:37 [Larry]
larry: two communities ... members, public. lightning talk on election
15:12:36 [Larry]
ht: doing lightning talk is excellent idea, pointless to ask for 15 minutes
15:13:26 [Larry]
jeni: half-day AC on tuesday, half-day on thursday
15:14:04 [Larry]
"Getting more security/network protocol/IETF experience on the TAG would also be helpful. Know any other candidates?"
15:16:05 [DKA]
DKA has joined #tagmem
15:16:28 [Larry]
15:17:57 [ht]
"The TPAC2012-Committee is planning the day"
15:18:07 [ht]
15:18:48 [Larry]
1) promote past work & dashboard 2) recruit volunteers 3) get feedback on documents 4)
15:18:53 [Yves]
15:19:20 [noah]
4) hilite as "Dashboard" to track what TAG is doing and has done
15:19:23 [ht]
HST wants to show 3 slides: Publishing and Linking; Frag-ids; Participate, review, stand for the c'ttee
15:19:25 [Larry]
4) solicit ideas for topics to take up
15:19:44 [Larry]
15:20:36 [Yves]
15:21:00 [DKA_]
DKA_ has joined #tagmem
15:21:30 [noah]
ACTION: Noah to contact Ian about TAG participation in TPAC -- see minutes of 8 Oct late afternoon
15:21:30 [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].
15:22:44 [noah]
Convey sense that 5 mins might be right on general TAG issues
15:23:47 [noah]
JT: 5 mins at plenary for everyone (Jeni) 5 mins AC (Henry or Larry)
15:26:33 [Larry]
topic: List for Jeff (ACTION-563)
15:26:34 [noah]
15:26:34 [trackbot]
ACTION-563 -- Noah Mendelsohn to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F -- due 2012-11-01 -- OPEN
15:26:34 [trackbot]
15:27:23 [Larry]
noah: background on tracking high priority items for Jeff
15:27:39 [ht]
ACTION: Henry with help from JAR and JT to produce a publishable version of Issue57Proposal27 (, due 2012-12-31
15:27:39 [trackbot]
Created ACTION-751 - With help from JAR and JT to produce a publishable version of Issue57Proposal27 (, due 2012-12-31 [on Henry Thompson - due 2012-10-15].
15:27:55 [ht]
trackbot, action-571 due 2012-12-31
15:27:55 [trackbot]
ACTION-571 Write up comments on microdata and RDFa due date now 2012-12-31
15:28:03 [Larry]
emphasis on things Jeff wouldn't have noticed otherwise
15:28:19 [ht]
trackbot, action-751 due 2012-12-31
15:28:19 [trackbot]
ACTION-751 With help from JAR and JT to produce a publishable version of Issue57Proposal27 (, due 2012-12-31 due date now 2012-12-31
15:28:28 [Larry]
jeni: http 2.0 stuff
15:28:36 [Larry]
noah: what's the issue?
15:29:02 [jar]
q+ jar to ask is 'TAG effectiveness' something to raise with Jeff?
15:29:36 [Larry]
larry: candidate to including working on web performance, benchmarking, HTTP performance
15:30:15 [Larry]
tbl: 3986 forking, URLs, registerProtocolHandler
15:30:50 [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.
15:31:00 [noah]
ack nex
15:31:05 [noah]
ack next
15:31:06 [Zakim]
jar, you wanted to ask is 'TAG effectiveness' something to raise with Jeff?
15:31:23 [Larry]
larry: not worth teasing out all the related issues of URL issues
15:32:04 [Larry]
noah: JEff's mainly on technical issues
15:32:56 [noah]
LM: Red flag for me: I want to seminar on security...seems to me Web security is in crisis. Exponential growth in attacks, outpacing expertise to address.
15:33:38 [noah]
15:36:26 [Larry]
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
15:36:40 [Larry]
ht: there's nobody looking at security at the highest level
15:37:09 [jar]
15:37:19 [Larry]
ht: his colleague was saying "black web" and "white web", one is "credit cards are known", vs. people who can be billed
15:37:39 [jar]
It was Butler Lampson, and the colors were "red" and "green"
15:38:16 [ht]
Well, on the day it was zuwei, wasn't it?
15:38:24 [ht]
I guess he credited Butler
15:38:51 [jar]
zewei chen (of Akamai)
15:39:19 [noah]
LM: I see security reviews getting lost between IETF and W3C. Attacks cross abstraction boundaries.
15:40:56 [noah]
TBL: makes a least power argument that it's hard to prove properties of URIs if the specifications for URIs are procedural
15:41:05 [noah]
15:41:14 [Larry]
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
15:41:33 [Larry]
tbl: talking about "language of least power"
15:42:37 [Larry]
noah: also there are stuff you would tend to design during the design phase
15:43:02 [Larry]
noah: also things we thought were secure aren't falling apart
15:43:29 [noah]
NM: are we organized to respond to threats, whether in new specs or not.
15:44:12 [noah]
LM: performance is multi-level.
15:44:24 [ht]
For Lampson on red and green webs, see
15:44:44 [noah]
Great paper on layering and performance:
15:45:36 [noah]
LM: Speculating on cloud stuff...ashok?
15:46:21 [Larry]
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
15:46:36 [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.
15:47:37 [Larry]
noah: share hosting, someone running on the same machine -- one little leak, someone reinstalls your whole environment
15:48:56 [noah]
15:48:56 [trackbot]
ACTION-563 -- Noah Mendelsohn to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F -- due 2012-11-01 -- OPEN
15:48:56 [trackbot]
15:49:53 [JeniT]
ACTION: Jeni to update URIs in data primer based on discussion at Tuesday F2F
15:49:53 [trackbot]
Created ACTION-752 - Update URIs in data primer based on discussion at Tuesday F2F [on Jeni Tennison - due 2012-10-15].
15:50:09 [noah]
ACTION: Larry to do first draft of technical issues list for Jeff - Due 2012-10-22
15:50:09 [trackbot]
Created ACTION-753 - do first draft of technical issues list for Jeff [on Larry Masinter - due 2012-10-22].
15:52:30 [Ashok]
rrsagent, make logs public
15:53:27 [Ashok]
Butler Lampson's slides --- slide 16 Noites
15:53:43 [Ashok]
15:56:00 [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
15:56:01 [timbl]
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
15:56:02 [timbl]
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.""" .
15:56:21 [timbl]
-- Butler Lapson Op.cit.
15:57:52 [jar]
think: two computers connected via IP (NOT IPC or shared memory)
15:58:07 [jar]
15:59:00 [noah]
Time check - 3 mins
15:59:45 [timbl]
16:00:17 [jar]
(hmm, maybe got that s/// wrong.)
16:00:56 [Larry]
16:03:34 [Larry]
adjourned for day
16:03:45 [Ashok]
rrsagent, pointer?
16:03:45 [RRSAgent]
17:59:14 [Zakim]
Zakim has left #tagmem