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

13:54:07 [ht]

jt: No modification, the same algorithm

13:54:30 [ht]

tbl: But that only gives you relations between documents, I want the relations between the things

13:55:12 [ht]

tbl: Is the squares+circles diagram in your example an RDF graph

13:55:28 [ht]

s/graph/graph?/

13:55:28 [Ashok]

JT: No same algorithm

13:58:18 [Ashok]

Tim: How do I change my code

13:58:31 [Ashok]

jar: You don't need to change your code

13:59:02 [Ashok]

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

13:59:06 [Ashok]

jar: No

14:01:48 [Ashok]

NM: This assumes references exist in a media type context

14:02:11 [Ashok]

... is this correct?

14:02:28 [Ashok]

... is there a solution where that is not the case

14:02:43 [Ashok]

JT: No changes to how the Web works today

14:05:13 [ht]

NM: [about context in the story]

14:06:38 [ht]

HST: Coming back also to TBL's question: The examples we had in mind, which are the easier ones to understand, are 1) message is text/html, with URI in context <a href="...", and 2) message is application/n3, context is <...> a Person. Other contexts can be managed, but the story is more complicated

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

14:30:29 [Zakim]

TAG_f2f()8:00AM has now started

14:30:30 [Zakim]

+Yves

14:31:53 [Ashok]

JT: The media-type tells you how to interpret the URI

14:32:08 [Zakim]

+ +1.617.715.aaaa

14:32:11 [Ashok]

... just pure JSON does not

14:32:49 [noah]

ack next

14:32:50 [Zakim]

timbl, you wanted to say that data things do care about the document it came from in 2 cases 1) trust from provenance and 2) error siuations

14:33:08 [Ashok]

JT: For example JSON-LD provides the context

14:33:53 [jar]

timbl: Need to localize source of error

14:34:06 [Ashok]

... also for provenannce

14:34:15 [timbl]

ack a

14:34:20 [timbl]

ack b

14:34:20 [Zakim]

bob, you wanted to say that when the URI is used in JSON say, there is no commitment to the RDF model and so limited damage

14:34:48 [Ashok]

(Tim will provide URI to slides later)

14:35:22 [Ashok]

Tim: RDF does not have to define what JSON means

14:38:01 [timbl]

ack c

14:38:01 [Zakim]

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

14:44:06 [Ashok]

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

14:45:16 [darobin]

darobin has joined #tagmem

14:48:17 [Ashok]

jar: Some vocabulary to help people think more rigorously is a good thing

14:50:48 [Ashok]

... you get consistenct through model theory

14:51:11 [Ashok]

s/consistenct/consistency/

14:51:20 [noah]

q?

14:52:23 [noah]

q+ noah2 to make a concrete proposal on documenting this

14:52:53 [timbl]

ack d

14:52:54 [Zakim]

dick, you wanted to say this ismaybe RDF-ER

14:53:07 [Ashok]

Charlie has been uses "identifies" for a long time

14:54:10 [Ashok]

Dick is worrying whether this is RDF E-R

14:54:57 [Ashok]

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

14:55:34 [Ashok]

Tim: So, tabulator has to do some up-front forward chaining on these properties

14:56:42 [Ashok]

... I can hang an event handler that alerts me when I have a parallel property and I can then do some forward chaining on it

14:57:03 [timbl]

ack e

14:57:03 [Zakim]

egbert, you wanted to say that the "correspondsTo " matches foaf:primarySubject

14:57:14 [timbl]

q?

14:58:02 [jar]

timbl: So, what tabulator does, is that if it sees that a property is a "parallel" property, it can do some forward chaining via the implied property chain.

14:58:06 [jar]

jar: yes

14:58:24 [JeniT]

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

14:58:31 [jar]

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

14:59:07 [jar]

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

14:59:08 [jar]

jar: yes

15:01:06 [timbl]

SO in practice, in tabulator, I can hang an event handler on a new statment { ?p a ParallelProperty } and when I get that i can hang an event handler on any new statement of the form { ?s PP ?o } for the given PP, and then from that I can then add the deduced from the primary topics of ?s and ?o, and so there will, thorgh smshing, end up with a reasonable graph about s' and o' , although alas much flotsam and jetsam from the arcs which were used to generate it,

15:01:06 [timbl]

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

15:01:16 [jar]

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

15:01:21 [jar]

jt: Let's talk about that later

15:01:52 [timbl]

s/primarySubject/primaryTopic/

15:01:58 [timbl]

ack next

15:02:05 [timbl]

q?

15:02:07 [Zakim]

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

15:02:13 [jar]

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

15:02:14 [JeniT]

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

15:02:50 [Ashok]

q+

15:03:56 [Ashok]

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

15:04:03 [ht]

hst: +1 to avoiding "primary topic"

15:05:01 [ht]

I suspect that "smshing" is what I think of as unification

15:05:19 [jar]

q?

15:06:35 [Ashok]

NM: You said media type was important ... I came away with the feeling that may not be so important

15:06:48 [Ashok]

... what do you JT think is the role of the media type

15:07:39 [Ashok]

JT: Mapping from message to a knowledge represenation. If that has links to documents, can we make inferences and add some extra nodes

15:08:18 [Ashok]

... how you interpret depends on media type of the message

15:09:51 [Ashok]

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

15:10:18 [Ashok]

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

15:12:01 [Ashok]

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

15:14:56 [Ashok]

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

15:15:17 [Ashok]

s/monotic/monotonic/

15:16:10 [jar]

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

15:16:19 [Ashok]

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

15:17:27 [Ashok]

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

15:17:32 [Ashok]

Jar: Agree

15:17:49 [noah]

q?

15:17:54 [noah]

ack next

15:17:55 [Zakim]

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

15:18:15 [jar]

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

15:18:30 [Ashok]

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

15:19:45 [Ashok]

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

15:20:01 [Ashok]

JT: We getting to the procedural part

15:20:28 [Ashok]

q-

15:21:24 [Ashok]

s/explian/explain/

15:22:16 [jar]

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

15:23:02 [Ashok]

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

15:23:36 [jar]

jar: Two questions re rdf:type, whether the type's URI is interpreted (in the model theory) as a document or as a class, and whether the type is a type of documents or a type of things documents are about

While Web architecture allows the definition of new schemes, introducing a new scheme is costly. Many aspects of URI processing are scheme-dependent, and a large amount of deployed software already processes URIs of well-known schemes. Introducing a new URI scheme requires the development and deployment not only of client software to handle the scheme, but also of ancillary agents such as gateways, proxies, and caches. See [RFC2718] for other considerations

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

19:20:57 [noah]

PL: They don't know or care.

19:21:06 [noah]

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

19:21:11 [noah]

PL: Not sure.

19:22:09 [noah]

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

19:22:17 [noah]

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

19:22:44 [noah]

q?

19:23:45 [JeniT]

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

19:24:10 [JeniT]

noah: we can sometimes go and shed a light on an architectural area in a WG, and that's welcomed

19:24:26 [JeniT]

... sometimes we try to stop WGs from doing things that have long-term negative impacts

19:24:40 [JeniT]

... if we go "here we are" many groups will say "are they gone yet?"

19:25:00 [Ashok]

Ashok has joined #tagmem

19:25:05 [JeniT]

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

19:25:31 [JeniT]

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

19:25:42 [JeniT]

timbl: I think it will vary by group

19:26:16 [jar]

q?

19:26:29 [Ashok]

Ashok has joined #tagmem

19:26:29 [JeniT]

... suppose we use the chairs list?

19:26:44 [JeniT]

... ask someone to nominate an architecture dude within a group

19:26:59 [JeniT]

... someone who could answer the question, who we could talk to

19:27:14 [JeniT]

ht: having been in the XML Core WG as well as the TAG has been a real help

19:28:02 [JeniT]

... a lot of WGs will just be silent

19:28:34 [JeniT]

... a few will say go away

19:28:43 [JeniT]

... and some will say, here's someone who will do it

19:29:02 [JeniT]

noah: what if they're cheerful volunteers, who will take up our time?

19:29:18 [JeniT]

... this has worked best when TAG members read WG specs in detail

19:29:49 [JeniT]

... the risk is that the person understands their specs, but doesn't know about architecture

19:30:19 [JeniT]

plinss: if they send someone who doesn't get webarch, we should take that as a educational opportunity

19:30:36 [JeniT]

... it would help us disseminate the TAG's message

19:30:47 [JeniT]

noah: if we get a lot of people then we're in trouble

19:31:08 [JeniT]

... if I have 20 people calling me, it takes me a long time

19:31:17 [JeniT]

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

19:31:40 [JeniT]

timbl: could we have WGs allocated to TAG members?

19:31:56 [JeniT]

ht: there are a lot of them

19:32:11 [JeniT]

jar: what about a list of the problems to which an architecture would be a solution

19:32:15 [JeniT]

... like registry design

19:32:29 [JeniT]

... instead of coming up with an answer, maybe we list a bunch of the problems

19:32:49 [JeniT]

... ask them if they have one of these architectural problems, and then say we want to talk to them

19:32:59 [JeniT]

noah: sounds like something we can engage the WG chairs with

19:33:14 [JeniT]

... I'm not sure we could characterise them

19:33:30 [JeniT]

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

19:33:58 [jar]

I asked whether we talked about anything else

19:34:24 [JeniT]

noah: maybe we can craft a message to the chairs, to say that they should be watching for these things

19:34:46 [JeniT]

... perhaps part of the Rec approval process is that they check off against that list

19:36:10 [JeniT]

jar: I've been thinking about this for a long time

19:36:17 [JeniT]

... there's a big distance between TAG and WGs

19:36:32 [JeniT]

... if the TAG had unlimited manpower, we'd review every spec through the process

19:36:38 [JeniT]

... as early as we could

19:36:41 [JeniT]

... but that's impossible

19:36:51 [JeniT]

... so is there a sweet spot?

19:37:04 [JeniT]

... if we say that there are particular things we'd review for

19:37:23 [JeniT]

... the WGs won't bring it to us, and they might not recognise that the problem is an architectural issue

19:37:45 [JeniT]

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

19:38:06 [JeniT]

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

19:38:17 [JeniT]

noah: perhaps this relates to improving education outreach

19:38:52 [JeniT]

... we'll tell them they should be thinking about X, and they might not understand what that is

19:39:11 [JeniT]

... if we put out more material to educate them, maybe it will help them recognise arch issues

19:39:34 [JeniT]

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

19:39:46 [JeniT]

... we have to show that we're learning

19:40:06 [JeniT]

noah: for some findings, there'll be a draft and the community will push back on it

19:40:15 [JeniT]

... that's always good, but it's hard to get that

19:44:08 [JeniT]

noah: what should we do with this?

19:44:39 [JeniT]

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

19:44:55 [JeniT]

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

19:46:55 [JeniT]

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

19:47:09 [JeniT]

... maybe new, maybe old

19:47:20 [JeniT]

noah: we used to have 20 minutes every TPAC

19:47:31 [JeniT]

... that died when the standard presentations went from TPAC

19:47:40 [JeniT]

ht: the standing slot was at the AC meeting

19:47:54 [JeniT]

... and they correctly decided to stop having the standard items

19:48:05 [JeniT]

plinss: that sounds more like TAG status report

19:48:21 [JeniT]

noah: in some cases that was quite technical

19:48:39 [JeniT]

timbl: in early days we were playing catch up, writing up what people knew

19:48:52 [JeniT]

... nowadays the W3C is covering a lot more ground

19:49:14 [JeniT]

... I think the attitude of the TAG should be to ask for input of what people think

19:49:24 [JeniT]

... ask if people have arch issues that they want to flag

19:49:25 [jar]

+1

19:49:30 [JeniT]

+1 !

19:49:42 [JeniT]

noah: what at TPAC?

19:49:43 [jar]

ask what the TAG can learn from what WGs are doing

19:49:50 [JeniT]

timbl: use TPAC to feed them back

19:49:57 [JeniT]

... trying to highlight stuff that's new

19:50:59 [JeniT]

ht: pilot with WGs but go out to CGs

19:51:08 [JeniT]

noah: scaling to that number of people is difficult

19:51:22 [JeniT]

jar: would it help to think of our role as a cross-bar

19:51:37 [JeniT]

... there's all this experience accummulating all over the place

19:51:45 [JeniT]

noah: but that doesn't scale

19:51:55 [JeniT]

jar: I know, that's what we're working on, how to do this economically

19:52:38 [JeniT]

... if the role of the TAG is phrased in a good appealing way, it invites engagement

19:53:21 [JeniT]

ht: what about if instead of spending 15 minutes at the end of each TAG call looking at overdue actions, we spent that time looking at the mail coming in from our correspondents

19:53:28 [JeniT]

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

19:53:45 [JeniT]

ht: this is in the context of the architectural dudes

19:53:56 [JeniT]

... say we'll look at mail at each meeting

19:54:01 [JeniT]

... and we will get back to you

19:54:16 [JeniT]

... one of the responses is that there's another group talking about the same thing

19:54:28 [JeniT]

noah: I get very nervous about logistics

19:54:35 [JeniT]

... about making promises we can't keep

19:54:43 [JeniT]

... how we relate this to our charter

19:55:01 [JeniT]

... our charter has a top-down feel, about documenting for the community principles of web architecture

19:55:17 [JeniT]

... where we can be collegial, fine, but we're not set up as a coordinating body

19:55:20 [JeniT]

ht: yes we were

19:55:55 [JeniT]

jar: we're having a trouble developing web architecture

19:56:07 [JeniT]

... we have to learn, and enlist the help of other people to learn what has to be said

19:56:15 [JeniT]

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

19:56:28 [JeniT]

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

19:56:41 [JeniT]

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

19:56:57 [JeniT]

jar: another way to think of it is to say that webarch is a hypothesis and we're trying to test it

19:57:17 [JeniT]

... if the data shows the architecture is wrong, then we need to correct it

19:57:25 [JeniT]

... set expectations, say that's what we want to do

19:57:40 [JeniT]

... they feel there's a purpose to the interaction

19:57:58 [JeniT]

noah: how would we do that?

19:58:31 [JeniT]

plinss: we reach out to the groups to say that we're here to help

19:58:48 [JeniT]

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

19:59:01 [JeniT]

jar: one way to frame it is as a study, as a test of the hypothesis

19:59:08 [JeniT]

... we have to plan how we're going to gather the data

19:59:15 [plinss]

s/we're here to help/we need your help building web arch/

19:59:23 [JeniT]

... someone needs to draft the study plan

19:59:30 [JeniT]

noah: right, and doing that would be helpful

20:00:31 [JeniT]

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

20:00:35 [JeniT]

... which is hard work

20:00:39 [JeniT]

ht: you know, you don't

20:01:00 [jar]

application directorate reviewer list at ietf

20:01:08 [JeniT]

... my experience on the AppsDR reviewer list

20:01:15 [JeniT]

... once a quarter I get an RFC to review

20:01:26 [JeniT]

... that's a lot of work, I get asked to review stuff involving XML

20:01:36 [JeniT]

... but everyone watches everything that goes by

20:01:47 [JeniT]

... I cherry-pick, skim these things

20:01:56 [JeniT]

... like the acct: example, it's not that hard

20:02:04 [JeniT]

... if your goal is not participate, but to keep an eye open

20:02:14 [JeniT]

... you don't miss everything

20:02:21 [JeniT]

... it doesn't take an enormous amount of time

20:02:33 [JeniT]

jar: I'm suggesting something easier than a review

20:02:41 [JeniT]

... if we can list our five concerns, and only look for those things

20:03:07 [JeniT]

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

20:03:36 [JeniT]

jenit: we need someone to do a draft study plan

20:03:50 [JeniT]

noah: I'd like some people to be owners of all this discussion

20:04:15 [JeniT]

... to summarise it, come back with ideas, or help us assess these concerns

20:04:25 [JeniT]

... then when there's a specific proposal like the one that jar's made

20:04:36 [JeniT]

... then identify what can be done to help the TAG make the decision

20:04:48 [JeniT]

... I'm open to pursuing all that

20:05:09 [JeniT]

... I don't want to do all that, and drop everything aside from that

20:07:10 [noah]

jenit: I am glad to do the next step in trying to gather what we've learned from the overall analysis of opportunities to improve TAG effectiveness

20:09:21 [JeniT]

ACTION: Jeni, with help from Peter, to create big picture overview coming out of analysis of TAG effectiveness

20:09:21 [trackbot]

Sorry, couldn't find user - Jeni,

20:09:36 [JeniT]

ACTION: Jeni with help from Peter, to create big picture overview coming out of analysis of TAG effectiveness

20:09:36 [trackbot]

Created ACTION-725 - With help from Peter, to create big picture overview coming out of analysis of TAG effectiveness [on Jeni Tennison - due 2012-06-21].

20:10:47 [JeniT]

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

20:11:02 [JeniT]

noah: this might be a big time sink

20:11:15 [JeniT]

... getting consensus might not be easy

20:11:36 [JeniT]

... it could cover versioning etc

20:11:59 [JeniT]

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

20:12:04 [JeniT]

noah: also include accepted Findings

20:12:17 [JeniT]

... more recent statement of what the TAG thinks we should be worrying about

20:12:35 [JeniT]

jar: yes, I will

20:13:06 [jar]

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

20:14:41 [jar]

. ACTION jar to make a list of questions to which webarch and the findings suggest answers to, as input to possible 'study design' and/or communication to chairs etc.

20:17:31 [JeniT]

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

20:17:36 [jar]

ACTION jar to make a list of questions to which webarch and the findings suggest answers to, as input to possible 'study design' and/or communication to chairs etc.

20:17:36 [trackbot]

Created ACTION-726 - Make a list of questions to which webarch and the findings suggest answers to, as input to possible 'study design' and/or communication to chairs etc. [on Jonathan Rees - due 2012-06-21].