Chatlog 2012-06-22

See original RRSAgent log or preview nicely formatted version.

Please justify/explain all edits to this page, in your "edit summary" text.

15:32:57 <RRSAgent> RRSAgent has joined #prov
15:32:58 <RRSAgent> logging to http://www.w3.org/2012/06/22-prov-irc
15:32:59 <trackbot> RRSAgent, make logs world
15:33:00 <Zakim> Zakim has joined #prov
15:33:01 <trackbot> Zakim, this will be 
15:33:01 <Zakim> I don't understand 'this will be', trackbot
15:33:02 <trackbot> Meeting: Provenance Working Group Face-to-Face
15:33:03 <trackbot> Date: 22 June 2012
15:33:11 <Luc> Zakim, this will be PROV 
15:33:11 <Zakim> ok, Luc; I see SW_(PROV)12:00PM scheduled to start in 27 minutes
15:34:39 <Luc> Agenda: http://www.w3.org/2011/prov/wiki/F2F3Schedule
15:35:08 <Luc> Chair: Paul Groth
15:42:11 <Curt> Curt has joined #prov
15:43:00 <pgroth> pgroth has joined #prov
15:43:15 <pgroth> is anyone on the telecon yet?
15:43:50 <dgarijo> I tried, but it said that it is restricted at this time
15:43:55 <pgroth> ok
15:44:52 <GK> GK has joined #prov
15:45:56 <GK> I'm not sure much of tghe meeting I'll be able to follow...  I hadn't fully appreciated the time difference when I said I'd try to join in today.
15:48:33 <Zakim> SW_(PROV)12:00PM has now started
15:48:40 <Zakim> +??P0
15:48:45 <dcorsar> dcorsar has joined #prov
15:48:49 <jun> zakim, ??P0 is me
15:48:49 <Zakim> +jun; got it
15:49:34 <Zakim> -jun
15:49:36 <Zakim> SW_(PROV)12:00PM has ended
15:49:36 <Zakim> Attendees were jun
15:50:07 <Zakim> SW_(PROV)12:00PM has now started
15:50:14 <Zakim> +??P0
15:50:25 <jun> Am I the only one dialing in? I was told I am the first participant of the conference
15:50:28 <Zakim> + +1.805.893.aaaa
15:50:41 <Zakim> +??P2
15:50:42 <jun> zakim, ??P0 is me
15:50:43 <Zakim> +jun; got it
15:50:49 <dgarijo> zakim, ??P2 is me
15:50:49 <Zakim> +dgarijo; got it
15:51:25 <dcorsar_> dcorsar_ has joined #prov
15:52:30 <Luc> scribe: tlebo
15:54:54 <zednik> zednik has joined #prov
15:56:32 <tlebo> tlebo has joined #prov
15:56:49 <tlebo> Zakim, who is on the phone?
15:56:49 <Zakim> On the phone I see jun, +1.805.893.aaaa, dgarijo
15:56:55 <tlebo> Zakime, I am happy
15:57:43 <Luc> rrsagent, make logs public 
15:58:38 <zednik> zednik has joined #prov
16:00:38 <hook> hook has joined #prov
16:02:41 <Luc> zakim, who is here?
16:02:41 <Zakim> On the phone I see jun, +1.805.893.aaaa, dgarijo
16:02:42 <Zakim> On IRC I see hook, zednik, tlebo, dcorsar_, GK, pgroth, Curt, Zakim, RRSAgent, Luc, dgarijo, jun, MacTed, sandro, trackbot, stain
16:03:07 <Luc> guest:  Hook Hua
16:04:50 <Luc> regrets: Deborah McGuinness, James McCusker, Simon Miles, Ivan Herman, Olaf Hartig, Sam Coppens
16:06:08 <tlebo> The rest of the faces have arrived.
16:06:31 <dgarijo> I am afraid I will only be able to attend around 2 hours, since it is getting late here :(
16:07:35 <Paolo> Paolo has joined #prov
16:08:09 <dgarijo> http://www.w3.org/2011/prov/wiki/F2F3Schedule
16:08:10 <pgroth> Topic: Admin
<pgroth> Summary: The group was informed that Ivan will become our new W3C Contact replacing Sandro. The group thanked Sandro for all his work. Luc gave an update about the status of the group. There was good progress on since the last face to face. However, even with the progress we still need to ask for an extension by the end of July. The goals of the meeting were set out. Namely, to finalize what needed to be done for Last Call on the various document, to draft Candidate Recommendation exit criteria and to prepare for a Call for Implementations. 
16:08:20 <pgroth> http://www.w3.org/2011/prov/meeting/2012-06-14
16:08:30 <pgroth> proposed: Minutes of the June 14, 2012 telcon
16:08:36 <tlebo> +1
16:08:37 <dgarijo> +1
16:08:38 <jcheney> jcheney has joined #prov
16:08:39 <jun> +1
16:08:56 <zednik> +1
16:09:02 <jcheney> 0 (was not present)
16:09:03 <Paolo> +1
16:09:16 <dcorsar_> 0 (was not present)
16:09:29 <pgroth> accepted: Minutes of the June 14, 2012 telcon
16:10:35 <satya> satya has joined #prov
16:11:02 <tlebo> luc: Sandro has been our w3c contact; he is moving to other w3c tasks.
16:11:10 <tlebo> ... ivan to be our new contact.
16:11:34 <TomDN> TomDN has joined #prov
16:11:47 <tlebo> luc: review of what we've been doing and what we are to do.
16:11:57 <tlebo> ... first WD of DM in Sept.
16:12:17 <tlebo> ... F2F2 led to good progress.
16:12:26 <tlebo> ... now trying to prepare LCs.
16:12:43 <tlebo> ... charter on homepage: Oct 1.
16:12:56 <tlebo> ... we need to request charter extension.
16:13:15 <tlebo> ... logistics on charter extension.
16:13:33 <tlebo> ... request needs to be ready by end of July.
16:13:43 <tlebo> ... request is non-trivial.
16:14:04 <tlebo> ... we have one shot at the request. no more extensions.
16:14:11 <Zakim> +??P3
16:14:27 <GK> zakim, ??p3 is me
16:14:27 <Zakim> +GK; got it
16:14:31 <tlebo> ... goal of this meeting: identify what we want and need to do, decide what not to do.
16:15:09 <tlebo> ... it is up to the WG to decide how much more time to ask for.
16:15:26 <tlebo> ... our timetable from F2F2 shoots for Jan.
16:15:27 <pgroth> Revised timetable: https://docs.google.com/spreadsheet/ccc?key=0An15kLxkaMA3dFVCWm9aREZFemNOYjlGQjdPRkdFZXc#gid=0
16:15:40 <tlebo> ... may want to add a month or two for safety.
16:16:02 <tlebo> ... goal of meeting is to finalize LC.
16:16:21 <GK1> GK1 has joined #prov
16:16:41 <Zakim> +Satya_Sahoo
16:16:44 <tlebo> ... second goal: produce realistic timetable for remaining documents (Notes)
16:17:23 <pgroth> q?
16:17:27 <tlebo> ... we need to define what defines interoperability, aka "exit criteria".
16:18:02 <tlebo> ... need to prepare for Call for Implementations. Need to manage it.
16:18:17 <tlebo> ... who is going to take lead, what will be done?
16:18:54 <tlebo> 4 goals: finalize LC, timetable for WG (extension), define CR exit criteria draft, Call for Implementation.
16:19:04 <pgroth> q?
16:19:11 <Luc> q?
16:19:51 <tlebo> topic: PROV-DM
<pgroth> Summary: The goal of this session was to resolve the remaining technical issues around the PROV-DM in order to proceed to last call. The chairs listed the following features as having technical issues that needed to be resolved: collections and dictionaries, contextualization, primary source, tracedTo, data types and synchronization between prov-o and prov-dm. The group agreed that these were the remaining technical issues to be resolved. Options were given for resolution of the issues: 1) Leave it as is 2) A quick resolution and change in the document 3) a combination of 1 or 2 while marking the feature at risk 4) complete removal of the features
16:20:00 <tlebo> paul: technical features.
16:20:07 <tlebo> ... all "technical features" are done in LC.
16:20:23 <tlebo> ... we are promising that all technical features are done.
16:20:33 <Dong> Dong has joined #prov
16:20:51 <pgroth> collection contextualization primary source tracedTo (constraints are not final, should include specialization?) data types prov-o prov-dm incompability, e.g. prov\:location
16:20:52 <tlebo> ... Paul and Luc looked through all reviews and listed the outstanding technical features.
16:20:58 <Curt> Curt has joined #prov
16:21:06 <pgroth> http://www.w3.org/2011/prov/wiki/F2F3Schedule
16:21:34 <khalidBelhajjame> khalidBelhajjame has joined #prov
16:21:38 <tlebo> ... the above link shows the outstanding technical features that we need to settle.
16:21:40 <pgroth> q?
16:21:42 <tlebo> ... any others?
16:22:00 <tlebo> gk: prov-aq included?
16:22:03 <tlebo> paul: no
16:22:14 <tlebo> ... we'll talk about this afternoon.
16:22:18 <tlebo> ^ tomorrow
16:22:18 <jcheney> q+
16:22:24 <pgroth> ack jcheney
16:22:30 <GK1> Hmmm... I won't be around tomorrow
16:22:43 <GK1> But maybe that's OK.
16:23:09 <tlebo> jcheney: prov-constraints, what is the scope and intent of it?
16:23:24 <tlebo> ... it is behind the others, we need to be aware of it.
16:24:15 <tlebo> Paul: lets walk through each technical features.
16:24:22 <tlebo> ... we have "options" on each feature.
16:24:29 <tlebo> ... 1 - rapid change and leave it in
16:24:39 <tlebo> ... 2 - if consensus, leave in.
16:24:50 <tlebo> ... 3 - can mark any feature as feature at risk.
16:25:14 <tlebo> ... this is something we want to have, but it can be removed.
16:25:26 <tlebo> ... 4 - remove a feature completely.
16:25:38 <tlebo> subtopic: Collections
16:25:50 <tlebo> subtopic dm - collections
<pgroth> Summary: The group felt that the the technical definition of collections had been settled, however, the key question was whether the whole collection definition inclusive of dictionaries should have be included in the recommendation. Some members felt that collections should not be included as they were not core to the recommendation. Others argued that collections are fundamental to so many domains and thus need to be included for interoparability. Several straw polls were taken. A consensus was reached to keep the collections class and its associated membership relation in the prov-dm recommendation and move the dictionary portion of recommendation to a separate Note.
16:26:33 <tlebo> pgroth: summary. there has been debate and we seem to have converged.
16:26:40 <tlebo> ... Collection and hadMember.
16:26:49 <tlebo> ... "pop-up"s about collections.
16:27:05 <tlebo> ... e.g. okay to "strings" as keys in Dictionaries?
16:27:17 <tlebo> ... are Dictionaries stable enough for Rec?
16:27:28 <tlebo> ... or are they changing and will the continue to change?
16:27:39 <pgroth> q?
16:27:58 <pgroth> q?
16:27:59 <tlebo> luc: we can split the discussions.
16:28:00 <tlebo> q+
16:28:16 <pgroth> ack tlebo
16:28:52 <pgroth> q?
16:28:55 <Paolo> q+
16:29:01 <pgroth> ack Paolo
16:29:09 <tlebo> tlebo: my impression is that from the last weeks effort had settled it.
16:29:24 <tlebo> paolo: comfortable that we've settled it.
16:29:36 <tlebo> ... pop ups: Brian's concern. An official concern?
16:29:40 <tlebo> q-
16:30:00 <tlebo> ... "it's not clear" why they are there. "why aren't generic enough"
16:30:12 <tlebo> ... less worried about the technical definition.
16:30:31 <tlebo> ... the questions on the "strings" key issue.
16:30:39 <tlebo> ... "all of prov has to be semantic"
16:30:44 <Luc> Luc has joined #prov
16:30:53 <pgroth> q?
16:30:55 <tlebo> ... in an RDF encoding doens't imply "semantics"
16:31:01 <pgroth> q?
16:31:23 <tlebo> stephanZ: we should stick to string keys. it's just a way to index a member.
16:31:43 <tlebo> ... Bag of Hurt if we open keys to Resource.
16:31:58 <pgroth> q?
16:32:03 <tlebo> ... considers prov-o Dictionary modeling settled. Stable and reasonable. Fine wiht Note and Rec.
16:32:03 <TomDN> +1 jcheney
16:32:05 <reza_bfar> reza_bfar has joined #prov
16:32:28 <tlebo> pgroth: it seems that the technical work is stable.
16:32:28 <TomDN> sorry, +1 zednik
16:32:34 <GK1> (I don't understand that mention of "semantics"... by definition RDF has semantics, even if the semantics of a particular construct is vacuous.)
16:32:39 <tlebo> ... the existential of "do they belong" seems to be the only question.
16:33:16 <pgroth> straw poll: leave collections as there as part of the prov-dm rec
16:33:20 <tlebo> +1
16:33:24 <Paolo> +1
16:33:26 <Curt> -1
16:33:26 <khalidBelhajjame> +1
16:33:31 <TomDN> +1
16:33:32 <dgarijo> +1
16:33:33 <dcorsar_> +1
16:33:35 <reza_bfar> +1
16:33:35 <jun>   +1
16:33:36 <satya> +1
16:33:37 <GK1> -0 (I won't oppose consensus)
16:33:42 <jcheney> 0 (haven't kept up)
16:33:49 <zednik> +1
16:34:03 <tlebo> curt: they are a layer above the fundamentals.
16:34:21 <tlebo> ... it is a significantly complicated, many new concepts. 
16:34:25 <tlebo> ... likes how it's modeled.
16:34:30 <tlebo> ... fine as a note.
16:34:41 <tlebo> ... has no need for modeling prov of collections (personally).
16:34:49 <tlebo> ... it's extraneous.
16:35:01 <tlebo> ... like them, keep them, but not in Rec.
16:35:07 <dgarijo> but collections are not part of the "core" right?
16:35:10 <tlebo> paul: take dictionary?
16:35:24 <pgroth> q?
16:35:27 <Dong> +1
16:35:28 <tlebo> curt: all of collections, since there is nothing in spec that depends on it.
16:35:30 <GK1> @dgarijo They're in the REC
16:35:35 <GK1> (proposed)
16:35:41 <tlebo> ... the whole spec would be smaller.
16:35:49 <pgroth> q?
16:35:50 <dgarijo> @GK1 ok.
16:35:55 <pgroth> q+
16:36:02 <tlebo> ... collections are not fundamental.
16:36:15 <tlebo> ... loads of ways to model collections.
16:36:18 <Luc> Luc has joined #prov
16:36:21 <Luc> q?
16:36:23 <tlebo> ... it is a specialized thing.
16:36:42 <tlebo> ... like Workflows, not fundamental.
16:36:55 <jcheney> q+
16:37:04 <tlebo> paul: personal opinion to have Collection and hasMember in rec
16:37:21 <tlebo> ... Simon's argument that things on web is collection. it's all over the web.
16:37:40 <pgroth> ack pgroth
16:37:42 <reza_bfar> q+
16:37:43 <tlebo> ... Dictionaries can more easily be a big chunk for niches
16:37:55 <pgroth> ack jcheney
16:38:31 <GK1> I agree with Curt ... it's not fundamental to provenance, so not strictly needed.  There are other ways to model collections.  One could argue that many things on the web being collections is a reason *not* to include them in provenance specs, as we should use definitions that al;so work for non-provenance apps.
16:38:52 <tlebo> jcheney:  how separable are they? they are.
16:39:02 <pgroth> q?
16:39:05 <Paolo> q+
16:39:08 <Paolo> q?
16:39:11 <reza_bfar> q+
16:39:37 <tlebo> ... derivedByInsertion etc.
16:39:42 <pgroth> ack reza_bfar 
16:39:57 <khalidBelhajjame> +q
16:39:57 <tlebo> reza: for interoperabily, we need SOMETHING for Collection.
16:40:01 <jun> Mmmm, but the property hasMember has nothing to do with provenance. but I like to keep it because there are a lot of collections on the web, and we provide people a standard way to model the insertion, deletion etc key patterns, instead of letting everyone extend prov in their own way
16:40:05 <pgroth> q?
16:40:08 <pgroth> ack Paolo 
16:40:10 <tlebo> ... for Dictionary, agree with Paul (too complicated).
16:40:24 <tlebo> paolo: promote interoperability
16:40:35 <pgroth> q?
16:40:45 <tlebo> ... GK's point is the exact reason to include Collection.
16:41:01 <tlebo> ... Dictionary is one type of collection, if not fundamental. Then make it a Note. 
16:41:06 <tlebo> ... what is a Note?
16:42:08 <tlebo> pgroth: a Note is a Recommendation from our group, it has a standing, but not the full force. Some patent stuff, too.
16:42:18 <tlebo> luc: no burden of proving interoperability.
16:42:29 <tlebo> ... on a Note.
16:42:38 <pgroth> q?
16:42:41 <pgroth> ack khalidBelhajjame 
16:43:08 <tlebo> khalid: Curt said likely to treat as Collections, unlikely to go down. As long as it's in Rec OR Note, fine.
16:43:23 <dgarijo> I would leave collecitons in the recommendation. It is not part of the fundamental provenance, ok, but collections are out of what we have called the core.
16:43:26 <tlebo> ... a Note has Insertion and Removal, then Collection in DM doens't make sense.
16:43:36 <tlebo> q+ to say we have Bundle, Plan, etc. same with Collection.
16:43:54 <pgroth> ack tlebo 
16:43:54 <Zakim> tlebo, you wanted to say we have Bundle, Plan, etc. same with Collection.
16:43:57 <GK1> If we would pick an existing widely used collection spec and recommend that, I'd be more supportive.
16:44:12 <pgroth> q?
16:44:15 <tlebo> q-
16:44:41 <tlebo> pgroth: leave collection and hadMember, move Dictionary to Note.
16:44:50 <reza_bfar> +1 for Paul's proposal.
16:44:53 <Luc> q?
16:45:09 <jun> what about other stuff, like insertion, deletion? not included?
16:45:10 <Luc> q+
16:45:23 <Paolo> @jun no
16:45:44 <pgroth> ack Luc
16:45:59 <Paolo> @jun really, really minimal. essentially a placeholder as Tim pointed out
16:46:06 <tlebo> luc: if we take Dictionary out and keep just Collection and hadMember, do we still add their axioms?
16:46:17 <Paolo> q+
16:46:32 <tlebo> ... seems that we'd be adding new realtion to model between entity and xxx
16:46:41 <jun> @Paolo, thanks
16:46:45 <tlebo> ... does it mean that prov-n doc is taken out regarding Insertion?
16:46:46 <YolandaGil> YolandaGil has joined #prov
16:46:53 <pgroth> q+
16:47:01 <pgroth> ack Paolo
16:47:26 <tlebo> luc: hadMember is not provenance
16:47:37 <jcheney> q+
16:47:51 <reza_bfar> Does collection not imply life-cycle ownership?  So, something more specialized than hasMember?
16:47:54 <tlebo> paolo: specOf isn't provenance, either.
16:48:04 <tlebo> luc; specOf is related to aspects of Entities.
16:48:07 <Luc> q?
16:48:21 <pgroth> ack pgroth
16:48:28 <tlebo> pgroth: we aren't going to lose it.
16:48:35 <reza_bfar> In other words, doesn't the life-cycle of members of collection belong to collection?
16:48:51 <pgroth> ack jcheney
16:48:51 <tlebo> jcheney: as jun says...
16:49:08 <khalidBelhajjame> +q
16:49:13 <Paolo> q+
16:49:18 <tlebo> ... same can be said for membership, if it's not standard provenance, it's going to be part of it.
16:49:20 <khalidBelhajjame> ack kh
16:49:21 <pgroth> ack khalidBelhajjame 
16:49:29 <tlebo> paolo: what happens to prov-n?
16:49:31 <pgroth> ack Paolo 
16:49:31 <Luc> isn't there an ontology out there with a part of relation? why does it need to be in prov?
16:49:47 <Luc> isn't there an ontology out there with a "part of" relation? why does it need to be in prov?
16:49:49 <tlebo> ... take partOf out, is Note union of Rec?
16:50:07 <tlebo> ... a bi odd that's not provennace.
16:50:36 <hook> q+
16:50:39 <tlebo> ... the provenance of collections isn't in DM.
16:50:43 <Luc> q+
16:50:44 <pgroth> ack hook
16:50:57 <Luc> q+ isn't there an ontology out there with a "part of" relation? why does it need to be in prov?
16:51:28 <tlebo> hook: python and json, dictionaries and collections are fundamental and primative. Newer forms, they are intrinsic. But PROV isn't a programming language...
16:51:59 <tlebo> ... notional views as data structures as PROV or domain specific interpretations of structures.
16:52:06 <pgroth> ack luc
16:52:11 <jun> @luc, at least dcterms has it, isPartOf, hasPart
16:52:26 <tlebo> luc: if there are part_of relations otu there, then why make our own?
16:52:49 <tlebo> ... fine to make it i the Note, but on DM with only Collection, why "part-of"?
16:52:53 <tlebo> q+
16:52:53 <pgroth> q?
16:52:59 <pgroth> ack tlebo
16:53:15 <tlebo> q-
16:53:23 <reza_bfar> The issue I see with moving everything into the Note is that implementers start minimally and moving everything to the note is as good as moving everything out.
16:53:27 <tlebo> luc: proposal would be have EVERYTHIGN be a note.
16:53:29 <Paolo> q+
16:53:38 <pgroth> ack paolo
16:53:56 <tlebo> paolo: taht would make the most sense, as breaking things up it's hard to fit into buckets. left with too much semantics in one.
16:54:13 <dgarijo> Does this mean that we separate it from prov-o too?
16:54:31 <pgroth> q?
16:54:52 <zednik> @dgarijo I think so, create prov-collections
16:55:23 <tlebo> paul: first straw pole -1 and a 0
16:55:29 <GK1> I think the comparison with Python is misleading.  With RDF you can mix languages as required. With programming languages you can't.
16:55:33 <tlebo> ... next straw pole: move entirely to a Note.
16:55:48 <pgroth> straw poll: move collections completely into a note
16:55:53 <reza_bfar> -1
16:55:54 <Curt> +1
16:55:55 <khalidBelhajjame> +1
16:55:55 <dgarijo> +0 
16:55:59 <tlebo> +1
16:56:01 <reza_bfar> 0
16:56:05 <GK1> (My -0 meant that I'd prefer to drop, but won't argue against consensus)
16:56:11 <YolandaGil> -1
16:56:14 <reza_bfar> +q
16:56:15 <zednik> +1 (happy with results of either straw poll, argument was convincing to use note)
16:56:17 <jcheney> +1 (we can always go back later if there is strong pull for this)
16:56:22 <YolandaGil> q+
16:56:23 <pgroth> ack reza_bfar
16:56:24 <GK1> +0
16:56:26 <jun> +0 I don't mind either way. but what will happen to prov-o?
16:56:35 <tlebo> reza: daytime implementers can be devious. Will use different mechansism if it's not in the standard.
16:56:42 <TomDN> TomDN has joined #prov
16:56:52 <tlebo> ... "deviating the product" will be done by different companies.
16:56:55 <GK1> Overspecification kills standards too --- look at OSI.
16:57:01 <pgroth> ack YolandaGil 
16:57:02 <dgarijo> @Jun, That is my concern too. Will we have to separate it? Create another ontology?
16:57:08 <tlebo> yolanda: for Plan, we have nominal concept of Plan.
16:57:19 <Paulo> Paulo has joined #prov
16:57:20 <tlebo> ... nothing fleshes them in.
16:57:22 <Luc> q+
16:57:31 <Curt> prov\:type Collection
16:57:41 <tlebo> ... as a compromise, have Collection without hadMember (just like we have Plan).
16:57:45 <pgroth> q?
16:57:45 <zednik> q+
16:57:46 <Paolo> @yolanda so we just leave prov:type = "collection"?
16:57:47 <pgroth> ack Luc
16:58:04 <tlebo> luc: to reza: not suggesting we drop Coll/Dict entirely. Moved to Note.
16:58:07 <Paolo> q+
16:58:09 <satya> -1 (Note is a very vague notion and I don't understand how the features of collection can be modeled in Notes - specifically from perspective of PROV-O like Jun and Dani)
16:58:12 <tlebo> ... cut and paste job.
16:58:27 <pgroth> @satya - we are talking about a w3c note document
16:58:54 <satya> ahh - ok, (still -1, collection is needed in Rec from my perspective)
16:59:01 <tlebo> ... to Yolanda: we have Plans, yes. but we have hadPlan on QualifiedAssociation. So links TO it.
16:59:11 <Paolo> q?
16:59:11 <tlebo> ... Collection doesn't have an In or Out.
16:59:16 <zednik> q-
16:59:20 <tlebo> q+ to say the relation is subClassOf
16:59:28 <zednik> q+
16:59:46 <tlebo> yolanda: I'd chose Collection over Plan
17:00:22 <TomDN> +q
17:00:30 <tlebo> paolo: agree, notion of placeholder to leave open to elaboration.
17:00:48 <tlebo> ... reza's point that standards hold develoeprs hands for what they can do.
17:01:01 <GK1> We should remember that the specs we produce will not be the last word.  It's easier to add stuff later than to take out mistakes.
17:01:11 <pgroth> ack Paolo
17:01:19 <tlebo> ... Note is not enough.
17:01:29 <tlebo> q-
17:01:31 <pgroth> ack tlebo
17:01:47 <jcheney> @reza: Given that we can't standardize all kinds of collections in advance, developers will still be differentiating anyway.
17:01:51 <GK1> Also, I don't think it's about how binding a document may be, but how confident we are that it will garner consensus from a wider community.
17:02:14 <reza_bfar> FWIW - I think Yolanda's proposal is the way to go.  It avoids a situation where, for example, people will use something like a linked list of entities.
17:02:23 <GK1> A NOTE suggests we aren't so sure ... NOTEs may get picked up and standardized later if they make sense.
17:03:10 <pgroth> q?
17:03:26 <pgroth> ack zednik
17:03:35 <tlebo> zednik: adding a Note provides a claim to the developer to differentiate.
17:03:49 <tlebo> ... "we support the Rec and the Note" - the Note becomes the feature.
17:03:58 <tlebo> ... they can brag about the Note.
17:04:25 <tlebo> ... Note gives direction that they can move towards.
17:04:51 <tlebo> ... Collection with no properties. Def says "has entities".
17:05:34 <tlebo> ... Plans as stub, something that refers to the stub. We don't gain without hadMember.
17:06:03 <GK1> I think if something is well documented and makes sense, developers will use it.  Standard or no.  I think there's too much hand-wringing about status.  But if a spec is monolithic that would tend to weigh against it.  IMO.
17:06:07 <zednik> q-
17:06:14 <pgroth> ack TomDN 
17:06:22 <hook> q+
17:06:24 <tlebo> tomdn: if we put into rec, all we're saying is taht there is a collection and it has members.
17:06:29 <tlebo> ... for keeping Collection in rec.
17:06:52 <tlebo> ... it isn't technically provenance, but it IS! If you want to talk about where something comes from, it is a part of a bigger whole.
17:07:21 <Luc> q+
17:07:25 <tlebo> ... keep Collection and hadMember.
17:07:27 <Paolo> q?
17:07:34 <pgroth> ack hook
17:07:40 <tlebo> hook: extremes of interoperability.
17:08:03 <tlebo> ... having defined Collections and Plans without ties to them, breaks down interoperability.
17:08:12 <tlebo> ... systems will vary and defeats the purpose.
17:08:16 <pgroth> @gk for paq - i think we don't have a ton to talk about - just raising issues that we will have to address
17:08:31 <pgroth> @gk does that make sense?
17:08:33 <tlebo> ... e.g. OPM, Annotations, key-value pairs.
17:08:47 <GK1> @pgroth mainly, yes.  But I'm thinking we should drop hasAnchor.
17:08:52 <tlebo> ... 2nd point: Collections and Plans. Should be some constraining factors.
17:08:58 <tlebo> ... "Creatively used".
17:09:15 <tlebo> ... constraining and giving pattern.
17:09:24 <GK1> @pgroth ... because the main usecases are covered by specializationOf
17:09:36 <Paolo> @GK agree -- if you propose something that makes sense, that's the best way to win the argument regardless of status
17:09:43 <tlebo> luc: editors hat: constriants doc: no Collec/Dict. No constraints in dm-constraints (good!)
17:09:52 <tlebo> ... not clear we'll converge quickly
17:10:08 <tlebo> ... timeline!
17:10:16 <pgroth> @gk hmm maybe we can start that up on the mailing list and address it at  call
17:10:20 <tlebo> ... taking out of rec makes things faster.
17:10:29 <Paolo> q?
17:10:42 <GK1> @pgroth ack - I already responded to your issue
17:10:50 <tlebo> paul: less objection to keeping it in Rec
17:11:25 <tlebo> ... withotu hadMember relation, "it doenst make sense"
17:11:25 <Paolo> q+
17:11:30 <tlebo> .. what to do?
17:11:30 <Curt> q+
17:11:32 <Luc> ack luc
17:11:40 <Paolo> q+ to make a proposal
17:11:41 <khalidBelhajjame> +q (can we clarify what a W3C note mean?)
17:12:08 <YolandaGil> @Luc: how do you deal with Plan in the constraints spec?
17:12:15 <tlebo> paolo: a collection with hadMember in Rec, everything else goes to a Note.
17:12:28 <TomDN> +1
17:12:31 <tlebo> ... no constraints in dm-constraints
17:12:50 <pgroth> q?
17:12:53 <pgroth> ack Paolo
17:12:53 <Zakim> Paolo, you wanted to make a proposal
17:13:08 <GK1> My compromise might be: drop all collection-related classes; keep those collection properties that are subproperties of derivedFrom, etc., (as properties involving entities).
17:13:13 <tlebo> jcheney: does not seem to be controversy
17:13:54 <tlebo> luc: we can move mountains.
17:14:11 <tlebo> ... they restructured dm-constraints and prov-n
17:14:17 <tlebo> ... but they may be unhappy
17:14:37 <tlebo> jcheney: we don't want it, either.
17:14:45 <Zakim> -Satya_Sahoo
17:14:49 <tlebo> curt: mention the note in the Rec?
17:14:52 <jcheney> (does not seem to be controversy about memberOf and Collection cosntraints)
17:15:02 <tlebo> ... increase the stature for an implementer.
17:15:05 <pgroth> q?
17:15:07 <pgroth> ack Curt
17:15:26 <tlebo> paolo: if you do it right, people will follow it.
17:15:48 <reza_bfar> I'm good with either Yolanda's proposal or Paolo's proposal.
17:16:02 <khalidBelhajjame> +q 
17:16:12 <tlebo> paul: straw poll #3
17:16:21 <pgroth> ack khalidBelhajjame 
17:16:26 <tlebo> khalid: what is a Note?
17:16:55 <tlebo> ... "you can ignore the notes" when implementing a Rec.
17:17:14 <Zakim> +Satya_Sahoo
17:17:14 <reza_bfar> I think the key question is this:  "Can an implementer claim compliance while violating a note?"
17:17:20 <tlebo> ... they can claim compliance without doing the Note.
17:17:43 <tlebo> (but as Stephan points out, the Note becomes a bragging point for those that do)
17:18:09 <tlebo> paul: Notes are less forceful.
17:18:18 <GK1> If implemented an application that generated provenance with collections that are, say, rdf:List values, would I be in violation of a provenance REC that specified collections.  I think not.
17:19:00 <tlebo> jcheney: one can come up with other collections, but the question is do we require them to implemetn it? (not in a Note)
17:19:30 <Luc> proposal 1: keep collection and dictionary in recommendations
17:19:43 <Luc> proposal 2: keep collection class in recommendations, move collection membership and dictionary to note
17:20:04 <Luc> proposal 3: keep collection class and membership in recommendations, move dictionary to note
17:20:11 <TomDN> TomDN has joined #prov
17:20:14 <Luc> proposal 4: move collection and dictionary to note
17:20:38 <pgroth> proposal 1
17:20:42 <khalidBelhajjame> +1
17:20:47 <Dong> proposal 3
17:20:48 <GK1> -0
17:21:10 <GK1> vote 1:-0, 2:-0, 3:-0, 4:+0  (that would be a vote for 4)
17:21:12 <tlebo> PICK A NUMBER
17:21:23 <TomDN> +proposal 3
17:21:33 <jcheney> +proposal 3
17:21:40 <zednik> 3
17:21:40 <pgroth> pick a proposal
17:21:44 <khalidBelhajjame> 1
17:21:44 <jcheney> +proposal 3
17:21:44 <YolandaGil> 2
17:21:45 <TomDN> +proposal 3
17:21:46 <GK1> vote 1:-0, 2:-0, 3:-0, 4:+0  (that would be a vote for 4)
17:21:46 <Paolo> 3
17:21:48 <satya> 2
17:21:48 <zednik> 3
17:21:49 <tlebo> 3
17:21:50 <dcorsar_> 3
17:21:51 <Curt> 4
17:21:57 <jun> 4
17:21:59 <reza_bfar> 3
17:22:08 <Paulo> Paulo has joined #prov
17:22:39 <GK1> just take the last number then :)
17:22:48 <Dong> 3
17:24:06 <pgroth> proposed: keep collection class and membership in recommendations, move dictionary to note
17:24:10 <TomDN> +1
17:24:11 <Dong> +1
17:24:12 <Paolo> +1
17:24:13 <GK1> -0
17:24:13 <YolandaGil> +1
17:24:15 <Curt> +1
17:24:15 <zednik> +1
17:24:15 <tlebo> +1
17:24:15 <jcheney> +1
17:24:17 <dcorsar_> +1
17:24:20 <khalidBelhajjame> +0.5
17:24:48 <reza_bfar> +1
17:24:52 <jun> +0
17:25:04 <dgarijo> +0
17:25:05 <jun> [hard decision ...]
17:25:16 <pgroth> accepted: keep collection class and membership in recommendations, move dictionary to note
17:25:27 <Paolo> @jun I have made harder decisions in my life :-)
17:26:23 <jun> @Paolo, let's wait for contextualization :)
17:27:21 <tlebo> topic contextualization
17:27:34 <tlebo> subtopic: Contextualization
<pgroth> Summary: The group started with a straw poll on whether keeping contextualization in the specification. There were a few negative votes and positive votes and many abstentions. The members who voted negatively were asked to express their concerns. One concern by Khalid and Daniel was that contextualization was an attempt to bring back accounts by giving a semantics to a bundle and the definition was felt to be too complex. Graham expressed the view that it would be useful but in its current form the definition was not clear enough and could encourage users to apply in a way that could possibly break RDF semantics. Fundamentally, Graham was concerned that the concept was too important to get wrong. Tim and Tom argued that contextualization was a way to connect entities and their description in bundles and would not break RDF semantics. A key observation was that term context was overloaded and thus caused confusion. To avoid confusion, the group resolved to rename contextualization and leave the definition as it stands. Furthermore, because the feature is new and it's keen to understand how or if it will be used, the feature group decided that the term would be marked as "at risk".
17:27:47 <pgroth> straw poll: do we keep contextualization in the rec?
17:27:47 <GK1> are we voting yet?
17:27:47 <TomDN> +1
17:27:50 <GK1> -1
17:27:53 <tlebo> +1
17:27:57 <TomDN> +1
17:27:57 <Paolo> 0
17:28:02 <Curt> 0
17:28:02 <khalidBelhajjame> -0.5
17:28:03 <reza_bfar> 0
17:28:03 <jcheney> 0
17:28:04 <zednik> 0
17:28:06 <dgarijo> -0
17:28:06 <satya> -1
17:28:11 <dcorsar_> 0
17:28:21 <YolandaGil> 0
17:28:37 <GK1> My latest position: http://lists.w3.org/Archives/Public/public-prov-wg/2012Jun/0355.html
17:29:35 <jun> [I'll dial back then]
17:29:45 <pgroth> 20 minutes and we'll be back
17:29:50 <dgarijo> ok
17:29:59 <jun> @tlebo, thanks for the excellent scribing!
17:30:03 <Zakim> -jun
17:32:20 <dgarijo> maybe I'll have to go by then. As I said in my review of the DM, I think that contextualization is trying to do something similar what the accounts were trying to do with the ids within each account. We voted to leave them out of the dm because it complicated the model.
17:35:00 <Zakim> -Satya_Sahoo
17:49:22 <Zakim> - +1.805.893.aaaa
17:54:48 <Zakim> + +1.805.893.aabb
17:55:39 <dgarijo> I have to go. Hopefully I'll be able to join more time tomorrw. Good bye!
17:55:49 <pgroth> thanks dgarijo
17:55:51 <Zakim> -dgarijo
17:56:50 <Paolo> scribe: paolo
17:57:46 <satya> +1 Dani - I just dug out the previous version of DM to state that contextualization is trying to bring in Account through the back door
17:58:02 <satya> sorry, I have to leave for another meeting, will be back in an hour
17:58:42 <jun>   have we resumed?
17:58:57 <Luc> about to resume
17:59:04 <Zakim> +??P1
17:59:07 <Dong> Dong has joined #prov
17:59:13 <jun> zakim, ??P1 is me
17:59:13 <Zakim> +jun; got it
17:59:16 <pgroth> resuming
17:59:54 <khalidBelhajjame> +q
18:00:12 <GK1> q+
18:00:47 <Paolo> khalidBelhajjame: not opposed to keeping contextualization, but do we need to keep it as it is?
18:00:48 <tlebo> tlebo has joined #prov
18:01:08 <Paolo> khalidBelhajjame: def of contextualization too complicated for no good reason
18:01:13 <CraigTrim> CraigTrim has joined #prov
18:01:25 <jcheney> jcheney has joined #prov
18:01:29 <pgroth> ack khalidBelhajjame 
18:01:54 <Paolo> khalidBelhajjame: it simply adds bundle to specialization, however bundle appears to be a defined context, which is not really part of the def. of bundle in the current DM
18:01:57 <YolandaGil> YolandaGil has joined #prov
18:02:10 <TomDN> I was going to propose something like: "An entity that is a contextualization, is a specialization of an entity in another bundle"
18:02:28 <TomDN> (to simplify the phrasing)
18:02:53 <Paolo> khalidBelhajjame: bundle def was careflly phrased not to bring back "account", however in contextualization the bundle seems to define context, which is too strong a semantics
18:03:03 <pgroth> q?
18:03:07 <pgroth> ack Gk
18:03:12 <hook> hook has joined #prov
18:03:20 <GK1> Why I oppose leaving contextualization in the PROV specifications.
18:03:20 <GK1> First, I want to be clear that I don't oppose this because I don't think it is useful.
18:03:20 <GK1> Indeed, it's somewhat the opposite:  I think it's too important to risk getting wrong,
18:03:20 <GK1> and I really don't think we're clear enough about what we're trying to achieve here
18:03:20 <GK1> to be sure that we aren't getting it wrong.
18:03:21 <Paolo> GK1: see IRC 
18:03:24 <GK1> As far as I can tell, contextualization as currently described has NO semantics that
18:03:27 <GK1> distinguish it from specializationOf, yet I believe it encourages users to read into it
18:03:28 <Paolo> GK1: just above...
18:03:28 <GK1> uses that could violate the semantics of RDF URI usage (by creating an illusion of
18:03:30 <GK1> URIs that denote different things in different contexts).
18:03:34 <GK1> In the absence of such semantics (i.e. without usable inferences), I can't see any valid 
18:03:36 <GK1> reason for  including contextualizationOf.  I believe this is an area in which we really 
18:03:38 <GK1> *need* formalization and rigour, because it relates so closely to RDF semantics.
18:03:42 <GK1> If we caused lots of developers to produce data that turns out to be inconsistent with 
18:03:44 <GK1> RDF semantics, that would be real harm done, far far worse than the kind of failure of 
18:03:46 <tlebo> @khalid, I agree that bundles do not define themselves as contexts, and they shouldn't.
18:03:46 <GK1> interoperability just discussed in the context of collections.  In this case, if we got it 
18:03:48 <GK1> wrong, it would much harder to just ignore any stuff that turns out not to work the way
18:03:49 <Paolo> GK1: this concept too important to get wrong
18:03:51 <GK1>  it was intended, because there could be lots of broken data out there.
18:03:52 <GK1>  
18:03:54 <GK1> If provenance is wildly successful, I suggest that broken contextualization could result
18:03:56 <GK1> in Balkanization of the semantic web to rival the Browser wars over HTML that 
18:03:58 <GK1> we saw in the late 90s.
18:04:03 <GK1> And we should remember that the specs we produce will not be the last word.
18:04:04 <GK1> When the whole issue of RDF contextualization is better defined (i.e. we have
18:04:06 <GK1> formal semantics for RDF datasets) then it should be possible to define 
18:04:08 <GK1> provenance contextualization that we can be confident won't be used
18:04:10 <GK1> inappropriately.
18:04:14 <GK1> Part of the reason that I'm so wary of this particular relation is that I think 
18:04:17 <GK1> it usurps a part of semantic web technology that is being defined by the RDF 
18:04:18 <GK1> working group ("named graphs", datasets and associated semantics).  As such, I 
18:04:20 <GK1> think the whole discussion about this should be conducted in the provenance+RDF 
18:04:22 <GK1> coordination group.
18:04:26 <Paolo> GK1: no semantics to make it different from specialization
18:04:39 <pgroth> @paolo
18:04:42 <zednik> zednik has joined #prov
18:04:44 <pgroth> you don't have to scribe this
18:04:48 <pgroth> he pasted it in
18:04:52 <Paolo> GK1: but there is a chance it will be misused -- (see argument above on IRC)
18:05:05 <Paolo> GK1: no valid reason to include this
18:06:14 <Paolo> GK1: dire consequences if we get this wrong
18:06:31 <pgroth> wow! i want to be that successful
18:07:29 <Paolo> GK1: this discussion should be don on much closer coordination with the RDF WG
18:07:42 <pgroth> q?
18:08:31 <Paolo> pgroth: any comments from people who were in favour?
18:09:33 <Paolo> Luc: def can possibly be simplified.  the app-specific interpretation in the current def follows a discussion with Satya
18:09:40 <jcheney> q+
18:09:48 <Paolo> Luc: but that part can be removed
18:10:43 <Paolo> Luc: comments to GK1: absence of inferences for this relation is not a strong objection, there are other examples in the spec
18:11:11 <Paolo> Luc: contextualization is a form of specialization with an extra fixed aspect, namely the bundle 
18:11:50 <GK1> Just wanted be clear I feel strongly about this!
18:11:53 <Paolo> Luc: surprised that it may lead to such drastic consequences as those GK1 envisioned
18:12:37 <Paolo> Luc: "context" used in a broad sense, it may apply to other elements of the model
18:12:41 <pgroth> q?
18:13:03 <Paolo> GK1: can't be sure it's not a problem -- but if it is, it can do serious damage
18:13:07 <TomDN> TomDN has joined #prov
18:13:15 <pgroth> ack jcheney 
18:13:30 <GK1> Can't hear
18:14:00 <pgroth> better?
18:14:02 <Paolo> jcheney: description of bundle makes it just a container, it doesn't say anything about context
18:14:08 <GK1> yes, thanks
18:14:51 <pgroth> q?
18:14:57 <tlebo> q+
18:15:08 <Paolo> jcheney: GK1 seems to need a formal discussion of the implications of this def -- is that needed as part of the formal semantics?
18:15:46 <Paolo> GK1: that would be better, however the point of the meeting is to decide what's in or out, and this would need more time
18:15:50 <pgroth> ack tlebo
18:15:58 <Paolo> GK1: discussion with the RDF WG needed
18:16:48 <pgroth> the return of bob!
18:16:50 <jcheney> please don't call it bob
18:17:30 <Paolo> tlebo: prov:contextualize is just another property to relate two entities -- all we do is create 2 triples to associate 3 distinct resources with distinct URIs
18:17:36 <Paolo> tlebo: how does that break RDF semantics?
18:18:10 <Paolo> tlebo: and nonen of those URI are in the rdf namespace -- these are all in our own namespaces
18:18:17 <Paolo> s/nonen/none
18:18:32 <pgroth> q?
18:18:40 <Paolo> tlebo: can't see how this violates any of the RDF semantics
18:18:52 <tlebo> it gets me over to another bundle.
18:19:00 <Paolo> GK1: can't we get the same effect with specialization alone?
18:19:43 <Paolo> GK1: the structure is such that it may encourage people to use it in improper ways
18:20:36 <Paolo> GK1: the danger is of different interpretations of the same URI
18:20:43 <pgroth> q+
18:20:43 <Paolo> tlebo: the URIs are distinct...
18:21:13 <tlebo> http://aquarius.tw.rpi.edu/prov-wg/prov-o#inContext
18:21:16 <tlebo> ^^ different URIs.
18:21:29 <Paolo> pgroth: the idea is to relate two distinct URIs but also that one of them occurs in a bundle -- it's specialization plus "this other URI occurs in a bundle"
18:21:50 <tlebo> tool\:bob-2011-11-17 is not == :bob
18:22:01 <Paolo> khalidBelhajjame: believes GK1 is referring to "locatedIn" 
18:23:19 <jcheney> What if you do this: bundle b1 entity(bob,[a=1]) end   bundle b2 entity(bob,[a =2]) end
18:23:32 <Paolo> tlebo: (explains the use of inContext and specialization in the example above)
18:23:44 <jcheney> What stops me from concluding that entity(bob,[a=1,a=2]) ignoring the bundles?
18:24:04 <pgroth> +q
18:25:34 <khalidBelhajjame> hasProvenanceIn is described in http://dvcs.w3.org/hg/prov/raw-file/default/model/working-copy/wd6-bundle.html
18:25:56 <TomDN> +q
18:26:01 <Paolo> GK1: what are we getting out of contextualization that can't be stated more simply?
18:26:03 <pgroth> ack TomDN 
18:26:28 <Paolo> TomDN: maybe a qualified specialization?
18:26:44 <TomDN> (which isbasicly what a contextualization is)
18:26:59 <Paolo> GK1: the problem is what people may and up doing with these properties
18:27:07 <Paolo> s/and/end
18:27:21 <jcheney> can we feed this into RDF as a use case/possible requirement instead?
18:27:47 <jcheney> (or at least the "inContext part")
18:27:49 <Paolo> pgroth: we basically want to qualify a specialization with a bundle
18:27:55 <pgroth> ack pgroth
18:28:23 <TomDN> because we want it to inherit the same aspects as in the other bundle?
18:28:29 <Paolo> GK1: why do we you want to qualify specialization itself, rather than the entity itself that is introduced by the specialization?
18:29:05 <jun> @jcheney, we already did when we presented the XG work in the RDF workshop 2010. Good idea to take what they have at the  moment for a test drive
18:29:13 <khalidBelhajjame> +q
18:29:25 <tlebo> using a subclass of Involvmeent will require a third resource... :-(
18:29:30 <pgroth> ack khalidBelhajjame 
18:29:45 <jcheney> @jun, yes it would be good to see how that is handled and whether it addresses this
18:29:52 <tlebo> prov\:inContext  is the additional "fixed aspect" of the specialization.
18:29:53 <Paolo> khalidBelhajjame: maybe decompose contextualization into specialization plus another property
18:30:18 <Paolo> khalidBelhajjame: for example, the same idea may apply to alternate -- wouldn't that be another type of contextualization?
18:30:34 <GK1> if it were decomposed, I think I'd be *much* happier
18:30:35 <jun> @jcheney: +1. but how we make a decision now ...
18:30:47 <GK1> @jun +1
18:30:47 <pgroth> q?
18:30:54 <TomDN> very good point
18:30:55 <Paolo> khalidBelhajjame: so contextualization is "parametric" to the property that is being qualified
18:31:30 <Luc> q+
18:31:35 <Paolo> khalidBelhajjame: we could do contextualization for any type of relation
18:31:51 <tlebo> this was my original isTopicOf .
18:31:58 <Reza_BFar> Reza_BFar has joined #prov
18:32:45 <Paolo> Luc: it's the usual problem of n-ary relations modelled with RDF properties. we decided to go with functional contextualized to clarify that it is a 3-way relation encoded as a binary
18:33:40 <Paolo> Luc: wanted to avoi the qualified pattern for this
18:33:46 <Paolo> s/avoi/avoid
18:34:19 <Paolo> tlebo: rigt now contextualize is not functional, but it could be
18:34:34 <Reza_Bfar> Reza_Bfar has joined #prov
18:34:38 <TomDN> +q
18:34:43 <pgroth> ack Luc
18:35:12 <Paolo> tlebo: re: khalidBelhajjame's suggestion:  it would broaden the intended scope of this property too much
18:35:55 <GK1> Are we back to doing discovery through the data model?
18:36:01 <Zakim> - +1.805.893.aabb
18:36:13 <tlebo> so, khalid, you're suggesting that we just use isTopicOf with an open domain?
18:36:22 <tlebo> and range of bundle?
18:37:01 <GK1> specializationOf and isTopicOf as separate properties would be fine, I think.
18:37:48 <Zakim> + +1.805.893.aacc
18:37:57 <Luc> @gk, we were there befoer, and it doesn't work
18:38:02 <Luc> q+
18:38:37 <GK1> @luc my fear is that it doesn't work because you're trying to do something that RDF semantics doesn't support.
18:38:50 <Paolo> TomDN: @khalidBelhajjame: we already have what you are suggesting 
18:39:01 <pgroth> ack TomDN 
18:39:32 <pgroth> ack Luc
18:39:36 <Luc> specializationOf(new-bob,bob)   isTopic(bob,bundle)
18:40:06 <tlebo> @gk1, didn't we address the RDF semantics concern?
18:40:32 <Paolo> Luc: suggestion is to separate out the properties, but we've tried that before. Can't replace contextualization with those two relations
18:41:08 <GK1> You *never* know in RDF what extra constraints may be placed on an entity.  That's the open worlkd model for you.
18:41:44 <TomDN> you could specify "contextualized alternate"like this: contextualization(new-bob,bob), alternateOf(newer-bob,new-bob)
18:42:21 <TomDN> That way you keep consistent in your own bundle, reduce overhead, and still remain the link to the original entity(bob)
18:42:28 <Curt> contextualization is a specialization of specialization
18:43:23 <Paolo> Luc: in the example, Bob has a new fixed aspect, namely the bundle. the isTopic does not address that
18:43:40 <GK1> "You don't know what aspects are specialized in a particular bundle" - this sounds like use of RDF reification, but the original use of of that had precisely the problem that I'm afraid of.
18:44:37 <GK1> Sound is patchy.
18:44:43 <Paolo> s/new-bob/bob
18:44:52 <Paolo> s/bob/new-bob
18:44:58 <Paolo> (sorry, bob)
18:46:12 <tlebo> Tim's modeling of what he thinks Khalid would prefer: http://titanpad.com/yLqfwp8wps
18:46:30 <GK1> "the bob that is described in this specific bundle" -- that;'s exactly the problem.  bob is bob is bob.  RDSF semantics doesn't allow different bobs (with the same name "bob")
18:48:05 <TomDN> TomDN has joined #prov
18:48:08 <pgroth> q?
18:48:31 <TomDN> so contextualization is a means of getting a "Linked Open Bobs" cloud...
18:48:59 <pgroth> q?
18:49:07 <khalidBelhajjame> +q 
18:49:13 <Paolo> Luc: yes, it's the same bob in both activities, each described in a bundle. you can use specialization of bob to distinguish the contexts, using two different URIs and then relating them
18:49:16 <pgroth> ack khalidBelhajjame 
18:49:35 <tlebo> q+
18:49:47 <pgroth> ack tlebo 
18:50:25 <Paolo> tlebo: bundles are just sets of assertions, all contextualization is doing is to say that a bundle describes an entity
18:51:12 <Paolo> khalidBelhajjame: but now bundle is made to do more, too much semantics. the two bobs are different because they are in different bundles
18:51:31 <tlebo> q-
18:51:31 <pgroth> q?
18:51:36 <TomDN> TomDN has joined #prov
18:51:39 <Luc> q+
18:51:43 <pgroth> ack luc
18:52:09 <GK1> I am thinking that what Luc just said is maybe OK, but it's not at all clear (to me) from the spec.  The problem is that the definition of "bundle" says nothing about context.  It;'s just a bundle of assertions - there no claim that the assertions are in any way from a common "context".
18:52:28 <GK1> "Applications can exploit it inthe way they want" ... that's what I fear.
18:52:50 <Paolo> Luc: the link to bundles is just a general mechanism, which enables apps to then add their own interpretations, as illustrated in the bob performance example
18:53:06 <TomDN> linkedSpecialization?
18:53:09 <Paolo> pgroth: should we just rename context to something that is less overloaded?
18:53:22 <jcheney> -1 -1 -1
18:53:51 <tlebo> http://titanpad.com/yLqfwp8wps
18:53:55 <GK1> Renaming might help, but I think the problem is that there's no formal restraint on how it can be used.
18:53:59 <pgroth> http://titanpad.com/yLqfwp8wps
18:54:41 <Paolo> tlebo: inContext --> inBundle?
18:54:47 <Luc> q+
18:54:55 <pgroth> ack Luc
18:55:39 <GK1> q+
18:55:43 <pgroth> ack gk
18:56:16 <Paolo> GK1: elaborates on tlebo's titanpad example 
18:58:40 <Reza_Bfar> A side note is that in the RDMBS world, I think the word "View" is used to accomplish some of these things.  So, a "View" in the RDMBS world can be some selective, specialized, way of looking at things.
18:58:44 <Reza_Bfar> Just an idea... 
18:59:09 <pgroth> q?
19:00:17 <Paolo> GK1: requests that the text describing contextualization be made more clear as to its intended meaning 
19:00:41 <Paolo> GK1: the term "context" introduced without specification of its meaning
19:01:01 <Paolo> pgroth: we agree that the term is overloaded
19:01:29 <Paolo> pgroth: suggests to replace contextualization with isTopicOf
19:02:17 <GK1> Do you mean isTopicOf(e1, e2, bundle)?
19:02:25 <GK1> Seems odd to me.
19:03:06 <Curt> topic implies even more semantics -- it seems we want less..
19:03:06 <GK1> why not:  isTopicOf(e2, bundle) ; ispecializationOf(e1, e2)  ?
19:04:09 <Curt> ispecializationOf(e1, e2) doesn't tie to the specific instance of the bundle
19:04:24 <GK1> That's kind of the point
19:04:54 <Paolo> pgroth: how about adding an optional bundle argument to ispecializationOf
19:05:06 <Paolo> jcheney: not clear what the implications would be
19:06:00 <GK1> I think that adding an attribute to specializationOf would be better.  It suptypes the relation.
19:06:10 <Paolo> pgroth: one option is to keep the structure, trying to rephrase it, and mark it as at risk
19:06:45 <GK1> I think it's less inviting to abuse.
19:07:09 <Luc> q?
19:07:23 <Paolo> Luc: need to ask Ivan about what we can do once we flag as "at risk"
19:07:45 <TomDN> TomDN has joined #prov
19:07:51 <pgroth> q?
19:07:58 <Paolo> pgroth: marking it as 'at risk' implies that we can still remove it if no agreement is reached
19:08:11 <GK1> How not a subtype (didn't hear clearly)
19:08:42 <tlebo> @gk, b/c different arity
19:09:00 <TomDN> (just suggesting more names here: isExternalSpecializationOf(e1,e2, bundle), isSpecializedInBundle(e1,e2,bundle), ...)
19:10:13 <GK1> @TomDn "isSpecializedInBundle" I think is problem.  Maybe "isSpecializedFromBundle"?
19:10:15 <Luc> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-constraints.html#contextualization-specialization
19:11:01 <TomDN> @GK1: sure, was just throwing things out there...because the name is what we seem to be stuck upon
19:11:42 <jcheney> Can a q+
19:11:47 <jcheney> oops
19:11:47 <pgroth> q?
19:11:48 <jcheney> q+
19:11:53 <pgroth> ack jcheney 
19:12:36 <Paolo> jcheney: which bundle does the result of an inference live?
19:12:46 <Paolo> GK1: should go in the top leve
19:12:51 <Paolo> s/leve/level
19:13:55 <pgroth> q?
19:14:02 <Curt> +1 jcheney -- I think you nailed it.
19:14:05 <Paolo> jcheney: it seems we want specialization but in a way that "goes across" bundles, and we haven't thought that through
19:14:32 <Paolo> jcheney: so it may be similar to specialization, but not quite
19:14:36 <GK1> Sorry ... sound was dropping out - so I thought James had finishged.  I'd like to see the semantics after james has thought about it.
19:14:42 <Reza_Bfar> James, can you go over it again please?  I didn't get it.
19:15:03 <Paolo> jcheney: so we need to go back and think about it
19:15:12 <jcheney> @reza - at lunch maybe?
19:15:15 <Reza_Bfar> sure.
19:15:16 <Reza_Bfar> thanks
19:15:21 <Paolo> pgroth: was suggesting to make a quicker decision, for the sake of time
19:15:39 <Paolo> q+
19:15:57 <TomDN> to address the concern raised about the ternary structure: you're still free to use 2 binary relations
19:15:57 <TomDN> this is just an easier way to assert it in 1 statement
19:16:12 <GK1> I'm OK with a vote.  I'd reserve the right to maintain an objection going forward to last call.
19:16:14 <TomDN> much like derivation is to assert a usage + generation
19:16:32 <Paolo> pgroth: we could also have another round of discussion, but with a time limit
19:16:38 <pgroth> q?
19:16:56 <GK1> OKJ
19:16:59 <Paolo> pgroth: we could also vote on dropping it
19:17:06 <pgroth> q?
19:17:41 <pgroth> ack Paolo
19:18:24 <Paolo> pgroth
19:18:30 <pgroth> q?
19:18:39 <tlebo> q+ to say rename and at risk seems to correspond to the straw pol
19:18:41 <Paolo> pgroth: comments on what option people prefer?
19:19:29 <Paolo> tlebo: giving the recent straw poll, the renaming + marking seems like a reasonable option
19:19:38 <tlebo> q-
19:19:42 <pgroth> straw poll: rename contextualization (within a week ) and mark at risk 
19:19:46 <GK1> renaming to...?  Do we know?
19:19:48 <Paolo> +1
19:19:51 <tlebo> +1
19:19:53 <khalidBelhajjame> +1
19:19:54 <Curt> +1
19:19:55 <Reza_Bfar> +1
19:19:56 <jcheney> +1
19:19:56 <GK1> -0
19:19:56 <CraigTrim> +1
19:19:57 <zednik> +1
19:19:59 <dcorsar_> +1
19:20:00 <jun> +1
19:20:12 <YolandaGil> +1
19:20:12 <tlebo> hi, @jun!
19:20:23 <Dong> 0.5
19:20:26 <jun> hey, @tlebo!
19:20:44 <Dong> I want it renamed, but not marked as 'at risk'
19:20:48 <pgroth> accepted: rename contextualization (within a week ) and mark at risk
19:21:21 <GK1> I would oppose if not "at risk"
19:21:36 <Paolo> Luc: @Dong wise to put it at risk because it allows us to get feedback from implementers
19:21:39 <zednik_> zednik_ has joined #prov
19:22:13 <pgroth> Topic: Primer
19:22:28 <Paolo> TOPIC prov-primer
<pgroth> Summary: After an update on the Primer from Yolanda, the general consensus was that document was in could shape as it stood but to delay release as Last Call until feedback from on other last call documents so the Primer could take that feedback into account. There was also consensus that the Primer should not deal with the PAQ and to keep it lean.
19:23:08 <Paolo> pgroth: question is, do we take it to LC along with the others, or delay so we can incorporate feedback 
19:23:29 <GK1> I'm going to have to drop out now.
19:23:40 <Zakim> -GK
19:23:42 <dcorsar> dcorsar has joined #prov
19:23:50 <Paolo> YolandaGil: should not be a problem to delay
19:24:15 <hook> hook has joined #prov
19:24:24 <Paolo> pgroth: primer currently talks about DM only. should PAQ and other material be incorporated?
19:24:50 <TomDN> TomDN has joined #prov
19:24:59 <pgroth> q?
19:25:04 <Reza_Bfar> From implementers perspective, I think Paul's suggestion is the way to go.  I would leave the primer as is with just a pointer to PAQ.
19:25:06 <Paolo> pgroth: replies to himself: the PAQ by itself should be sufficiently self-describing  
19:25:14 <Reza_Bfar> Keeps the primer lean.
19:25:20 <Paolo> Curt: PAQ reads well on its own
19:25:22 <Reza_Bfar> +1 for Luc's comments.
19:25:51 <Paolo> q+
19:25:53 <Paolo> YolandaGil: 
19:26:19 <Paolo> YolandaGil: examples need to highlight provenance coming from different sources (publishers...)
19:26:54 <Paolo> YolandaGil: would add an example of bundle, and thus of provenance of provenance
19:26:54 <pgroth> q?
19:27:38 <pgroth> ack Paolo
19:28:12 <jun> Going to drop out now! Enjoy your lunch! Bye!
19:28:18 <Paolo> YolandaGil: nothing about collections in primer ATM. there will not be anything in the future, either
19:29:55 <Paolo> (lunch break)
19:30:01 <jun> thee more issues
19:30:07 <Zakim> - +1.805.893.aacc
19:30:08 <Zakim> -jun
19:30:08 <Zakim> SW_(PROV)12:00PM has ended
19:30:08 <Zakim> Attendees were +1.805.893.aaaa, jun, dgarijo, GK, Satya_Sahoo, +1.805.893.aabb, +1.805.893.aacc
19:30:08 <jcheney> Quick and dirty semantics draft at http://www.w3.org/2011/prov/wiki/FormalSemanticsWD5#Bundles
19:49:40 <satya> satya has joined #prov
20:28:52 <pgroth> is anyone on the phone?
20:30:40 <Zakim> SW_(PROV)12:00PM has now started
20:30:47 <Zakim> + +1.805.893.aaaa
20:30:47 <TomDN_> TomDN_ has joined #prov
20:33:34 <Luc> Luc has joined #prov
20:33:51 <Luc> q?
20:35:15 <Curt> Curt has joined #prov
20:35:29 <jcheney> jcheney has joined #prov
20:35:57 <pgroth> subtopic primary source
20:36:03 <pgroth> q?
20:36:12 <dcorsar> dcorsar has joined #prov
20:36:22 <pgroth> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#term-primary-source
20:36:41 <pgroth> q?
20:36:45 <jcheney> q+
20:37:06 <pgroth> ack jcheney 
20:37:12 <tlebo> tlebo has joined #prov
<pgroth> Topic: PROV-DM continued
<pgroth> Summary: the group continued discussion on the technical issues remaining in the prov-dm before last call 
20:37:22 <TomDN_> subtopic: primary source
<pgroth> Summary: Concerns about the clarity of the definition of primary source and its usefulness were expressed within the group. In particular, the relation is not tightly defined. Others group members argued that it was a vital relation to a number of different use cases (science, law) and that it was meant to be defined in a more open manner. The group decided to keep the relation as is but add a suitable reference for the definition used. 
20:37:35 <hook> hook has joined #prov
20:37:46 <ferdinand> ferdinand has joined #prov
20:37:50 <TomDN_> pgroth: Daniel had some objections about hadPrimarySource in his review
20:38:24 <CraigTrim> CraigTrim has joined #prov
20:38:52 <TomDN_> jcheney: I'm surprised of the use of subtype instead of subproperty. (It's a naming issue)
20:39:46 <TomDN_> ... we're already saying wasDerivedFrom, which can have a more specific type, such as wasRevisionOf
20:40:31 <TomDN_> ... we use prov:type for this
20:40:39 <GK1> @jcheney taking a quick look at  http://www.w3.org/2011/prov/wiki/FormalSemanticsWD5#Bundles - at first glance, what your describing is beyoind the expressive capability of current RDF semantics.  This is the sort of thing I'd expect to see coming from RDF WG for semantics of Datasets (http://www.w3.org/2011/rdf-wg/wiki/Documents#RDF_1.1_Semantics), but so far there's no editors' draft of that.  I guess you've seen Guha's thesis and other work in this area?  Also,
20:41:23 <TomDN_> Luc: you've got the binary relation (wasDerivedFrom), and the extra attributes to specify the association class
20:41:32 <zednik> zednik has joined #prov
20:41:32 <TomDN_> jcheney: ok
20:41:54 <Reza_BFar> Reza_BFar has joined #prov
20:42:16 <TomDN_> jcheney: not an issue, moving on...
20:43:05 <TomDN_> Luc: Khalid had some remarks about the clarity of the definition
20:43:16 <TomDN_> khalid: but it can be solved by simply rephrasing
20:43:31 <TomDN_> pgroth: anyone else have this problem with the definition?
20:43:44 <pgroth> q?
20:44:07 <tlebo> http://en.wikipedia.org/wiki/Primary_source
20:44:07 <TomDN_> zednik: it's supposed to be a first-hand experience of an event
20:44:18 <pgroth> q?
20:44:34 <TomDN_> pgroth: so is there still an issue?
20:44:44 <TomDN_> ... and/or suggestions?
20:44:46 <pgroth> q?
20:45:07 <TomDN_> Khalid: can we find another way of characterizing it?
20:45:13 <TomDN_> paolo: it can be derived from entities
20:45:47 <jcheney> @GK1: Yes, this is what makes me nervous about contextualization.  However, what I wrote is very preliminary so far.  Haven't read Guha's work carefully but familiar with related ideas in modal logic
20:45:47 <TomDN_> Khalid: it would be easier to say: primary source cannot be derived by any other source
20:46:00 <TomDN_> tlebo: but that's not true, they can
20:46:01 <Dong> I wonder if there is a strong use case to include hasPrimarySource in the DM
20:46:35 <TomDN_> Paolo: maybe we should find the "primary source" for the primary source definition...
20:46:43 <TomDN_> ... (to make sure it's clear)
20:46:59 <Dong> because the definition of it seems to up to the user
20:47:10 <TomDN_> ... We could offer a citation for the definition
20:47:17 <pgroth> http://www.princeton.edu/~refdesk/primary2.html
20:47:42 <GK1> @jcheney - ah ... I thought the language was reminiscent of modal logic.  I don't recall that Guha appeals to modal logic in his thesis ... it's more like full FoL with rules for mapping between contexts (he calls them "lifting rules").
20:47:50 <Curt> q+
20:48:05 <TomDN_> "A primary source is a document or physical object which was written or created during the time under study. " (priceton)
20:48:22 <pgroth> ack curt
20:48:25 <TomDN_> Curt: tries to apply this concept to other domains, and it seems to fit
20:48:38 <GK1> @jcheney BTW, my previous comment got truncated.  The bit that (I think) went missing was:  Also, there was an informal proposal from Pat Hayes to the RDF WG a couple of months ago.  My point is, I think you should be working with these guys to work out a common model, not in isolation.
20:48:42 <TomDN_> ... Does it accomodate data?
20:48:45 <TomDN_> everyone said yes
20:49:08 <TomDN_> pgroth: consensus is to add a suitable definition/citation to clarify
20:49:42 <TomDN_> dong: what's the distinction between derivation and primary source?
20:50:03 <TomDN_> tlebo: depends on what you're trying to do with the provenance
20:50:15 <TomDN_> pgroth: it's purposely left subjective
20:50:20 <TomDN_> ... to that end
20:50:48 <TomDN_> zednik: scientists don't add as much value to derivation as to primary source
20:51:04 <TomDN_> ... They don't always want to full derivation
20:51:10 <TomDN_> s/to/the
20:51:20 <Reza_BFar> +q
20:51:47 <TomDN_> dong: We're trying to produce a standard, but we don't define this difference
20:52:21 <TomDN_> reza: When you look at legal documents, primary source is atomary
20:52:39 <TomDN_> ... You don't look beyond this point.
20:52:40 <Dong> +q
20:52:56 <TomDN_> ... There is some distinction that needs to be made
20:53:26 <TomDN_> pgroth: We had originalSource first, but the proper term is primarySource.
20:53:33 <khalidBelhajjame> +q
20:53:41 <pgroth> ack Reza_BFar 
20:53:44 <pgroth> ack Dong 
20:54:00 <TomDN_> ... It's clear anough to use when looking at the English definition, but it's open enough for interpretation
20:54:01 <Reza_BFar> is Atomicity the common theme?
20:54:13 <Reza_BFar> can't break it down further, etc.
20:54:38 <TomDN_> dong: I'm concerned about this openness to interpretation
20:55:05 <TomDN_> tlebo: but that is mentioned in the wiki page
20:55:25 <pgroth> ack khalidBelhajjame 
20:55:28 <Reza_BFar> +q paulo
20:55:29 <TomDN_> ... it is discipline specific
20:55:51 <TomDN_> khalid: it's not something we want to infer, but that is specified by the asserter
20:55:57 <tlebo> DM: "It is recognized that the determination of primary sources can be up to interpretation, and should be done according to conventions accepted within the application's domain"
20:56:06 <Curt> an entity can also have multiple primarysources
20:56:10 <Paolo> q+
20:56:15 <Paolo> q-
20:56:22 <TomDN_> The name primarySource implies that this is the MAIN entity that was used for the derivation
20:57:07 <pgroth> q?
20:57:14 <pgroth> ack Paulo
20:57:32 <Dong> Is there a constraint "there can only one primary source"?
20:57:36 <hook> +q
20:58:25 <Reza_BFar> I would say that, in a provenance graph, it would mean a point in the graph that has no derivation before it and we know that there is no way we can find derivation that caused it... 
20:58:58 <TomDN_> hook: primary source is usually something that is validated by the domain experts
20:59:05 <Luc> q+
20:59:09 <Reza_BFar> Pq
20:59:12 <Reza_BFar> +q
20:59:13 <pgroth> ack hook\
20:59:14 <TomDN_> ... can we capture this contextual element?
20:59:19 <Reza_BFar> +1
20:59:24 <Reza_BFar> +q
20:59:25 <TomDN_> Luc: it's a relation, not a type of entity
20:59:37 <pgroth> ack Reza
20:59:39 <TomDN_> ... the context is given by the relation
20:59:40 <pgroth> ack hook
20:59:41 <pgroth> ack Luc
21:00:16 <TomDN_> Reza: if there's a discontinuity in a provenance graph, the point right before this discontinuity is the primary source
21:00:31 <pgroth> q+
21:00:31 <TomDN_> s/before/after
21:00:36 <zednik> q+
21:00:37 <tlebo> so, sounds like there's plenty of uses for it :-)
21:01:09 <hook> +q
21:01:15 <TomDN_> pgroth: it's clear that it's useful. But it is left purposely scruffy, to support all these different uses
21:01:27 <TomDN_> ... Does anyone want it out of the spec?
21:01:43 <zednik> q-
21:01:47 <pgroth> ack pgroth
21:01:50 <pgroth> ack hook
21:01:57 <TomDN_> Luc: As concluded earlier, we should add a suitable definition/citation for it
21:02:09 <pgroth> resolved: add a suitable primary source for the definition of primary source
21:02:25 <TomDN_> subtopic: tracedTo
<pgroth> Summary: Luc expressed concerns that the tracedTo relation did not seem to serve much purpose and that its inferences within the constraints may have not been fully correct, in particular, that it implied transitivity across quite a few but not all relations. Tom and Paul argued that the relation was important because it allowed the expression of a lighter or more unconstrained form of influence that was transitive, which was particularly useful in scenarios where provenance was being reconstructed or stitched together. Paolo identified that transitivity was actually a query language problem and shouldn't be a concern of the data model itself. The group agreed that the indeed transitivity could be dropped. The group identified that the notion that tracedTo was being used for was similar to the role of Involvement in prov-o. Involvement did not have a corresponding concept in prov-dm. The group agreed that the notion of involvement without transitivity was what was required. Finally, the group agreed that influence was a better term. Essentially, influence would act as a top-level relation within the model. The group resolved to replace with Trace by Influence with no transitivity. A further benefit of this resolution is that it improved alignment between prov-o and prov-dm.  
21:02:59 <TomDN_> Luc: I don't like tracedTo
21:03:18 <TomDN_> ... It doesn't seem to serve much purpose, but people objected to dropping it.
21:03:46 <TomDN_> ... The issue is: do we want to infer tracedTo across specialization?
21:04:14 <Paolo> q+
21:04:16 <TomDN_> .. and how does this add up  with the definition in the DM?
21:04:23 <TomDN_> (it doesnt support it)
21:04:25 <pgroth> ack paolo
21:04:31 <pgroth> q+
21:04:34 <TomDN_> paolo: Why not drop it?
21:04:43 <TomDN_> ... I would.
21:05:09 <TomDN_> pgroth: I like it!
21:05:28 <Luc> q?
21:05:42 <TomDN_> ... It allows to express notions of influence that are guaranteed to be transitive
21:05:52 <TomDN_> ... And it's wooly
21:06:15 <TomDN_> ... Which is great when you try to reconstruct provenance
21:06:38 <TomDN_> ... and derivedFrom isn't necessarily transitive
21:06:58 <tlebo> q+ to say that the current prov-o modeling reflects the right RDF modeling patterns.
21:07:10 <TomDN_> ... For these types of reconstructing applications, I'd add attributes to derivedFrom if tracedTo is dropped
21:07:12 <pgroth> ack pgroth
21:07:14 <Luc> ack pg
21:07:30 <pgroth> ack tlebo
21:07:30 <Zakim> tlebo, you wanted to say that the current prov-o modeling reflects the right RDF modeling patterns.
21:07:34 <TomDN_> tlebo: In prov-o, we have this whole subproperty tree under wasDerivedFrom
21:08:14 <TomDN_> ... If tracedTo disappears, it would be bad
21:08:27 <khalidBelhajjame> +q
21:08:48 <TomDN_> ... When reconstructing/stitching provenance entities, tracedTo is useful
21:08:48 <Paolo> q+
21:08:50 <jcheney> q+
21:09:02 <jcheney> q-
21:10:02 <TomDN_> Luc: I'm not sure that the inferences in the constraints are the ones we want
21:10:07 <pgroth> q+
21:10:14 <TomDN_> ... and how they influence the definition in the DM
21:10:50 <hook> q+
21:11:00 <khalidBelhajjame> ack khalidBelhajjame 
21:11:02 <TomDN_> tlebo: just founded the "Rescue TracedTo Foundation"
21:11:09 <Luc> q?
21:11:30 <tlebo> Don't Club Baby Seals: Save TracedTo!
21:11:37 <Luc> ack pao
21:11:58 <Zakim> +Satya_Sahoo
21:12:12 <TomDN_> paolo: The reason I said to drop it is that it seems more than graph traversal that ignores the relation types, but when it tries to pick some particular paths, it seems arbitrary
21:12:26 <TomDN_> ... I'd like to see this constrained more
21:12:29 <Luc> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-constraints.html#inference-trace
21:12:38 <jcheney> q+
21:12:41 <TomDN_> ... Why are some traversals legal and others not?
21:12:44 <Luc> q?
21:12:55 <TomDN_> Luc: this is indeed the origin of the issue to some extent
21:13:19 <TomDN_> pgroth: Can't we have the concept without that many implications in the constraints?
21:13:51 <TomDN_> pgroth: I'm currently using it for assertions
21:13:55 <TomDN_> +q
21:14:03 <Luc> ack pg
21:14:03 <pgroth> ack pgroth
21:14:24 <TomDN_> hook: I fear that tracedTo would inherit semantics
21:14:30 <khalidBelhajjame> +q
21:14:38 <TomDN_> ... and people would rather use this than more specific relations
21:14:41 <Luc> ack ho
21:15:00 <TomDN_> ... (e.g. at capture time, when you want more specific stuff)
21:15:16 <tlebo> is the PROV-WG really suggesting that we eliminate a transitive property?
21:15:27 <TomDN_> ... It's lossy
21:15:27 <Curt> add verbiage to tracedto encouraging more specific terms 
21:16:11 <TomDN_> jcheney: How many of the inferences in the constraints are helpful or not?
21:16:46 <tlebo> is'nt the organizing principle that it's all invovmenets among Entities?
21:16:52 <TomDN_> ... some are redundant
21:17:23 <TomDN_> Luc: When we designed it, we had agents in mind
21:17:29 <TomDN_> ... and responsibility
21:17:38 <TomDN_> jcheney: It seems a bit overloaded
21:18:20 <pgroth> q?
21:18:26 <tlebo> so if we cut out agents from tracedTo, then it's a transitive derivation among entities. "cutting out" Agents is addressed by just adding attribution to the traced to entity.
21:18:27 <pgroth> ack jcheney 
21:18:27 <TomDN_> Luc: assuming we go for this option (?) it will be clearer in the constraints, but does it still support pgroth's/hook's use case?
21:18:31 <pgroth> q+
21:18:34 <Luc> q?
21:18:45 <Luc> ack tom
21:19:10 <tlebo> just define it as a transtiive derivation?
21:19:28 <Luc> q?
21:19:32 <Luc> ack kha
21:19:39 <TomDN_> tomdn: Do we just want to express weaker relations than derivation?
21:20:18 <Luc> q?
21:20:38 <tlebo> transitivity is pretty useful for:     SELECT ?everything WHERE { <x> prov:tracedTo ?everything . }
21:21:13 <TomDN_> Khalid: It seems necessary (more than just convenient) when you have missing information about the activities etc. involved when inferring derivation/transitivity
21:21:14 <Paolo> traceability with transitivity isn't just giving a name to a closure relation? 
21:21:21 <Reza_BFar> I see we need tracedTo, but it seems like it's solving limitations of sem web reasoning?  if tracedTo is a "weaker" form of derivation, then the main purpose of "weaker" is to be used at reasoning time?  and if the answer to that is Yes, then I think the issue is we want to do something that's more similar to Baysian reasoning than transitive (which is binary)... but anyways... 
21:21:24 <Paolo> or rather, to the closure of a relation
21:21:45 <Luc> q?
21:21:46 <TomDN_> pgroth: For my purposes, having it as some kind of "transitive derivation" is fine
21:21:58 <Reza_BFar> If I have 3 tracedTo's in a row, then by the time I get to the end of the graph, that "tracedTo" should get weaker and weaker... 
21:22:03 <tlebo> @paolo: tracedTo is currently an "Activity-less transitive", no?
21:22:05 <Paolo> @Reza_BFar: Bayesian?? 
21:22:21 <Reza_BFar> I mean there is some "certainty" value associated with the derivation.
21:22:26 <TomDN_> ... To address Hook's issue with documentation, we could stress this in the spec
21:22:29 <Luc> q?
21:22:39 <Reza_BFar> It looks like "tracedTo = [derivation + certainty factor of reasoning]"
21:22:39 <TomDN_> Luc: then what's wrong with wasDerivedFrom?
21:22:40 <Paolo> @Reza_BFar: oh i see what you mean
21:23:07 <TomDN_> tlebo: TracedTo allows you to add levels of abstraction (more than derivation)
21:23:25 <TomDN_> +1 tlebo, well phrased
21:23:46 <Curt> just derivation, and not attribution?
21:24:48 <Reza_BFar>  +q
21:24:52 <TomDN_> Luc: You can just derive a "scruffy"/"imprecise" derivation
21:25:17 <TomDN_> Luc: it doesn't have to specify all the activities involved
21:25:19 <Luc> q?
21:25:23 <Reza_BFar> -q
21:25:31 <Reza_BFar> =q
21:25:34 <Reza_BFar> +q
21:25:39 <Luc> ack pg
21:25:54 <pgroth> ack Reza_BFar 
21:26:21 <Paolo> q+
21:26:49 <hook> hook has joined #prov
21:26:59 <Luc> q?
21:27:08 <Curt> q+
21:27:15 <Luc> ack pao
21:27:34 <TomDN> TomDN has joined #prov
21:27:41 <TomDN> Reza: we need a certainty factor with every generation. (or even derivation, but might be too complex) pgroth: It would be good, but not in the standard.
21:28:09 <TomDN> paolo: It isn;t clear to me when to use one or the other
21:28:14 <Luc> q+
21:28:22 <Luc> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#term-trace
21:28:29 <TomDN> Curt: We should add an example for that
21:28:39 <Luc> q?
21:28:47 <pgroth> ack Curt
21:28:49 <TomDN> ... but what about attribution/agents?
21:28:53 <Luc> Trace ◊ is the ability to link back an entity to another by means of derivation or responsibility relations, possibly repeatedly traversed.  
21:29:05 <TomDN> Luc: that's the def we HAD
21:29:29 <TomDN> ... If we follow what james suggested, that would become
21:29:30 <pgroth> q+
21:29:47 <TomDN> ... Trace ◊ is the ability to link back an entity to another by means of derivation  relations, possibly repeatedly traversed.  
21:29:57 <TomDN> ... (without responsibility)
21:30:10 <TomDN> ... But then that's almost a regular derivation
21:30:12 <Luc> ack pg
21:30:18 <pgroth> q+
21:30:19 <Luc> ack l
21:30:21 <khalidBelhajjame> +q
21:30:39 <TomDN> pgroth: So we would keep tracedTo as only an inference?
21:30:44 <tlebo> +1 keeping agents in.
21:30:52 <TomDN> Luc: No, that was an adaptation of the current definition
21:31:08 <tlebo> tracedTo gives you an "activity-less" view of everything behind an entity.
21:31:28 <Dong> but derivations are not transitive, I believe
21:31:31 <pgroth> @tlebo but you can do that with activity
21:31:34 <TomDN> @tlebo: but so can derivations, no?
21:31:36 <Luc> q?
21:31:38 <pgroth> derivation
21:31:41 <Paolo> q?
21:31:47 <jcheney> +q to say that my suggestion was to pare down to the minimal inferences for which there is a use case.  If there are use cases for attribution as well as derivation then I'm fine with keeping htem.
21:32:01 <Paolo> q+
21:32:10 <tlebo> @pgroth, but "I don't care about Activity" when I'm trying to draw the tracedTo.
21:32:13 <TomDN> pgroth: I want to be able to assert floppy things, and then have transitivity across that
21:32:20 <jcheney> also, sparql 1.1 will have (hopefully not very broken) transitive queries
21:32:28 <TomDN> ... If that's possible with other things, that's fine
21:32:47 <Luc> q?
21:32:51 <Luc> ack pg
21:33:07 <TomDN> Khalid: To do that, we need to change the definition
21:33:08 <zednik> q+
21:33:30 <TomDN> @khalid can you put your definition on here?
21:33:33 <Luc> ack kha
21:34:11 <satya> It is a bit difficult to hear on the phone - can they speak a bit louder thanks!
21:34:22 <TomDN> jcheney: It sounded like the reason to have tracedTo was the transitivity, so we keep this, and throw away the rest
21:34:25 <Luc> q?
21:34:49 <Luc> ack jch
21:34:49 <Zakim> jcheney, you wanted to say that my suggestion was to pare down to the minimal inferences for which there is a use case.  If there are use cases for attribution as well as
21:34:52 <Zakim> ... derivation then I'm fine with keeping htem.
21:35:12 <tlebo> If we strip out agents in the tracedTo inferences, we'll then just do:    SELECT ?everything WHERE { <x> prov:tracedTo ?everything . OPTIONAL {  ?everything prov:wasAttributedTo ?who } }
21:35:26 <Luc> q?
21:35:35 <TomDN> paolo: It's really a query language problem (as james just said), not a problem of the model itself
21:35:53 <jcheney> @tlebo good point, is there a strong motivation for having a single property naming this query?
21:36:06 <TomDN> ... that's not a strong enough argument to have it in the model
21:36:17 <tlebo> q+ to say that tracedTo is currently the Activity-less view of what led to an Entity.
21:36:22 <Luc> ack pao
21:36:29 <hook> SPARQL 1.1 supports http://www.w3.org/TR/sparql11-query/#propertypaths
21:37:01 <TomDN> zednik: The current definition doesn't make it clear that we're interested in the transitivity
21:37:06 <Luc> q?
21:37:46 <TomDN> ... will think about a new definition
21:37:56 <pgroth> ack zednik
21:38:07 <TomDN> Luc: We seem to have 2 different issues here. 
21:38:24 <TomDN> ... If we want it just for querying, we don;t need it in the model.
21:38:36 <TomDN> ... And if we want to assert it, we should have a better definition
21:38:46 <TomDN> ... and make the delta with derivation clear
21:38:50 <Luc> q?
21:39:09 <TomDN> tlebo: the distinction is that tracedTo includes agents
21:39:39 <TomDN> ... tracedTo allows you to get to every static fixed thing (as an activity-less view) about how you got to a certain entity
21:40:02 <Luc> q?
21:40:11 <Luc> ack tl
21:40:11 <Zakim> tlebo, you wanted to say that tracedTo is currently the Activity-less view of what led to an Entity.
21:40:12 <tlebo> q-
21:40:20 <khalidBelhajjame> The only argument for keeping tracedTo is the ability to express that an entity may have influenced the generation of another entity, without necessarily specifying the activitie(s) that were involved
21:40:31 <Luc> q?
21:40:34 <pgroth> q+
21:41:18 <TomDN> pgroth: I would include the notion of influence in the definition
21:41:53 <Luc> q?
21:41:57 <TomDN> ... but am not blocking
21:41:58 <Luc> ack pg
21:42:16 <hook> q+
21:42:26 <Luc> ack hoo
21:42:43 <TomDN> hook: couldnt you just use involvement
21:43:13 <TomDN> Luc: it's not in the DM, but in the ontology, but it is a good point
21:43:29 <Luc> q?
21:43:33 <TomDN> hook: seems like tracedTo is redundant
21:44:02 <TomDN> tlebo: So we would use something like "Involvement", without transitivity
21:44:10 <TomDN> ... and drop tracedTo
21:44:27 <Luc> q?
21:45:11 <TomDN> @tlebo: could you paste that in here please?
21:45:40 <tlebo> "The broadest provenance relation between two resources, prov:involved is the superproperty of all unqualified binary relations among any two Activities, Entities, or Agents (or anything else). A more specific property should be favored of prov:involved."
21:45:45 <TomDN> tnx :)
21:45:57 <tlebo> prov\:involved prov:editorsDefinition "The broadest provenance relation between two resources, prov:involved is the superproperty of all unqualified binary relations among any two Activities, Entities, or Agents (or anything else). A more specific property should be favored of prov:involved."  .
21:47:00 <TomDN> tlebo: this is already a qualified relation in prov-o, so the work there is already done
21:47:19 <TomDN> Luc: so this would need to belong to one of the components in the DM
21:47:50 <tlebo> "agents-responsibility"
21:47:56 <tlebo> ^^ NO
21:48:07 <tlebo> entities-activities
21:48:08 <pgroth> q?
21:48:14 <tlebo> +100 to "entities-activities" :-)
21:48:15 <TomDN> pgroth: should we put this in further elements?
21:48:19 <tlebo> bummer
21:48:25 <tlebo> -100 entities-activities
21:48:41 <TomDN> Luc: that would be a bit akward
21:49:50 <pgroth> q?
21:49:54 <Luc> q?
21:50:10 <TomDN> Luc: If people are satisfied with this resolution, that would be ok
21:51:40 <Luc> proposed: replace Trace (5.3.5) by Involvement, as related two objects to signify some form of influence, and remove all related inferences (including transitivity) 
21:52:22 <TomDN> jcheney: We would want to keep some rudamentary inferences
21:52:39 <Luc> proposed: replace Trace (5.3.5) by Involvement, as related two objects to signify some form of influence, and clean up related inferences (no transitivity required) 
21:53:18 <hook> http://aquarius.tw.rpi.edu/prov-wg/prov-o#involved
21:53:27 <Luc> proposed: replace Trace (5.3.5) by Involvement, as relation between two objects to signify some form of influence, and clean up related inferences (no transitivity required) 
21:53:38 <TomDN> +1
21:53:39 <jcheney> +1
21:53:45 <Paolo> +1
21:53:50 <khalidBelhajjame> +0.99
21:53:50 <Curt> +1
21:53:51 <dcorsar> +1
21:53:53 <CraigTrim> +1
21:54:04 <zednik> +1
21:54:05 <Reza_BFar> +1
21:54:06 <tlebo> +1
21:54:07 <Dong> +1
21:54:13 <satya> +1
21:54:23 <Luc> accepted: replace Trace (5.3.5) by Involvement, as relation between two objects to signify some form of influence, and clean up related inferences (no transitivity required) 
21:55:10 <Reza_BFar> involvedWith?
21:55:33 <TomDN> Luc: so what name will this beast have?
21:55:45 <TomDN> tlebo; involved(bla1,bla2)
21:55:46 <tlebo> "involved"
21:56:14 <TomDN> tlebo: involved(bla1,bla2)
21:56:22 <Reza_BFar> Question   \: is there a situation where the order\direction matters?
21:56:37 <TomDN> khalid: is it symmetric then?
21:56:45 <Reza_BFar> I don't think it is... 
21:56:59 <TomDN> pgroth: no, we would look back into the past, right?
21:57:39 <TomDN> jcheney: so how is it used in prov-o?
21:57:48 <TomDN> Luc: it's recommended not to use it
21:57:56 <TomDN> ... (discouraged)
21:58:17 <TomDN> Luc: maybe wasInfluencedBy?
21:58:34 <Curt> tracedto?
21:58:36 <TomDN> khalid: that seems too strong
21:58:39 <Reza_BFar> I think there are 2 different situations: A and B are symmetrically involved -- they are involved together.  The other is A is involved with B, but B is not involved with A
21:59:12 <TomDN> pgroth: +1 for influence
21:59:27 <Luc> q?
21:59:37 <TomDN> Curt: indeed, if there's no influence, it wouldnt be in the graph
21:59:54 <Reza_BFar> So, influencedBy is definitely not symmetric, right?
21:59:57 <Reza_BFar> just checking.
22:00:01 <TomDN> tlebo: seems better indeed
22:00:21 <TomDN> Luc: we would change this in the ontology aswell?
22:00:24 <TomDN> tlebo: yes!
22:00:28 <TomDN> Luc: nice!
22:00:41 <jcheney> influence (n): the capacity to have an effect on the character, development, or behavior of someone or something, or the effect itself 
22:00:47 <tlebo> prov\:involved -> prov:influenced && prov:Involvement -> prov:Influence
22:00:49 <Luc> q?
22:00:51 <pgroth> the capacity to have an effect on the character, development, or behavior of someone or something, or the effect itself:
22:01:29 <TomDN> paulo: what about contribute?
22:01:36 <TomDN> tlebo: too agent-like
22:01:47 <khalidBelhajjame> affectedBy
22:01:49 <TomDN> Luc: and  what would the term be then?
22:02:16 <TomDN> wasSomehowRelatedTo? ;)
22:02:55 <Luc> proposed: replace Trace (5.3.5) by INFLUENCE, as relation between two objects to signify some form of influence, and clean up related inferences (no transitivity required) 
22:03:13 <TomDN> +1
22:03:23 <Curt> +1
22:03:24 <Dong> +1
22:03:29 <Reza_BFar> +1
22:03:31 <khalidBelhajjame> +1
22:03:31 <CraigTrim> +1
22:03:31 <Paolo> +1
22:03:37 <dcorsar> +1
22:03:39 <jcheney> +1 (cf dictionary definition)
22:04:12 <TomDN> zednik: so generation is currently a subproperty of this
22:04:27 <TomDN> everyone said yes
22:06:31 <TomDN> tlebo: there's a conflict with this concept having some predefined order, and its subproperties (such as wasGeneratedBy)
22:07:25 <Reza_BFar> +1 with Luc
22:07:28 <TomDN> Luc: you would have wasGeneratedBy and generated
22:07:34 <TomDN> ... So that resolves it
22:07:40 <tlebo> +1
22:07:43 <zednik> +1
22:07:54 <Luc> accepted: replace Trace (5.3.5) by INFLUENCE, as relation between two objects to signify some form of influence, and clean up related inferences (no transitivity required) 
22:08:08 <tlebo> (consequence: we need wasInfluencedBy with inverse influenced)
22:08:54 <Zakim> -Satya_Sahoo
22:09:09 <Zakim> SW_(PROV)12:00PM has ended
22:09:10 <Zakim> Attendees were +1.805.893.aaaa, Satya_Sahoo
22:24:50 <Luc> q?
22:25:13 <Curt> Curt has joined #prov
22:26:00 <Luc> q?
22:27:37 <TomDN> TomDN has joined #prov
22:27:47 <Zakim> SW_(PROV)12:00PM has now started
22:27:54 <Zakim> + +1.805.893.aaaa
22:29:30 <Luc> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#term-value
22:29:41 <pgroth> subtopic: data types
<pgroth> Summary: PROV-DM defines the type of data types supported by the data model. On purpose, it reuses datatype definitions from other specifications namely XML and RDF. However, there is a concern that the new version of RDF will change the list of accepted datatypes. Thus, the current version of prov-dm adopts language that suggests that the prov-dm will be compatible will future revisions of RDF. It was noted that implementers would prefer to have static dependencies for purposes of interop. The group resolved that the datatypes used would be fixed to a specific version of RDF and that all datatypes would be supported. To make it clear that implementers should support all specified datatypes in rdf, it was agreed to remove table 8 that listed some commonly used datatypes. Ivan was given the action to review this resolution and its ramifications on organization and interaction with other groups. 
22:30:12 <CraigTrim> Luc: section 5.7.3 of the data model - describes possible attribute value pairs
22:30:35 <CraigTrim> Luc: this section matters for interop; we don't want to re-invent the wheel
22:31:11 <CraigTrim> Luc: RDF WG is still in the process of defining types they will support
22:31:28 <dcorsar> dcorsar has joined #prov
22:31:36 <CraigTrim> Luc: although we want RDF compatible types but how do we phrase this in such a way that if RDF spec changes, we don't have to change our specs too?
22:32:00 <reza_bfar> reza_bfar has joined #prov
22:32:30 <pgroth> q?
22:32:37 <CraigTrim> Luc: Are we happy with the phrasing in this section and should we keep this table of data types?
22:32:47 <Zakim> +Satya_Sahoo
22:33:20 <pgroth> q?
22:33:26 <tlebo> q+
22:33:30 <pgroth> ack tlebo 
22:34:09 <CraigTrim> tlebo: in RDF 1.1 it wasn't about just adding data types, also involved deprecating some of the types.  
22:34:32 <tlebo> q-
22:34:34 <pgroth> q?
22:34:45 <CraigTrim> Luc: This table comes from RDF WG
22:34:49 <pgroth> q+
22:35:32 <CraigTrim> pgroth: "PROV accepts the RDF-Compatible XSD types that RDF enumerates in its own specification" does this mean we limit ourselves to XSD datatypes?  
22:35:42 <CraigTrim> pgroth: in the chart (Table 8: Informative List of PROV-DM Data Types) we have RDF defined datatypes
22:35:54 <CraigTrim> pgroth: need to re-phrase that PROV accepts datatypes from RDF spec
22:36:11 <CraigTrim> Luc: If you go back to 3 bullet points above we say use of full data types is recommended
22:36:34 <pgroth> q?
22:36:38 <pgroth> ack pgroth 
22:37:02 <CraigTrim> pgroth: suggest if we follow what RDF does in selecting datatypes, we should just say that
22:37:34 <CraigTrim> pgroth: We are following the RDF spec directly, not selectively choosing from the RDF spec
22:39:56 <CraigTrim> pgroth: suggest adding forwarding pointer to something that is not finalized yet
22:40:59 <CraigTrim> pgroth: standard W3C layer is that we point to RDF 1.0 datatypes and then we re-open WG and re-go-through-some-procedure.  We can avoid this by being vague, but this vagueness could affect the spec
22:41:10 <CraigTrim> Luc: are all these types supported in the PROV-O?
22:41:45 <hook> hook has joined #prov
22:41:47 <pgroth> q?
22:42:13 <CraigTrim> Luc: In the data types section there is a notion of data type maps - is this relevant to us?
22:42:36 <Luc> http://www.w3.org/TR/rdf11-concepts/#section-Datatypes
22:45:17 <CraigTrim> Luc: How is i18n supported in XML for strings?
22:45:20 <tlebo> "A special attribute named xml:lang may be inserted in documents to specify the language used in the contents and attribute values of any element in an XML document"
22:45:28 <tlebo> 2.12 Language Identification
22:45:41 <tlebo> http://www.w3.org/TR/REC-xml/
22:45:55 <CraigTrim> pgroth: you can put xml:lang on any element and leverage inheritance
22:46:06 <pgroth> q?
22:46:24 <dcorsar_> dcorsar_ has joined #prov
22:46:36 <CraigTrim> pgroth: proposal is to be completely dependent on RDF datatypes w/no exceptions.  
22:47:29 <CraigTrim> pgroth: we might have informative content in our document and recommended content in RDF spec
22:49:34 <CraigTrim> tlebo: we only use common datatypes (URL, int, string, dateTime) in examples, so change should not impact us
22:49:48 <CraigTrim> pgroth: in favour of removing whole table
22:50:03 <CraigTrim> Curt: hot link into other document - if people want to see it, they can see it
22:51:28 <reza_bfar> +q
22:51:30 <CraigTrim> Dong: second that we link into spec - interopt is key
22:51:56 <reza_bfar> I prefer static dependencies over dynamic dependencies, but if Ivan says we can't do that, then it is what it is.
22:52:09 <pgroth> ack reza_bfar 
22:52:15 <CraigTrim> reza_bfar: from software pov we don't want dynamic dependencies
22:52:57 <CraigTrim> pgroth: seems to be consensus that we prefer linking to specific datatype doc that already exists
22:53:28 <CraigTrim> pgroth: we should go back to Ivan and work out a process with RDF wg
22:54:01 <reza_bfar> +q
22:54:38 <CraigTrim> pgroth: Ivan prefers not to change any document after it becomes a rec (a new charter is needed even for minor changes)
22:54:52 <reza_bfar> Isn't RDF 1.1 going to be backwards compatible to 1.0?
22:55:28 <CraigTrim> Luc: there will be more types supported in 1.1 
22:55:42 <CraigTrim> tlebo: they have also discussed deprecating existing types
22:56:10 <reza_bfar> I guess it all depends on what deprecation means.
22:56:25 <reza_bfar> If it means that it's indefinitely deprecated, but included, then we still don't have an issue.
22:56:32 <CraigTrim> Luc: suggest we endorse recommendation that PROV should support all types in concrete version of RDF
22:56:36 <reza_bfar> but if it means that it's in preparation for future exclusion, then there is a problem
22:56:36 <pgroth> proposed: prov should adopt all the types a specific version of RDF
22:56:40 <CraigTrim> +1
22:56:44 <reza_bfar> +1
22:56:46 <TomDN> +1
22:56:46 <Curt> +1
22:56:48 <dcorsar_> +1
22:56:49 <satya> +1
22:56:49 <jcheney> +1
22:56:52 <tlebo> +1
22:57:05 <pgroth> accepted: prov should adopt all the types a specific version of RDF
22:57:18 <pgroth> proposed: remove table 8 from prov-dm
22:57:20 <Curt> +1
22:57:21 <CraigTrim> +1
22:57:23 <Dong> +1
22:57:23 <tlebo> +1
22:57:25 <khalidBelhajjame> +1
22:57:25 <zednik> +1
22:57:27 <dcorsar_> +1
22:57:27 <jcheney> +1
22:57:27 <satya> +1
22:57:29 <reza_bfar> +1
22:57:36 <pgroth> accepted: remove table 8 from prov-dm
22:58:55 <pgroth> action: ivan to look at resolution on usage of a specific version of rdf datatypes. is it ok? what are the ramifications?
22:58:55 <trackbot> Created ACTION-93 - Look at resolution on usage of a specific version of rdf datatypes. is it ok? what are the ramifications? [on Ivan Herman - due 2012-06-29].
22:59:31 <pgroth> subtopic: incompatibility prov-dm and prov-o and moving to last call
<pgroth> Summary: Prov-o and prov-dm were incompatible for the relation prov:location because prov-o defined an open domain for location whereas prov-dm defined a closed domain. It was agreed to have a closed domain for hadLocation but to expand that domain to include not only entity, activity but also agent and instantaneous events. 
23:00:14 <Luc> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#term-attribute-location
23:00:45 <tlebo> "The attribute prov:location is an optional attribute of entity, activity, usage, and generation."
23:01:13 <CraigTrim> Luc: how do we reconcile PROV-O and PROV-DM here
23:01:25 <Luc> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#data-model-components
23:01:53 <CraigTrim> Luc: look at overview table 4 in section 5 - supported relations are indicated
23:02:26 <pgroth> q?
23:02:39 <reza_bfar> -q
23:02:40 <pgroth> ack reza_bfar 
23:02:41 <CraigTrim> Luc: not sure why have location on ActedOnBehalfOf and WasAttributedTo
23:02:53 <pgroth> q?
23:02:59 <pgroth> q+
23:03:06 <tlebo> q+
23:04:04 <CraigTrim> pgroth: I was associated with PROV F2F mtg in SB vs someone in Ohio - so location we are associated with is different
23:04:26 <pgroth> ack pgroth
23:04:48 <CraigTrim> tlebo: PROV-O has open domain for atLocation
23:05:54 <CraigTrim> tlebo: preferred to leave open to avoid actively excluding, but closing with union may be tidy
23:06:02 <pgroth> q?
23:06:07 <pgroth> ack tlebo 
23:06:54 <reza_bfar> I agree with Tim there.  Extending ontologies is supposed to be for further specialization not generalization
23:06:55 <CraigTrim> tlebo: seems odd for interopt effort to not take broader approach
23:07:01 <pgroth> q?
23:08:28 <CraigTrim> pgroth: reason to constrain Ontology is to give enriched semantics
23:08:54 <CraigTrim> pgroth: to constrain doesn't seem to help interopt in this case because we gain no enriched semantics
23:10:03 <CraigTrim> tlebo: is there a popular vocabulary that gives location?
23:10:21 <CraigTrim> pgroth: yes, but only for particular kinds of location 
23:11:30 <CraigTrim> pgroth: just put location on classes in model (location on entity, agent, activity) or open up completely (including qualified relations)
23:11:46 <CraigTrim> pgroth: alt is to pick and choose relations 
23:11:55 <pgroth> q?
23:12:31 <CraigTrim> tlebo: alt set domain of atLocation to top level of all our classes
23:13:03 <Curt> q+
23:13:08 <Luc> q?
23:13:11 <pgroth> ack Curt
23:13:43 <zednik> q+
23:14:16 <pgroth> ack zednik
23:15:00 <CraigTrim> zednik: suggest agent entity activity and instantaneous event
23:15:31 <CraigTrim> tlebo: union of these four is domain of atLocatoin
23:15:51 <CraigTrim> pgroth: in order to say locatoin of agent, you have to make agent an entity?
23:15:54 <CraigTrim> tlebo: yes...
23:16:37 <CraigTrim> pgroth: not just a map; every kind of location
23:17:22 <CraigTrim> pgroth: what does this leave out?
23:17:57 <pgroth> proposed: the domain of hadLocation is the union entity, activity, agent and instantaneous event
23:18:04 <CraigTrim> pgroth: so we can't say "was derived from at activity"
23:18:08 <reza_bfar> +1
23:18:08 <TomDN> +1
23:18:08 <Curt> +1
23:18:11 <khalidBelhajjame> +1
23:18:11 <Dong> +1
23:18:12 <CraigTrim> +1
23:18:12 <dcorsar_> +1
23:18:12 <jcheney> +1
23:18:15 <tlebo> +1
23:18:19 <zednik> +1
23:18:32 <satya> +1
23:18:38 <Luc> q+
23:18:38 <Paolo> +1
23:18:46 <pgroth> accepted: the domain of hadLocation is the union entity, activity, agent and instantaneous event 
23:19:03 <pgroth> ack Luc
23:19:58 <CraigTrim> Luc: in terms of reconciling PROV-DM and PROV-O - properties of atLocation
23:21:46 <Curt> I am not my name
23:22:35 <CraigTrim> pgroth: any other issues on PROV-DM? bring up now ...
23:22:41 <pgroth> q?
23:22:53 <satya> sorry, I have to leave now - will join in tomorrow
<pgroth> Topic: Last Call Straw Poll
<pgroth> Summary: The group took a straw poll on the release of PROV-DM and and PROV-O as last call after all discussed changes technical changes were made. There was unanimous support. 
23:23:22 <CraigTrim> pgroth: can't vote on going to last call right now, but prefer straw poll given decisions made today on various technical issues will we move to last call once these are implemented?
23:23:22 <Zakim> -Satya_Sahoo
23:24:14 <pgroth> straw poll: move to last call if all resolutions on the listed technical issues identified at F2F3 are implemented
23:24:21 <TomDN> +1
23:24:22 <reza_bfar> +1
23:24:22 <Curt> +1
23:24:25 <tlebo> +1
23:24:25 <jcheney> +1
23:24:25 <Dong> +1
23:24:27 <dcorsar_> +1
23:24:29 <khalidBelhajjame> +1
23:24:37 <jcheney> q+ to ask about where we left ctx'n
23:24:42 <Paolo> I agree!
23:25:03 <zednik> +1
23:25:10 <CraigTrim> jcheney: was ctx'n left at renaming and change to definition?
23:25:16 <CraigTrim> pgroth: confirmed, plus marking as at risk
23:26:48 <pgroth> Topic: PROV-O
<pgroth> Summary: The group discussed what was remaining to be left on prov-o. The focus was on ensuring that the ontology was up to date with the data model and more needs to be done on the narrative. A discussion was had on whether the constraints as defined by the prov-constraints document should be encoded in prov-o. It was noted both that the constraints document was still under some flux and that that prov-o should support anything that was compliant with prov-dm. The group resolved that constraints that do not appear in prov-dm should not be encoded in prov-o. 
23:26:51 <CraigTrim> Luc: what do we need to do to get to last call on PROV-O?
23:27:07 <CraigTrim> tlebo: will release a document for internal review
23:27:47 <CraigTrim> tlebo: work up to yesterday's deadline was making modifications to Ontology for ctx'n and back-checking all examples to fill in re-names
23:28:22 <CraigTrim> tlebo: the narrative hasn't moved, couple issues to incorporate - principally fixing DM moves progress on PROV-O
23:28:37 <CraigTrim> tlebo: beyond that making sure constructs (terms) are discussed within narrative
23:28:40 <pgroth> q?
23:28:47 <pgroth> ack jcheney 
23:28:47 <Zakim> jcheney, you wanted to ask about where we left ctx'n
23:29:45 <CraigTrim> Luc: we have agreed on number of changes in DM today which will be added back into Ontology
23:29:48 <jcheney> q+ to ask if prov-rdf wiki page is still relevant (e.g. it doesn't mention ctx'n or bundles)
23:30:04 <CraigTrim> tlebo: timetable is July 13th
23:31:48 <CraigTrim> Luc: can we add additional resources to expedite timetable
23:32:08 <CraigTrim> Luc: July 13th as internal release date compresses remaining timeframe
23:32:40 <CraigTrim> Luc: We want sync'd release of PROV-DM and PROV-O
23:32:52 <pgroth> q+
23:33:06 <CraigTrim> jcheney: how much work remains?
23:33:19 <jcheney> That's not me :)
23:33:28 <jcheney> (it's zednik)
23:33:32 <CraigTrim> CraigTrim: my bad
23:33:49 <pgroth> s/jcheney/zednik/
23:34:10 <Luc> q?
23:34:33 <CraigTrim> tlebo: todo list is number of constructs in Ontology, and if construct is not mentioned in narrative, it is remaining work
23:34:44 <Luc> ack jch
23:34:44 <Zakim> jcheney, you wanted to ask if prov-rdf wiki page is still relevant (e.g. it doesn't mention ctx'n or bundles)
23:36:17 <CraigTrim> pgroth: we can go to last call with less than polished narrative as long as Ontology is fixed
23:36:32 <CraigTrim> pgroth: when can we get a fixed Ontology and who will help with narrative
23:36:45 <CraigTrim> pgroth: but if Ontology is done and narrative lags, we should keep moving ahead
23:37:07 <Luc> q?
23:37:11 <Luc> ack pg
23:37:13 <pgroth> ack pgroth
23:37:26 <CraigTrim> Luc: are there volunteers to work with tlebo?
23:38:01 <pgroth> q?
23:38:45 <zednik> I can work with Tim on prov-o
23:39:37 <CraigTrim> Luc: if parties that can contribute time specify when we can work out timetable based on availability
23:41:55 <Luc> q?
23:42:14 <CraigTrim> Luc: anything else we can discuss about PROV-O in order to get to last call?
23:42:49 <CraigTrim> tlebo: one aspect not personally focused on is property type (irreflexive, functional, etc)
23:43:18 <CraigTrim> tlebo: concerned about some constraints documents but no specific examples to raise
23:46:39 <Luc> q+ to ask if prov-o is about scruffy or proper provenance
23:48:29 <pgroth> q+
23:48:35 <Luc> ack luc
23:48:35 <Zakim> Luc, you wanted to ask if prov-o is about scruffy or proper provenance
23:49:45 <Luc> q?
23:49:51 <pgroth> q-
23:49:53 <CraigTrim> pgroth: constraints can be implemented in a variety of methods, but Ontology should remain scruffy
23:49:58 <zednik> q+
23:50:24 <Luc> ack pg
23:50:28 <Luc> ack ze
23:50:34 <CraigTrim> zednik: are constraints part of recommendation?
23:50:35 <Paulo> Paulo has joined #prov
23:50:42 <CraigTrim> Luc: forms a separate recommendation
23:51:05 <jcheney> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-constraints.html#compliance
23:51:12 <CraigTrim> Luc: eg. "in order to validate PROV the following constraints should be satisfied..."
23:51:41 <Paulo> q+
23:52:19 <CraigTrim> jcheney: several reviewers have noted document lacked clarity in past around compliance w/respect to constraints
23:52:27 <Luc> ack pau
23:55:21 <Paulo> q+
23:57:19 <CraigTrim> Luc: is it a resolution of this meeting that the constraints should not be put in the ontology?
23:57:24 <Luc> q?
23:57:28 <CraigTrim> tlebo: does that include the subProperty hierarchy?
23:57:30 <pgroth> q+
23:57:34 <Luc> ack pau
23:58:40 <TomDN> +q
23:58:44 <CraigTrim> Paulo: we want to make sure people have certain level of correctness when generating PROV
23:58:54 <tlebo> q+ to ask if prov-o loses its subproperty hierarchy in b/c of a strict "DM-only, no prov-constraints!" encoding.
23:58:54 <Luc> q?
23:59:11 <CraigTrim> Paulo: don't think we can provide PROV validator, but should have some level of syntax checking
23:59:29 <CraigTrim> jcheney: no point in standardizing something that is non-decidable 
23:59:55 <Luc> q?
00:01:08 <Luc> q?
00:01:24 <Paolo> q?
00:01:29 <Luc> ack pg
00:01:42 <CraigTrim> pgroth: maintain subProperty hierarchy in PROV-O since it exists in DM
00:01:55 <tlebo> q-
00:02:07 <Luc> q/
00:02:09 <Luc> Q?
00:02:15 <TomDN> q-
00:02:15 <pgroth> ack luc
00:03:05 <Luc> proposed: constraints that don't appear in prov-dm should not be encoded in the ontology
00:03:10 <jcheney> +1
00:03:12 <TomDN> +1
00:03:14 <khalidBelhajjame> +1
00:03:17 <CraigTrim> +1
00:03:18 <Curt> +1
00:03:19 <dcorsar_> +1
00:03:19 <Paolo> +1
00:03:26 <zednik> +1
00:03:31 <tlebo> +.98
00:03:32 <Dong> +1
00:04:00 <Luc> accepted: constraints that don't appear in prov-dm should not be encoded in the ontology
00:04:35 <Paulo> q?
00:05:07 <Curt> I would word it "It should be possible to express anything compliant with the DM using the ontology"
00:05:19 <pgroth> +1 for curt
00:05:31 <pgroth> +q
00:05:47 <Luc> q?
00:06:01 <TomDN> That's exactly what makes it a nice line between syntactic validity and "semantic" validity
00:06:22 <Luc> q?
00:06:22 <TomDN> (or "constrained" validity, whatever)
00:06:29 <Luc> ack pg
00:06:56 <jcheney> Since the constraints & inferences are still allowed/encouraged, in a REC, I don't think we lose anything here - just observe that there is an instance of PROV-O that bakes them in
00:07:11 <Paulo> q+
00:07:42 <Curt> (keep a CM tag for the version of the .owl just prior to removing all the constraints)
00:08:59 <TomDN> topic: PROV-N
<pgroth> Summary: The group was asked for any relevant technical issues on prov-n. Two were identified. The possible ramifications for internationalization and what the mimetype should be. Ivan was actioned to look into internationalization and the group agreed that the mimetype should be text/prov-n.
00:10:06 <Paolo> q+ to make a point later on prov-constraints regarding validation 
00:10:12 <TomDN> Paulo: about PROV-CONSTRAINTS: could we have a notion of "well-formed"-ness
00:10:18 <pgroth> q+
00:10:23 <TomDN> Luc: Back to PROV-N: any issues?
00:10:29 <Luc> ack pau
00:10:40 <Luc> ack pao
00:10:40 <Zakim> Paolo, you wanted to make a point later on prov-constraints regarding validation
00:11:33 <TomDN> pg: for internationalization: we can go to LC, and ask internationalization responsibles if it's allright
00:11:51 <TomDN> ... or how we can do it
00:12:01 <pgroth> action: ivan to check when we should do internationalization and how for PROV-N
00:12:01 <trackbot> Created ACTION-94 - Check when we should do internationalization and how for PROV-N [on Ivan Herman - due 2012-06-30].
00:12:17 <TomDN> Luc: In an earlier version there was a language tag over Strings, and it was removed
00:12:27 <TomDN> ... Any technical issues?
00:12:31 <Luc> q?
00:12:47 <pgroth> ack pgroth
00:13:02 <TomDN> Luc: There is an issue for LC, that a MIMETYPE is used, a request needs to be put in
00:13:20 <TomDN> s/a MIMETYPE/if a MIMETYPE
00:13:46 <TomDN> Luc: 1st question: is the group fine with a MIMETYPE in PROV-N?
00:13:53 <Luc> q?
00:13:56 <TomDN> Luc: 2nd question: are we happy with the name?
00:14:06 <pgroth> text/prov-n
00:14:21 <Luc> q?
00:14:52 <jcheney> q+ to ask why not text/prov
00:15:00 <TomDN> tlebo: we're already covered for RDF types (existing stuff out there)
00:15:18 <TomDN> jcheney: why not text/prov ?
00:15:38 <tlebo> q+
00:15:38 <Luc> q?
00:15:40 <hook> q+
00:15:42 <TomDN> ... It automatically maps to prov-n
00:15:44 <Luc> ack jche
00:15:44 <Zakim> jcheney, you wanted to ask why not text/prov
00:16:00 <TomDN> tlebo: recommend keeping the n
00:16:16 <TomDN> ... because of the various ways to specify provenance
00:16:18 <tlebo> q-
00:16:23 <Luc> ack tl
00:16:24 <TomDN> +1 tlebo
00:16:34 <TomDN> hook: +1  tlebo
00:16:57 <Luc> q?
00:16:57 <TomDN> ... imagine prov-json etc
00:17:01 <Luc> ack hoo
00:17:12 <TomDN> jcheney: I planned for this! hahah!
00:17:24 <TomDN> ... (and you matched my expectations)
00:17:37 <Luc> accepted: mime type for prov-n is text/prov-n
00:18:04 <Luc> q?
00:18:12 <TomDN> Topic: PROV-CONSTRAINTS
<pgroth> Summary: James asked whether the current whether the current approach for prov-constraints was acceptable? There was general consensus that a constraints document was important to have for the creation of validators for PROV. There was a concern raised about defining constraints that were undecidable. The group resolved that the constraints defined in the prov-constraints document should be decidable. 
00:18:20 <hook> text/prov-{textual encoding scheme}
00:18:37 <TomDN> Luc: coming back to the compliance section
00:19:08 <Dong> @hook the MIME type for JSON is application/json
00:19:13 <TomDN> jcheney: We need a clear idea whether there is consensus if something like what we have now is acceptable
00:19:53 <Dong> @hook I don't think we should have new MIME types for XML, JSON, and RDF
00:20:06 <Luc> q?
00:20:15 <TomDN> ... so maybe more people should read it
00:20:36 <tlebo> @dong (is there a mimetype for xml?)
00:21:14 <pgroth> q+ to say what constraints doc is important for
00:21:24 <TomDN> ... To respond to Paulo's question (is it feasible to check validity?): we shouldn't include anything that's impossible to check computationally
00:21:24 <Dong> tlebo: I thought it was application/xml
00:21:36 <Curt> prov-json is more specific (more tightly defined) than application/json e.g.
00:21:42 <TomDN> ... So nothing undecidable
00:21:48 <tlebo> @dong, ya. application/xml
00:22:21 <TomDN> ... I've tried to organize things in terms of inferences and definitions you can comply with
00:22:40 <TomDN> ... We still need to specify what to do with optional arguments
00:22:55 <TomDN> ... We may want uniqueness constraints.
00:23:20 <zednik> @Don, tlebo: application/xml and text/xml
00:23:21 <zednik> s/Don/Dong
00:23:34 <TomDN> ... We also want to be able to say that some things are not allowed. (like cycles and stuff)
00:24:27 <TomDN> ... We also might want some normalization in there
00:24:43 <Luc> q?
00:24:47 <TomDN> ... So there are both technical and representation issues remaining.
00:25:06 <TomDN> Paulo: Are the PROV- documents intended to be distributed?
00:25:42 <TomDN> s/documents/descriptions
00:25:53 <TomDN> s/PROV-/provenance
00:25:57 <Luc> q?
00:26:25 <TomDN> jcheney: yes, but it's up to the asserter to specify this
00:26:31 <Zakim> - +1.805.893.aaaa
00:26:32 <Zakim> SW_(PROV)12:00PM has ended
00:26:32 <Zakim> Attendees were +1.805.893.aaaa, Satya_Sahoo
00:26:37 <tlebo> @jcheney, as it should be "it's up to the reader to decide" what circumscribes the assertions.
00:26:45 <tlebo> +1 @jcheney
00:26:49 <Luc> q?
00:26:58 <TomDN> Paolo: it's basicly validating a set of assertions, regardless of where they are
00:27:25 <Luc> q?
00:27:28 <TomDN> pg: We addressed the distributed validation pretty well with validators in the Semantic Wev
00:27:32 <TomDN> s/Wev/Web
00:27:37 <zednik> zednik has joined #prov
00:27:51 <TomDN> pg: This document is very important for building a validator
00:28:08 <jcheney> Can we collect the feedback from developers somewhere?
00:28:23 <TomDN> ... it's part of the compromise of scruffiness
00:28:29 <TomDN> ... to have a validator
00:28:36 <TomDN> +q
00:28:50 <Paulo> q+
00:28:58 <Dong> +1 to validator
00:29:22 <Dong> q+
00:29:26 <Luc> ack to
00:29:33 <jcheney> As I unerstand it there will have to be implementations of validation for the prov-constraints to proceed on REC track
00:29:49 <pgroth> but they work - good enough
00:29:49 <TomDN> tomdn: So that corresponds to what Luc said before, a validator is one of the implementations we really want to have
00:30:00 <TomDN> ,,, and the CONSTRAINTS are the basis for that
00:30:04 <Paolo> q+
00:30:10 <TomDN> ... and the CONSTRAINTS are the basis for that
00:30:18 <Luc> ack pau
00:30:32 <TomDN> ... so everything should be computable (cfr. jcheney)
00:30:45 <pgroth> something like http://inspector.sindice.com/
00:30:57 <tlebo> @paulo, not enough prior art for us to standardize. You're expressing practical concerns that are application-specific, which we can't help as a WG.
00:31:04 <TomDN> Paulo: we can't impose a closed world assumption
00:31:10 <Luc> ack do
00:31:39 <TomDN> dong: I like the idea of the 2 levels of compliance, syntactic and "semantically"valid
00:31:59 <Luc> q?
00:32:19 <pgroth> ack paolo
00:32:21 <TomDN> kind of like HTML strict, right?
00:32:22 <jcheney> Just to be clear, curently VALID means "satisfies all constraints" 
00:32:31 <TomDN> (kind of)
00:33:01 <Luc> q?
00:33:03 <tlebo> +1 @paolo "distribution is a secondary problem" that distracts from a validator.
00:33:23 <TomDN> paolo: There's a good basis for this validation (ignoring the distribution issues), combined with what's out there
00:33:24 <Luc> q?
00:33:30 <pgroth> q+
00:33:33 <Paulo> coonstraints and best practices may be co-designed
00:34:24 <TomDN> Luc: So I don't see technical objections raised against the compliance section, except maybe the 2 levels of validation
00:34:40 <Luc> q?
00:34:54 <TomDN> jcheney: agreed
00:34:55 <Luc> ack pg
00:34:57 <dcorsar> dcorsar has joined #prov
00:35:17 <Curt> I would call the levels "DM compliant" and "CONSTRAINTS compliant"
00:35:21 <Luc> q?
00:35:34 <TomDN> pg: I think it's fine to say there's only one level of validity, but that the validator has levels of response
00:35:37 <Paulo> q+
00:36:01 <TomDN> ... it's up to implementer of the validator, not to us
00:36:08 <Luc> q?
00:36:15 <TomDN> jcheney: agreed
00:36:37 <Curt> q+
00:36:40 <Luc> ack pau
00:36:49 <Paolo> q+
00:37:13 <TomDN> Paulo: Validating everything at once is very hard, but smaller parts might be feasible
00:37:35 <Luc> ack cu
00:37:36 <pgroth> q+
00:37:49 <TomDN> Curt: I would define the levels of compliance with DM and CONSTRAINTS separatly
00:38:13 <Luc> q?
00:38:16 <Luc> ack pao
00:38:39 <TomDN> Paolo: It's not clear to me if there are problems with the decidability of the constraints
00:39:23 <TomDN> Paolo: The technical discussion should be had offline, before dismissing the document
00:40:08 <Luc> q?
00:40:12 <Luc> ack pg
00:40:17 <TomDN> +q to ask if we should just make this a reviewer question: Are there things in the document that lead to undecidability?
00:40:46 <Luc> q?
00:40:46 <TomDN> Luc: maybe it shouldn't be called CONSTRAINTS, but VALIDITY?
00:40:59 <Luc> ack tom
00:40:59 <Zakim> TomDN, you wanted to ask if we should just make this a reviewer question: Are there things in the document that lead to undecidability?
00:41:27 <jcheney> q+
00:42:08 <TomDN> Luc: i don't hear objections to the compliance section, on the contrary, there is large support for it
00:42:36 <Luc> ack jch
00:42:57 <TomDN> jcheney: Could use some help in editing the constraints
00:43:14 <TomDN> ... but input such as today's is valuable
00:43:56 <TomDN> ... We should keep in mind: There's no point in standardizing something that's not computable.
00:44:47 <TomDN> ... Would be happy with a proposal to comfirm this.
00:45:15 <Paulo> q+
00:45:22 <Luc> proposed: prov-constraints document should ensure decidability of constraints
00:45:26 <TomDN> +1
00:45:27 <jcheney> +1
00:45:29 <khalidBelhajjame> +1
00:45:30 <tlebo> +1
00:45:33 <zednik> +1
00:45:33 <dcorsar> +1
00:45:34 <Dong> +1
00:45:38 <Curt> +1
00:45:41 <TomDN> actually, +MAX_INT
00:45:54 <Luc> accepted: prov-constraints document should ensure decidability of constraints
00:46:18 <Luc> q?
00:46:41 <pgroth> trackbot end telcon
00:46:45 <khalidBelhajjame> bye
00:46:54 <pgroth> rrsagent, make logs public
00:47:39 <pgroth> rrsagent, draft minutes
00:47:39 <RRSAgent> I have made the request to generate http://www.w3.org/2012/06/23-prov-minutes.html pgroth
00:47:51 <pgroth> rrsagent, set logs public
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00001516