Chatlog 2012-02-02

See original RRSAgent log or preview nicely formatted version.

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

08:14:33 <RRSAgent> RRSAgent has joined #prov
08:14:33 <RRSAgent> logging to http://www.w3.org/2012/02/02-prov-irc
08:14:35 <trackbot> RRSAgent, make logs world
08:14:35 <Zakim> Zakim has joined #prov
08:14:37 <trackbot> Zakim, this will be 
08:14:37 <Zakim> I don't understand 'this will be', trackbot
08:14:38 <trackbot> Meeting: Provenance Working Group Teleconference
08:14:38 <trackbot> Date: 02 February 2012
08:14:41 <smiles> smiles has joined #prov
08:14:47 <Luc> Zakim, this will be PROV 
08:14:47 <Zakim> ok, Luc, I see PROV_f2f()3:00AM already started
08:15:16 <Luc> Agenda: http://www.w3.org/2011/prov/wiki/Meetings:F2F2Timetable
08:15:41 <Zakim> +[VrijeUni]
08:15:56 <kai> Zakim, who is on the phone?
08:15:56 <Zakim> On the phone I see +1.315.724.aaaa, [VrijeUni]
08:16:15 <pgroth> pgroth has joined #prov
08:16:17 <Luc> Chair: Luc Moreau
08:16:24 <tlebo> zakim, aaaa is me
08:16:24 <Zakim> +tlebo; got it
08:17:13 <Luc> rrsagent, make logs public 
08:17:16 <khalidbelhajjame> khalidbelhajjame has joined #prov
08:17:36 <Luc> scribe: Simon Miles
08:17:38 <dgarijo> dgarijo has joined #prov
08:17:52 <Luc> Topic: Introduction
<pgroth> Summary: A status report was given by Luc. It was noted that good progress since the first f2f was made however there has been a slow down in progress because of redebating of issues and complexity. The group is deviating from the timetable and needs to re-adjust it's ambition and timetable. To address these concerns a new timetable was proposed and resolved. In terms of process, any content causing slippage from the timetable (i.e. issues not being resolved) will will be candidates for removal. The timetable will be extended by three months. The proper W3C processes will needed to be followed.
08:17:52 <smiles> Scribe: smiles
<pgroth> Guest: Ivan (ivan) Herman, W3C
08:18:22 <pgroth_> pgroth_ has joined #prov
08:18:38 <smiles> Luc: good morning
08:19:21 <smiles> Luc: round of introductions
08:19:41 <smiles> On the phone: Tim
08:20:41 <tlebo> at the table: daniel, simon, khalid, ivan,
08:20:42 <smiles> Ivan: introduces himself
08:21:43 <smiles> Luc: first, need to approve minutes of last call
08:21:45 <pgroth> minutes  http://www.w3.org/2011/prov/meeting/2012-01-26
08:21:46 <GK> GK has joined #prov
08:22:09 <Paolo> Paolo has joined #prov
08:22:21 <jcheney> jcheney has joined #prov
08:22:49 <pgroth> Proposed: accept minutes of January 26, 2012 telecon
08:22:51 <khalidbelhajjame> +1
08:22:52 <dgarijo> +0 ( I wasn't there)
08:22:54 <tlebo> +1
08:22:54 <Paolo> +1
08:22:55 <kai> +1
08:22:58 <jcheney> +1
08:23:09 <smiles> +1
08:23:41 <pgroth> accepted minutes of January 26, 2012 telecon
08:24:02 <smiles> Luc: welcome
08:24:42 <smiles> ... Have some observations from chairs to start
08:24:47 <GK> http://www.w3.org/2011/prov/wiki/F2F2Intro
08:25:37 <smiles> ... From initial 17 words, we have made really good progress
08:26:10 <smiles> ... However, deviation from timetable, was hoping to release last call at 9 months
08:26:34 <smiles> ... See redebating of issues and drop in attendance
08:26:58 <smiles> ... We would like to address these
08:27:26 <smiles> ... Have some feedback, that the model is too complex
<pgroth> subtopic: Comments from Ivan
<pgroth> Summary: Ivan gave his perspective. He encouraged the group to simplify focusing on the core semantic web and linked data community. He emphasized that we should focus on making prov-o OWL-RL compatible. He also noted that we should use turtle for examples as that facilitates uptake.
08:28:45 <smiles> Ivan: concern is for use in semantic web community, realising most active part is linked data community
08:29:17 <smiles> ... Complex OWL ontolgies are only niche areas
08:30:41 <smiles> ... Experience with two past WGs, tried to be good for everyone, end up being ignored even though recognised useful topic
08:31:03 <Paolo> Paolo has joined #prov
08:31:04 <Luc> Luc has joined #prov
08:31:30 <smiles> ... Also OWL2, technically good but uptake poor, triple stores use an implementable subset
08:35:28 <pgroth> +q
08:35:29 <dgarijo> Ivan: maybe we have to think in profiles
08:35:39 <dgarijo> ... something simple that can be extended
08:36:01 <dgarijo> ... and it is more simple and reusable by the community
08:36:15 <pgroth> ack proth
08:36:17 <dgarijo> pgroth: the concepts from DM are adopted from those places.
08:36:18 <pgroth> ack pgroth
08:36:32 <dgarijo> ivan: is every concept of DM necessary?
08:36:55 <dgarijo> luc: there are interoperability issues that are not yet addressed
08:37:01 <smiles> smiles has joined #prov
08:37:17 <Luc> q?
08:37:36 <dgarijo> ivan: I took olaf and jun's voc as an example
08:37:48 <dgarijo> ... when I look at it I say: I get i
08:37:54 <dgarijo> t
08:38:12 <stain> q+
08:38:37 <smiles> Ivan: would prefer to have whole spec in terms of rdf, possibility of linked data profile
08:38:59 <Luc> q?
08:39:57 <GK> q+ to respond to Luc's comment about interoperability
08:40:15 <stain> Ivan: PROV-O is simple - OWL-RL-like - Keep it like that!
08:40:20 <stain> Ivan: RDFS with a tiny bit of OWL
08:40:25 <dgarijo> +q
08:40:29 <smiles> ...with regards to prov-o, impression is that ontology is actually simple, which is good, but should be made clear that
08:41:10 <smiles> ... this is owl-rl
08:41:27 <stain> Ivan: Pleease, don't use RDF/XML
08:41:32 <stain> stain: +1 +1 +1 +1
08:41:34 <tlebo> :-)
08:41:59 <smiles> ... Please do not use rdf/xml, our concern is not owl reasoners and is not readable
08:42:43 <smiles> ...use a time ontology in provo, but it is a draft not followed up
08:42:47 <stain> Ivan: Turtle should hopefully be standardized by then
08:43:27 <GK> (I'm very sympathetic with don't use RDF, but I'd like to ask Ivan about where the wind is blowing w.e.
08:43:43 <GK> ... w.r.t. a preferred format for RDF interchange.)
08:43:51 <smiles> ... Rdf group had discussion about time, pat hayes looking at time vocabulary, may be a way forward
08:44:44 <Luc> q+
08:44:51 <Luc> ack luc
08:44:55 <smiles> Luc: thanks for the input
08:44:56 <GK> ack stain
08:45:42 <tlebo> @GK, RDF__/XML__ 
08:45:48 <smiles> Ivan: reading provo at moment, have to go to dm, should be self standing owl docuement
08:46:07 <smiles> ...  Go to dm for details if needed
08:46:19 <Paolo> q?
08:46:20 <GK> ack  GK
08:46:21 <Zakim> GK, you wanted to respond to Luc's comment about interoperability
08:46:21 <smiles> ... Starting point owl document
08:46:25 <Paolo> q+
08:47:33 <smiles> GK: regarding interoperabiltiy, when creating standards cant solve every interoperability problem, have to start with big ones
08:48:00 <dgarijo> dgarijo has joined #prov
08:48:18 <Luc> q/
08:48:21 <Luc> q?
08:48:32 <tlebo> ivan: "what exactly do you mean by XXXX"?
08:48:52 <GK> @tlebo s/XXXX/interoperability/
08:49:16 <Luc> ack dg
08:49:19 <stain> tlebo: fast action on you :) (PROV-ISSUE-231)
08:49:31 <Luc> ack pao
08:49:50 <stain> in fact OWL-wise it's almost removed already as we've redeclared the few elements we're using.. we just need to change the prefix
08:50:14 <GK> q+ to ask what are the "high order bit" questions we need to address
08:50:36 <tlebo> @stian, I'm surprised I didn't submit the "NO RDF/XML" issue first :)
08:50:54 <GK> q+ to mention past experience (Internet fax)
08:51:15 <smiles> Paolo: appreciate comments, accept simplification needed, but worried that taking Jun and Olafs document as ideal means not being as ambituous and not addressing wider community
08:51:30 <Luc> in this WG, there is a lot of prior art which is not just linked data!
08:51:49 <dgarijo> @tlebo: we discussed this. Weren't you and I supposed to add the exmaples in turtle?
08:52:47 <dgarijo> now we have an additional motivation to convince satya :D
08:53:19 <smiles> Luc: paul and I feel that work around concepts in DM are blocking other work, so would like to conclude discussions on entities, identifiers etc.
08:53:23 <tlebo> @dgarijo, right, we never got consensus. 
08:53:58 <Paolo> q?
08:54:00 <smiles> ... Bandwidth to move to other stuff to make WG successful
08:54:28 <smiles> ... With regards to timetable, should revise to reflect ambitions we have
08:54:37 <khalidbelhajjame> khalidbelhajjame has joined #prov
08:54:44 <kai> kai has joined #prov
08:55:22 <smiles> ... But also adjust ambitions to timetable, drop concepts from initial charter
08:56:13 <smiles> ... Example use cases are not relevant to user communities 
08:56:50 <smiles> ... E.g. Concept of entity is complex because trying to address all cases
08:57:08 <smiles> ... Today 3PWD of DM being released
08:57:39 <smiles> ... Next should solve issues of entities, identifiers, accounts, alternateOf
08:58:00 <smiles> ... Paul and I will propose simplification, dropping concepts
08:59:21 <smiles> ... Timetable as originally envisaged plus 3 months
09:00:15 <smiles> Ivan: admin path has to be followed, if extended need to convince that have good plan to complete work, i.e. be far enough in pipeline
09:00:54 <Luc> q+
09:00:57 <Luc> ack gk
09:00:57 <Zakim> GK, you wanted to ask what are the "high order bit" questions we need to address and to mention past experience (Internet fax)
09:00:58 <smiles> .. Managament tougher on this than used to be
09:01:10 <Luc> ack luc
09:01:18 <smiles> GK: is model too complex or overspecified?
09:01:45 <Paolo> q+
09:01:55 <smiles> ... Corner cases can show where we can remove things from the spec
09:02:36 <smiles> ... E.g. Identifiers issue may not arise if use rdf from start rather than asn
09:03:05 <smiles> Luc: dont think this is incompatible with chairs view
09:03:38 <smiles> GK: if we declare dm done, we may still come back to the issues
09:04:28 <kai> kai has joined #prov
09:04:36 <smiles> Luc: declring dm done is wg saying done, not just editors
09:04:54 <pgroth> q?
09:04:58 <pgroth> ace paolo
09:05:01 <pgroth> ack paolo
09:05:06 <stain> but it's not easy for the WG to consider things done or not done when the editors are continually changing the draft without proper involvement of the WG
09:05:07 <smiles> pgroth: part of declaring done is anything possible to cut down
09:05:29 <tlebo> q+ to say that the wg keeping RDF as a second class citizen has made it difficult to develop prov-o
09:05:48 <stain> declaring it done is like declaring an API done - we can't go there before we've explored properly using it (otherwise we'll get the PROV version of the DOM API :) )
09:05:58 <GK> @tlebo ack.
09:06:13 <khalidbelhajjame> +q
09:06:48 <jcheney> q+ (dependencies, versioning, charter)
09:06:57 <jcheney> q- (dependencies, versioning, charter)
09:07:22 <jcheney> q+ to say something about dependencies, versioning, charter
09:08:18 <stain> would it be good to move DM to a more UML-like data model?
09:08:19 <dgarijo> paolo: you don't want to leave out part of the community because you'll miss an oportunity.
09:08:34 <dgarijo> tim: I find it difficult because RDF is a second citizen
09:08:46 <Luc> q?
09:08:49 <Luc> ack tle
09:08:49 <Zakim> tlebo, you wanted to say that the wg keeping RDF as a second class citizen has made it difficult to develop prov-o
09:08:59 <Luc> ack kh
09:09:05 <kai> kai has joined #prov
09:09:24 <smiles> smiles has joined #prov
09:09:32 <stain> +1 to Paolo's suggestion - basically he was suggesting a more iterative process where PROV-O feeds into PROV-DM in a loop rather than the current one-way development
09:09:34 <GK> BTW, notwithstanding my comments, I'm not opposed to having ASN, but I think it could be presented more simply, maybe with less specification detail.  Just saying.
09:09:49 <Luc> q?
09:09:55 <dgarijo> khalid: instead of trying to simplify DM I'd leave as it is now and identify the concept that are difficult to represent in OWL and simplify them afterwards
09:09:58 <Luc> ack jc
09:09:58 <Zakim> jcheney, you wanted to say something about dependencies, versioning, charter
09:10:06 <smiles> @dgarijo i am back, will continue scribing
09:10:27 <dgarijo> @smiles: ok!
09:10:30 <tlebo> +1 to parallel / two way development. all of the wg should be thinking in ASN and PROV-O. PROV-O can't just fall out of DM.
09:11:08 <smiles> jcheney: since dm developed first, been hard to keep ontology up, but was useful to start without owl details
09:11:20 <ivan> q+
09:11:54 <tlebo> BTW, there's a very big difference between encoding in RDF and getting hung up in OWL.
09:11:56 <Luc> q?
09:12:16 <smiles> ... Point 2, for entities could now take rdf resources view, as alternateof etc controversial may not be part of stantdard
09:12:30 <jcheney> PIL should      be applicable to any resource, not just for Semantic Web objects;     have a low entry point to facilitate widespread adoption, and makes it easy to do simple things;     have a small core model and allow for extensions (ie, profiles, integration of other more expressive/complementary vocabularies/frameworks);
09:12:40 <smiles> ... Also, would be good to look at charter above
09:12:54 <Luc> q?
09:12:58 <Paolo> Paolo has joined #prov
09:13:03 <tlebo> @jcheney "Semantic Web objects" are "any resource"
09:13:39 <Luc> ack iv
09:13:42 <jcheney> @tlebo: That was a quote from the charter, not my wording: http://www.w3.org/2011/01/prov-wg-charter#scope
09:14:11 <tlebo> @jcheney, thx.
09:14:14 <smiles> Ivan: on time, spent hour yesterday in rdf wg, ended up looking for simple proposal, else could contnue for couple of years
09:14:23 <GK> We could follow@jcheney's suggestion - focus on just expressing provenance with an implicit assumption of  non-variability and punt the rest (my interpretation).  I think that would be a reasonable approach, as the the rest of the details could be filled in later.
09:14:24 <stain> it takes time even for us who have been in the WG since the beginning
09:15:06 <smiles> Luc: definite views - linked data view, owl view, more than sw view
09:15:31 <smiles> ... If reasonable, pragmatic can meet timetable
09:16:29 <tlebo> (what was that example?)
09:16:33 <GK> I don't think anyone said prov-o was 2nd class.  Rather, I thought the comment was that RDF syntax was 2nd class.
09:16:35 <smiles> ... Work of PROVO team is not second class, need to work in way which makes ths clear
09:17:54 <smiles> ... Meeting timettable may need dropping use cases, also should be based on prior art as standrdisation not research
09:17:55 <ivan> q+
09:17:57 <stain> (as a side-note - we went for OWL Time because we first wanted to say that we don't want to restrict how time is specified (like Plan and Role) - but then needed to have a realistic mapping to XSD DateTime - OWL Time allowed both - and also gave a way to talk about partially ordered events (as discussed, but perhaps not practicsed, in DM)
09:18:20 <GK> I'm not convinced dropping "use cases" is enough.  I think we need to lower levels of specification detail in some areas.
09:18:33 <smiles> ... Chairs will rely more on W3c processes
09:19:08 <smiles> Paul: have been too laid back so far, e.g. Issues open for months
09:19:25 <dgarijo> dgarijo has joined #prov
09:19:41 <smiles> Ivan: each rdf wg call starts with open issues, why not addressed
09:20:02 <smiles> Luc: we also do that, but do not enforce completion
09:20:29 <smiles> Ivan: once issue closed do not reopen unless there is new evidence
09:20:30 <Luc> q?
09:20:51 <Luc> ack ivan
09:21:33 <smiles> Luc: never communicated to outsde world how to approach documents, e.g. Primer then provo
09:21:46 <Luc> q?
09:22:17 <smiles> GK: what is conclusion?
09:22:58 <smiles> Luc: strategy driven by the timetable, milestones; can refine milestones over next two days
09:23:57 <smiles> GK: if we slip from new timetable, what is strategy to get back on track?
09:24:31 <smiles> Luc: where discussion does not reach consensus, remove from spec
09:24:58 <smiles> Paul: chairs can decide out of scope
09:25:19 <smiles> Ivan: easier to drop from charter rather than add
09:25:40 <jcheney> q+ to ask about 17 concepts
09:25:50 <smiles> GK: agree that this is a concerete strategy
09:26:48 <Paolo> Paolo has joined #prov
09:26:54 <stain> The strategy is to be time-driven along the proposed time table [1]. In case of slippage, the issue(s) causing slippage will be a candidate for removal.  [1]http://www.w3.org/2011/prov/wiki/F2F2Intro#Revisited_Timetable 
09:27:13 <stain> ^Luc's proposal
09:27:45 <GK> +1
09:27:56 <Stian> PROPOSED: The strategy is to be time-driven along the proposed time table [1]. In case  of slippage, the issue(s) causing slippage will be a candidate for removal.   [1]http://www.w3.org/2011/prov/wiki/F2F2Intro#Revisited_Timetable 
09:27:59 <kai> +1
09:28:00 <jcheney> +1
09:28:00 <Stian> +1
09:28:01 <smiles> +1
09:28:02 <dgarijo> +1
09:28:02 <GK> +1
09:28:03 <tlebo> +1
09:28:07 <Paolo> +1
09:28:16 <Stian> s/a //
09:28:34 <Stian> ACCEPTED The strategy is to be time-driven along the proposed time table [1]. In case  of slippage, the issue(s) causing slippage will be a candidate for removal.   [1]http://www.w3.org/2011/prov/wiki/F2F2Intro#Revisited_Timetable
09:28:44 <Stian> RESOLVED: The strategy is to be time-driven along the proposed time table  [1]. In case  of slippage, the issue(s) causing slippage will be a candidate  for removal.    [1]http://www.w3.org/2011/prov/wiki/F2F2Intro#Revisited_Timetable
09:28:48 <Stian> we'll do both
09:29:05 <smiles> Khalid: +1 (not on irc)
09:29:38 <khalidbelhajjame> khalidbelhajjame has joined #prov
09:45:31 <Luc> q?
09:45:36 <Luc> ack jc
09:45:36 <Zakim> jcheney, you wanted to ask about 17 concepts
09:45:38 <khalidbelhajjame> khalidbelhajjame has joined #prov
09:45:43 <tlebo> hello
09:45:46 <pgroth> hi
09:46:45 <GK1> GK1 has joined #prov
09:46:59 <pgroth> pgroth has joined #prov
09:47:05 <GK1> hi
09:47:10 <Luc> q?
09:47:17 <Stian> Scribe: Stian
09:47:21 <khalidbelhajjame> Session on Provenance Access and Query
<pgroth> Topic: Provenance Access and Query
<pgroth> Summary: The current status of the prov-aq document was described. Paul gave an overview of six issues he had with the document. The major issues were editiorial in nature. A key outcome was that part of the document is best practice in nature (e.g. how to use sparql to query provenance, or embedd provenance in rdfa) and other parts are a specification (e.g. how to locate provenance). The editors agreed to try and make this distinction clear. A large amount of discussion was had on the definition of provenance services. In particular, there were concerns about not allowing service specific extensions that allow clients to define how much provenance information they want back. Essentially, the service definition should allow for extensibility. Two options were discussed for the definition of a protocol for provenance service either using a WSDL approach or a url pattern approach. The editors agreed to come up with a proposal for this protocol.
09:47:28 <Luc2> Luc2 has joined #prov
09:47:32 <Stian> pgroth: some issues to address.. GK, any?
09:47:43 <smiles> smiles has joined #prov
09:47:45 <Stian> GK1: Mainly notes within the document, or issue list. 
09:47:59 <Stian> pgroth: Have 6 issues
09:48:08 <Stian> pgroth: 1) Have a current service description
09:48:24 <jcheney> jcheney has joined #prov
09:48:25 <Stian> ... Uses an IETF Draft spec on how we define the service description
09:48:32 <Stian> GK: Template stuff
09:48:39 <Stian> GK: Close to becoming an IETF standard
09:48:50 <Stian> pgroth: minor technical issue.. second was that we have to do multiple lookups
09:49:01 <Stian> pgroth: you have to dereference the service specification, understand it, and then do the thing
09:49:22 <Stian> pgroth: Luc suggested on Sparql. They define a WSDL document that defines the way you get SPARQL or not
09:49:33 <tlebo> WSDL died by SPARQL 1.1, no?
09:49:45 <Stian> pgroth: one suggestion is to revisit the service specification and concretize it as a WSDL specification
09:49:56 <Stian> pgroth: and by very specific about the form of the URI should look like when you make a query
09:50:18 <Stian> GK: Have been doing other stuff
09:50:32 <pgroth> http://dvcs.w3.org/hg/prov/raw-file/default/paq/prov-aq.html#provenance-services
09:50:38 <Stian> pgroth: section 4
09:50:52 <Stian> GK: Was not initially convinced of the need for this section! 
09:51:01 <Stian> GK: Need simplification or elimination
09:51:12 <Stian> GK: Are we just doing strategies in this session, or digging in?
09:51:22 <Stian> Luc: Identify what we as the WG should work on
09:51:28 <Stian> Luc: so we can say that we don't do anything more on this
09:51:33 <Stian> pgroth: will go through the rest of my issues
09:51:42 <Stian> pgroth: issue of definition on provenance service
09:51:46 <dgarijo> dgarijo has joined #prov
09:52:12 <Stian> pgroth: second issue, in the document we have access - how we go from a Resource to associated Provenance [Information] - section 1
09:52:32 <Stian> ... then we have queries, how they look like, guidance on sparql etc. One of my questions is wether or not they should be seprated into different documents
09:52:58 <Stian> ... something that defines a query service documentation - might be super-simple. Maybe some patterns on how to use sparql. And then a query document, where's how you go from web resource to provenance.
09:53:38 <Stian> ... Third issue is.. we have, section 3 - http://dvcs.w3.org/hg/prov/raw-file/tip/paq/prov-aq.html#locating-provenance-information
09:53:38 <Luc> wsld2.0 interface for sparql protocol: http://www.w3.org/TR/rdf-sparql-protocol/
09:53:54 <Stian> ... we have resources represented as... X   hasprovenance service and has provenance. Duplicate. 
09:54:01 <Stian> pgroth: would find that complicating
09:54:07 <Stian> GK1: was uneasy about that as well. 
09:54:14 <Stian> pgroth: Can we get rid of this duality
09:54:30 <Stian> pgroth: Fourth issue - PAQ does not say how to locate provenance information within RDFa
09:54:41 <Stian> GK1: it's implicit in RDF - how to find it in RDF, then how to find it in RDFa?
09:54:55 <Stian> pgroth: perhaps a simple example
09:55:02 <Stian> pgroth: should it be in the PAQ? 
09:55:09 <Stian> pgroth: best practice? Or in PROV-O?
09:55:45 <Stian> GK1: You mentioned best practice.. I thought this document was trying to also be best practice. We might review this.
09:55:54 <Stian> pgroth: it's clear that there is specification.. for instance link headers
09:56:06 <Stian> GK1: hoping we would go for registration of these with the IETF registry
09:56:12 <Stian> pgroth: so this is a specification
09:56:39 <Stian> (I edited best practice document on the plane to say that an RDF document can be identified as a prov:Account if it simply says <> a prov:Account
09:56:42 <pgroth> q?
09:56:47 <Stian> (which should work also for RDFa)
09:56:56 <Stian> Luc: Original charter had this in
09:57:12 <Stian> Luc: we received feedback that we have too many implementations on the timetable, so downgraded to a note
09:57:16 <Stian> ^^ as a recommendation
09:57:24 <Stian> Luc: as a WG we can define what we are tryin to achieve here
09:57:33 <Stian> GK1: Have been trying to follow what I get from the group
09:57:38 <Luc> q?
09:58:01 <Stian> pgroth: broadly the document does strike the right balance between reusing what's there, and identifying how you reuse it. But it defines clearly how you should do X,Y,Z, which to me is a specification.
09:58:07 <Stian> pgroth: it's fine if a specification is built on other work
09:58:23 <Stian> GK1: at this stage we didn't have a clear enough view of which areas we would use PROV to achieve interoperability
09:58:27 <Stian> pgroth: perhaps that's what we need to talk about
09:58:59 <Stian> GK1: which aspects of interoperability is important. You mentioned splitting the document. To me this is not as much access vs query, but here is a baseline for basic interoperability vs here are some other things you can do if the basic mechanisms don't work
09:59:06 <Stian> pgroth: sounds like a  reasonable split
09:59:13 <Stian> ... The provenance services.. 
09:59:21 <Stian> GK1: the issue you raised.. this is what? 
09:59:27 <Stian> pgroth: PAQ does not have RDFa?
09:59:37 <Stian> pgroth: where does it belong.. we moved on to wether or not PAQ is a spec. 
09:59:49 <Stian> pgroth: seems consensus is that part of it is spec and others not
09:59:59 <Stian> Stian: like "This is informal section" etc? 
10:00:02 <Stian> pgroth: or splitting
10:00:16 <Stian> pgroth: Currently we're very entity focused
10:00:34 <Stian> pgroth: there's lots of other thins in PROV-DM and in the world that we might want to do provenance of
10:00:42 <Stian> Luc: for instance, provenance of an activity!
10:00:51 <Stian> GK1: my suggestion was a refactoring of those!
10:01:22 <Stian> pgroth: first agree if we are talkina bout more than entities, if so, what can we do.. 
10:01:29 <Stian> pgroth: we are entity questions, but is that appropriate?
10:01:33 <Stian> s/question/focused/
10:01:52 <Stian> pgroth: finally: There are some paragraphs where.. 
10:02:03 <Stian> pgroth: section 2 - http://dvcs.w3.org/hg/prov/raw-file/tip/paq/prov-aq.html#accessing-provenance-information
10:02:06 <Stian> pgroth: second and last paragraph
10:02:35 <Stian> pgroth: rewrite stuff "provided that such change does not contradict any previously retrieved information" - status about provenance - get rid and don't worry about there
10:02:47 <Stian> GK1: they were put in wether a provenance retrieved is changeable or not
10:03:00 <Stian> GK1: initially it seemed to me that the intention was.. a dynamic resource, and a provenance resource
10:03:11 <Stian> GK1: then you would not expect the provenance resource to update as the dynamic resource was
10:03:27 <Stian> GK1: but as what we talked about this morning changes, this might become redundant
10:03:46 <Stian> khalidbelhajjame: the entity discussion made it useful - because now you talk about entity instead of resource
10:03:59 <Stian> khalidbelhajjame: earlier we could not distinguish them
10:04:25 <Stian> GK1: but do we need to hang so much on this discussion? It was probably an important discussion - but is this important for the presentation on how to access information about some resource?
10:04:31 <Luc> q?
10:04:33 <Stian> s/info/provenance \0/
10:04:47 <Stian> pgroth: Use the paq as saying 'There's some provenance info about this X over there'
10:05:07 <Stian> pgroth: whatever is there - we don't say anything about it - you decide if it changes etc
10:05:13 <Stian> pgroth: that's my view - agnostic
10:05:27 <smiles> q+
10:05:30 <Stian> GK1: works for me and close to where I came from. That's the web - here's some related info, go get it
10:05:54 <Stian> dgarijo: tried to write down some example from yesterday. When I am asserting provenance, I want to say some resource used another resource, do I use an entity or a resource?
10:06:00 <Stian> pgroth: that's a Data Model discussion!
10:06:17 <Stian> pgroth: in PAQ we just say "There is some related provenance information - use this URL"
10:06:39 <Stian> pgroth: Same for provenance service, here's a serrvice, here's a URL, give me some provenance back
10:06:42 <Stian> pgroth: that's what I think we have!
10:06:51 <Stian> GK1: yes, that and more! That is my minimal model.
10:07:05 <Stian> GK1: I would have stopped there - perhaps say there's SPARQL for other stuff.
10:07:14 <Stian> ivan: That's the only document I didn't have time to look at
10:07:29 <Stian> ivan: ran out of time
10:07:31 <Luc> q?
10:07:46 <Stian> ivan: how does this relate to the approach as to what people do when they try to get metadata on dataset, using the VOID vocabulary?
10:08:04 <Stian> ivan: VOID describes datasets. SPARQL (?) has another document on how to get information on a dataset
10:08:15 <Stian> ivan: perhaps provenance not the same as VOID - not sure how they are related, but somehow they are both metadata
10:08:42 <Stian> ivan: there is a Sparql service description..
10:08:50 <GK1> http://www.w3.org/TR/2010/WD-sparql11-service-description-20100126/
10:09:09 <Stian> ivan: that is only on a sparql service, here we are talking about any resource
10:09:12 <Stian> pgroth: I think that's different
10:09:22 <Stian> ivan: I'm thinking of the mechanism to get there
10:09:38 <Stian> GK1: section 2
10:09:42 <Stian> > SPARQL services made available via the SPARQL Protocol should return a service description document at the service URL. This service description should be made available in an RDF serialization, and may be provided embedded in HTML by RDFa, or other RDF representations by using content negotiation.
10:10:06 <Stian> GK1: because we are looking at a resource, and we're trying to find information at a different resource
10:10:16 <Stian> GK1: you start with an URI of a service, you need to do an indirection to get there
10:10:31 <Stian> ivan: There is an additional discussion - too bad Sandro is not here as he's in both groups
10:10:50 <Stian> ivan: We have a discussion to start a group on linked data patterns
10:10:53 <Luc> q?
10:11:01 <Stian> ivan: what came up was how in generaral do I get information about a resource
10:11:12 <Stian> ivan: that is one of the patterns, a general RESTful pattern for that
10:11:53 <Stian> ivan: If I ask for a resource, then there is a HTTP header field , Related-To or something (Existing header)
10:11:57 <Luc> q?
10:11:59 <Stian> GK1: there is a Link: header which we use
10:12:15 <ivan> http://www.w3.org/2012/01/ldwg-charter.html
10:12:19 <Stian> ivan: perhaps it's the same conclusion.. Link header, yes. 
10:12:26 <Stian> Stian: yes, so all we use is a new relation, rel=provenance
10:12:36 <Stian> (and provenance-service)
10:12:39 <Stian> ivan: check section 2.2
10:12:46 <tlebo> whcih doc?
10:12:52 <Stian> http://www.w3.org/2012/01/ldwg-charter.html
10:12:57 <tlebo> thx
10:13:03 <Stian> > Define a protocol to interact with Linked Data resources, following a REST approach ...
10:13:10 <Stian> how long?
10:13:11 <Luc> q?
10:13:14 <Stian> ivan: might take some time
10:13:32 <Stian> GK1: is there a case for taking this piece of work, and combining. Similar goals.
10:13:41 <Stian> ivan: there should be a reference to provenance WG here
10:13:47 <pgroth> - Link: provenance-URI; rel="provenance"; anchor="entity-URI"
10:13:51 <Stian> ivan: apologies for orbgetting that
10:14:04 <Stian> pgroth: that's what we do - link header on resources, there's wher eyou get related provenance information
10:14:10 <Stian> ivan: yes, that's very much in line
10:14:23 <Stian> pgroth: yes, but we have a clear semantic - you are getting back some *provenance* information
10:14:33 <Stian> pgroth: you can generalize it to just some metadata and look at the data
10:15:01 <Stian> pgroth: but GK1 pointed out that the priority is.. for us.. are we far enough along? Wait for this group? Or just define this, and later we say how they are compatible
10:15:11 <Stian> pgroth: Suggests that they will be compatible
10:15:13 <Luc> q?
10:15:30 <Luc> ack sm
10:15:36 <Stian> smiles: Slight concern with the simple provenance URI..
10:15:55 <Stian> smiles: if someone is expecting that.. provenance data model allows you to record wast amount of information if you want to
10:16:14 <Stian> smiles: if I get provenance URI in header, and I Resolve it, and I get a wast amount of information.. how to deal with it?
10:16:22 <Stian> pgroth: sounds like a techie conversation we should have now.
10:16:26 <Stian> GK1:  a kind of scoping conversation
10:16:44 <Stian> Luc: we said from day 1 that provenance is a resource that has an URI
10:16:54 <Stian> Luc: in entity view, you have a service, you run a querry
10:17:11 <Stian> Luc: when Sparql talks about sparql query results, they don't talk about them as resources. But of course you can view them as resources. 
10:17:16 <Stian> GK1: yes, if you use the GET form they are resources
10:17:22 <tlebo> lost audio
10:17:32 <Stian> Luc: but in the document it is not presented as such..
10:17:38 <Stian> Luc: in the sparql service description document
10:17:55 <tlebo> sparql query results are resource _representations_, not resources themselves.
10:17:58 <tlebo> per AWWW
10:18:00 <Stian> GK1: yes, the service is a resource, if you dereference it you get a service description - and the rest follows this. This is the web resource (?) 
10:18:14 <Stian> Luc: we were talking about provenance information as a resource
10:18:24 <Stian> GK1: it's a different resource, provenance information resource
10:18:34 <Stian> GK1: key to the resource centric approach - you have to identify what those resources as
10:18:49 <Stian> GK1: as Smiles say, there's not a predefined notion of 'provenance' - it's something I have to query
10:18:52 <Stian> ^^Luc
10:19:01 <smiles_> smiles_ has joined #prov
10:19:01 <tlebo> still silent on this end.
10:19:06 <Stian> Luc: what is the provenance, resource, entity = always had the view that I need to run a query
10:19:13 <Stian> Luc: I might not want a GB of provenance information
10:19:22 <Stian> GK1:  a resource-centric approach might not have to be done like that. 
10:19:33 <Stian> GK1: there's a resource view, and a service view - different levels
10:19:50 <Stian> GK1: web architecture is based around resources - if we design something for the web, we should try to keep this in mind
10:19:53 <Stian> q+
10:20:05 <Stian> Luc: pitching this as a resource - is not helping the presentation of the material
10:20:23 <Stian> Luc: if we want as Simon says, to control what we get.. it sounds like a client would need to formulate a kind of query?
10:20:38 <Stian> Luc: when you have a provenance URI, which is in the header, you don't have that opportunity, the query has been formulated for you
10:20:49 <Stian> GK1: there's no reason that header is not a sparql header
10:20:55 <Luc> q?
10:20:56 <Stian> Luc: but someone would have had to premade that query
10:20:59 <Zakim> -tlebo
10:21:09 <Stian> Khalid: Does not seciton 5 address this?
10:21:15 <Stian> smiles_: you might get a GB first.. 
10:21:24 <Luc> q?
10:21:24 <Stian> smiles_: imagine a user who is.. what do you get first
10:21:27 <Zakim> +tlebo
10:21:38 <Stian> GK1: do we try to define how much information gets back when you dereference?
10:21:41 <tlebo> (still quiet)
10:21:41 <Stian> smiles_: either is a solution
10:21:52 <pgroth> is anyone else on the phone?
10:22:02 <Stian> smiles_: one way is to do a query.. another way is to say there is a definite thing that comes back, that you can operate on
10:22:04 <kai> Zakim, who is on the phone?
10:22:04 <Zakim> On the phone I see [VrijeUni], tlebo
10:22:17 <Luc> q?
10:22:18 <Stian> GK1: in a sense they are both in there, Paul's eariler comment, too many mechanism
10:23:12 <Luc> q?
10:23:16 <Luc> ack stia
10:23:39 <Stian> Stian: A provenance resource is not necessarily a whole provenance account (Which truly might be many GBs) - but Linked data allows you to have many resources that you have to follow the links to
10:24:09 <Stian> pgroth: (...) for the provenance combination - there might be other people that adds the ability to filter in the service information. FOr instance ?maxEntries=200 
10:24:14 <Stian> pgroth: we should not preclude exactly this
10:24:18 <Zakim> +[IPcaller]
10:24:26 <Stian> pgroth: but we don't have enough background material as to what that looks like
10:24:28 <Luc> q?
10:24:30 <Stian> Zakim: who is making noise?
10:24:32 <tlebo> back!
10:24:33 <dgarijo> dgarijo has joined #prov
10:24:37 <kai> Thats me
10:24:45 <kai> Probably :-)
10:24:50 <Stian> pgroth: just write a paragraph that's says.. who couldn't standardize it
10:24:55 <Stian> kai: no I meant if zakim heard us :)
10:25:02 <Stian> pgroth: if everyone uses a different mechanism to filter
10:25:05 <Luc> q?
10:25:14 <Stian> smiles_: agree - we can't know how filtering might take place
10:25:22 <kai> I can't hear anything either.
10:25:32 <kai> Think we have to redial.
10:25:35 <Stian> GK1: Sympathy with this - concern is that it is not the case.. we are defining another API. Rather than following a REST approach
10:25:48 <Stian> ...
10:25:48 <tlebo> resolving URIs or submitting a URI to a service is a matter of perspective. The former paradigm reduces the "agency" of the server on the other end and minimizes the client's control. Calling a service permits the client to have more control by feeding parameters to control what comes back.
10:26:25 <Stian> GK1: Roy Fielding is specific that there is a  (...) pure restful approach - much better with exchange of information (???)
10:26:48 <Stian> GK1: internally I feel it is the web way, or do we go through the route of making an API which is perhaps simpler/more specific..
10:27:04 <tlebo> (at least now I know _who_ is talking. Just a bunch of bnodes for what they're saying...)
10:27:22 <Stian> pgroth: in SPARQL protocol, I would just copy what they do. "Here's a WSDL 2.0 file that says input/output of this thing called query - a HTTP binding says how to do it with HTTP GET
10:27:30 <Stian> GK1: which is what I attempted to do with tempaltes
10:27:41 <Stian> pgroth: doing this in SPARQL I don't have to look up service description, etc..
10:27:47 <Stian> GK1: this is the REST Tax coming in
10:27:54 <tlebo> BTW, nobody implemented the WSDL, all implementations used HTTP exclusively.
10:28:06 <Stian> GK1: one of the principles, the client should not know about the form of the URI used. It is the hyperengine as an engine of application state. 
10:28:09 <khalidbelhajjame> khalidbelhajjame has joined #prov
10:31:12 <Luc2> Luc2 has joined #prov
10:31:43 <Luc2> Q?
10:33:01 <pgroth> pgroth has joined #prov
10:33:09 <GK> GK has joined #prov
10:33:38 <khalidbelhajjame> khalidbelhajjame has joined #prov
10:34:06 <khalidbelhajjame> Luc: what is the agreement?
10:34:07 <Stian> Pgroth: Would argue for..
10:34:21 <Stian> pgroth: indirection that is currently in the document - not a good thing - not what people really want
10:34:30 <Stian> pgroth: they don't want to dereferene the service description and build a URI
10:34:41 <Stian> pgroth: notion of well known URI vs WSDL - something to discuss
10:34:42 <Stian> q+
10:34:43 <khalidbelhajjame> Paul: The notion of well known URI vs WSDL is something we should discuss
10:34:48 <Stian> khalidbelhajjame: I'm back :)
10:34:56 <khalidbelhajjame> @Stian ok :-)
10:35:00 <Stian> pgroth: sepreate out document, call it an Provenance Service API.. perhaps lightweight
10:35:04 <Stian> @Khalid thanks
10:35:24 <Stian> ivan: when I saw the word 'query' I saw a red flag
10:35:37 <Stian> ivan: I saw Query in the title.. read the document I realised.. but the title suggest something else
10:35:44 <Stian> ivan: that you can define a query language for provenance information
10:35:53 <Stian> GK: so change the title to Access and SPARQL query?
10:35:59 <Stian> ivan: just Provenance Access
10:36:13 <Stian> pgroth: two things - provenance access, current service, and then there is the Locating Proveannce Information
10:36:28 <Stian> pgroth: how to embed thins in HTML etc.. that's location
10:36:39 <Stian> pgroth: this conversation about how to access the information - we don't say anything about query
10:36:45 <Stian> GK: can't we make references to sparql?
10:36:58 <Stian> pgroth: that's a way to do it.. and what we said.. but I think that it's more looking at me as a Best PRactice
10:38:37 <Luc2> q?
10:41:17 <Luc2> Q?
10:43:40 <Luc2> Q?
10:43:48 <khalidbelhajjame> +q
10:43:49 <Luc2> Ack stain
10:43:50 <jcheney> jcheney has joined #prov
10:43:55 <Stian> pgroth: just writing some SPARQL query..
10:44:00 <Stian> (??> Insert paste here)
10:44:02 <Luc2> Ack st
10:44:27 <Stian> Khalid: how to get information about entity.. getting the URI of the sparql query. Not inetersted in URI of entity (??)  (?) 
10:44:39 <Luc2> Ack kha
10:44:50 <Stian> GK: what you want is what you want.. what you get back is an URI that refers to some provenance 
10:44:52 <Paolo> Paolo has joined #prov
10:44:59 <Stian> GK: but what do you get back when dereferencing it - that's up to the service
10:45:04 <Paolo> Q?
10:45:14 <Stian> GK: the second thing is that we can get back the ... (??) 
10:45:24 <Stian> pgroth: provenance information directly - option 1
10:45:30 <Stian> pgroth: big blob - could overwhelm you
10:45:39 <Stian> pgroth: second is, we give you a URI that refers to that provenance information
10:45:43 <Stian> pgroth: those are the two options
10:45:52 <Stian> GK: the third option - a URI for a SPARQL endpoint?
10:46:08 <Stian> ivan: as a user I have the choice of which SPARQL endpoint to use
10:46:26 <tlebo> is there objection to letting a client SPARQL the provenance service for the subset it wants?
10:46:37 <Stian> GK: two deployments.. one is a SPARQL endpoint that fronts a bit of data - the second is a general engine where you can load data and then query it
10:46:47 <Stian> ivan: then we have a different problem.. if we have a URI against a RDF resource
10:46:58 <Stian> ivan: give me those SPARQL endpoints that can query that resource
10:47:05 <Luc2> Q?
10:47:08 <Stian> ivan: not something this group can standardize
10:47:16 <Zakim> + +1.781.899.aabb
10:47:23 <Stian> pgroth: down to a lightweight service description - if Graham agrees with this
10:47:28 <Stian> pgroth: as the PAQ man!
10:47:54 <Stian> pgroth: to decide what that API/protocol should cater for - we currently have two .. descriptions
10:48:02 <Stian> pgroth: one gives provenance info, one that gives (?)
10:48:05 <Stian> pgroth: resource view of the world
10:48:14 <Stian> pgroth: dereference
10:48:25 <Stian> GK: discovery of provenance, provenance service endpoints
10:48:33 <Stian> GK: context is a bit off..
10:48:37 <Luc2> Q?
10:48:42 <Stian> GK: simple case is focus on discovery of provenance URIs
10:48:48 <Stian> GK: would be happy if that is as far as I go
10:49:02 <Stian> GK: provenance URI is something you dereference to get the provenance
10:49:13 <Stian> GK: it's a URI you dereference that gives 'a' provenance resource
10:49:39 <Stian> pgroth: what has been asked is  - if we go for this - do we allow (not define) extending that so you can make sure the client can say 'Don't vive me everything'
10:49:57 <Stian> smiles_: in the API call.. if the rquest says "Give me provenance of this" - what is returned is the provenance URI
10:50:13 <Stian> ivan: Admin issue - Sandro  is on the call - understands Paul but noone else
10:50:17 <tlebo> I skyped in via Daniel.
10:50:27 <tlebo> much clearer than the telecon phone.
10:51:00 <Stian> can you hear us better now?
10:51:17 <Stian> Sandro: Mainly using the IRC track
10:51:17 <Luc2> Q?
10:51:27 <Stian> Ivan: pgroth will call in on the other line to see if it works again
10:51:27 <tlebo> telecon phone is only useful for knowing the speaker, not what they are saying.
10:52:46 <smiles> smiles has joined #prov
10:54:09 <Stian> Luc: provenance-uri does not work for me.. say I found a resource, a provenance URI
10:54:13 <Stian> Luc2: find with how we find it
10:54:22 <kai> You could directly use Skype, maybe thats better
10:54:36 <Stian> Luc2: I download the provenance.. dereference.. then I navigate my grpah and find "Oh, there is an edge, activity mentioned in here"
10:54:48 <Stian> Luc2: then I have a provenance URI..(?)
10:55:00 <Stian> GK: so you go back to the same step with the new URI
10:55:02 <kai> My ID is cirq-kai, if you want to give it a try
10:55:18 <Stian> ivan: you have an URI, that is a resource, you go and ask for the provenance of that URI
10:55:28 <Stian> ivan: so in linked data, you find out what's there, and that's how you expose it
10:55:54 <Stian> Luc2: talkinga bout prior art.. some prior art that is not (?) (?)
10:56:02 <Stian> Luc2: no prior art covered by this usecase
10:56:24 <Stian> Luc2: a protocol for provenance addresses, resolves this
10:56:28 <Stian> ivan: what does that mean?
10:56:37 <Stian> pgroth: what you might want to do is that there is some provenance-service
10:56:43 <Stian> pgroth: you pass it an identifier.. 
10:56:43 <dgarijo> dgarijo has joined #prov
10:56:50 <Stian> ivan: "Some provenance information" is vague to me
10:57:01 <Stian> pgroth: in these protocols.. if you say some query
10:57:10 <Stian> pgroth: now I don't think we can define that provenance query language
10:57:11 <kai> Zakim, who is on the phone?
10:57:11 <Zakim> On the phone I see [VrijeUni], tlebo, [IPcaller], Sandro
10:57:27 <Stian> pgroth: however we can define the protocol to say that here's a URL - give me provenance for that
10:57:34 <Stian> ivan: but Luc does not like that?
10:57:48 <Stian> pgroth: but you can extend that with non-standard service-specific query mechanisms if I want to
10:57:58 <Stian> pgroth: two ways - linked data approach, dereference data information - get something back
10:58:04 <Stian> pgroth: look through.. clear provenance service
10:58:30 <Stian> pgroth: give me information about this URI.. browsing through provenance info.. and then I know it's a provenance service, I could try to use the same with the other URI
10:58:45 <Stian> ivan: so an extension point in the sysstem, where you cut put any query language, or SPARQL, or anything as additional thing
10:58:57 <Stian> Luc2: but people implementing this, visualisation of PROV information
10:59:08 <Stian> Luc2: javascript code, accessing bits of PROV information, visualising
10:59:27 <Stian> Luc2: I want my browser to be able to interact with the provenance provider and retrieve what is needed
10:59:46 <Stian> ivan: if the provenance provider also has a SPARQL endpoint, this can be handled, get back a URI, get a SPARQL query.. throw it in
11:00:12 <Stian> Luc2: the provenance service COULD be a sparql endpoint
11:00:15 <Stian> (How can you tell?)
11:00:33 <Stian> GK: given an entity URI.. don't try to provide.. access to ..(?)
11:00:52 <Stian> Khalid:  Given URI or place.. where provenance information might be.. (?) 
11:01:02 <Stian> khalidbelhajjame: but not trying to say which SPARQL endpoint...?
11:01:20 <Stian> khalidbelhajjame: we are not trying to return to the user with SPARQL enpodint that provides access to the entity that the user is (?) 
11:01:31 <Stian> khalidbelhajjame: you started discussion with (?) how to access provenance
11:01:43 <Stian> khalidbelhajjame: the user has an entity, represent and entity, you can find entity in this URI.. (?) 
11:02:06 <Stian> khalidbelhajjame: if you want to query only parts of the provenance.. then you could use SPARQL - but given an entity URI we need a way to find which SPARQL endpoint that gives access to that
11:02:08 <tlebo> what is the current concern? that the two options in PAQ are too much,  or that it is inadequate?
11:02:11 <Stian> khalidbelhajjame: but now we say that is outside the scope
11:02:19 <Stian> khalidbelhajjame: but now we return back to this..
11:02:22 <Stian> q+
11:02:24 <Stian> q?
11:02:36 <sandro> (Alas, I can't hear the discussion, but one solution might be to provide access to the graphs an endpoint knows about, and have those graphs provide Link headers pointing to the endpoint.)
11:02:45 <tlebo> Zakim, what time is it there?
11:02:45 <Zakim> I don't understand your question, tlebo.
11:02:50 <Stian> pgroth: we lost 30 minutes before this started
11:02:57 <sandro> (that way only clients who know SPARQL needs to know SPARQL.)
11:02:58 <jcheney> it's 12:00 here
11:03:00 <dgarijo> it is 12:00
11:03:01 <Stian> pgroth: need a resolution on what we need to look at - bu tnot just look at it
11:03:18 <Stian> pgroth: a sheet is shown
11:03:19 <Luc2> Q?
11:03:32 <kai> @Sandro: Can you use Skype? Call me or someone else on Skype, thats better.
11:03:40 <Stian> GK: 1) Discover provenance URI from the resource provider.   Link: <link> etc
11:03:50 <tlebo> ^^ from HTTP header
11:04:00 <Stian> ... 2) Locatiing provenance information via a 3rd party service -- Provenance service
11:04:13 <Stian> GK: difference is that 1) is that the resource provider knows about, 2) is independent service
11:04:33 <Stian> GK: 3) Using SPARQL to query provenance - more Best Practice side - not anything about discovering SPARQL endpoint
11:04:40 <Stian> pgroth: so we should drop 3 or move 3 out
11:04:44 <Stian> ivan: it's just informative
11:05:01 <Stian> pgroth: think we should focus on 1 and 2 - explicit
11:05:09 <Stian> pgroth: MAke it.. this is a protocol
11:05:16 <Stian> pgroth: it is not defined as such
11:05:32 <Stian> pgroth: WSDL option, pattern option  etc.. just decide on one and talk about it
11:05:43 <Stian> GK: also decide what scope is. Here in 2) scope is a bit wide
11:05:54 <Stian> pgroth: should just say 'Here is a provenance service - here's something for an entity'
11:06:09 <Stian> pgroth: only constrait is that we make it open for extensibility - would solve Smiles' problem
11:06:24 <Stian> pgroth: up to other people to define how to extend it - could be extended with filters etc
11:06:27 <Stian> smiles: *(??) 
11:06:38 <Stian> smiles: In the HTPT header from provider you can say that a provenance service is here
11:06:47 <Stian> pgroth: that's in scope - saying how to locate provenance service provider - that's 2)
11:06:53 <Stian> pgroth: provenance-service headers
11:07:09 <Stian> smiles: the provider can talk about 3rd party services?
11:07:17 <Stian> luc: If he so wishes..
11:07:20 <Stian> q-
11:07:22 <tlebo> +1
11:07:40 <Stian> Luc: So 3) SPARQL queries is just best practice
11:07:46 <Stian> GK: yes, just says how to use what exists
11:08:23 <Stian> Luc: And then saying that we are.. two different topics  a) Defining a protocol - form and shape of protocol needs to be specified.   b) Is about locating.. much what we have, with headers etc.. f
11:08:29 <Zakim> -[IPcaller]
11:08:32 <Stian> GK: For resource providers to give location of provenance
11:08:39 <Zakim> -Sandro
11:08:41 <Stian> pgroth: biggest is defining this proctocol
11:09:01 <Stian> GK: biggest thing is coming to consensus about.. pure REST, part REST.. perhaps this is not the irght time for this discussion
11:09:04 <Stian> Luc: Lunch discission?
11:09:21 <pgroth> q?
11:10:23 <Stian> - TODO: SUmmarise the decission above
11:10:29 <Stian> We're trying to call in again now
11:10:44 <tlebo> my telecon phone went silent again.
11:10:50 <Stian> PAQ discussion finished
11:11:11 <sandro> (perfect timing -- PAQ was probably where I had the most expertise.  Ah well.)
11:11:13 <kai> Zakim, who is on the phone?
11:11:13 <Zakim> On the phone I see [VrijeUni], tlebo
11:11:26 <Zakim> +[VrijeUni.a]
11:11:27 <Stian> --- I'll now paste in some chat log from earlier
11:11:30 <Stian> 2012-02-02 PROV F2F notes 
11:11:30 <Stian> ---
11:11:30 <Stian> In practice, the application does not interpret the WSDL - but the user does.
11:11:30 <Stian> pgroth: The REST API.. Banging on Yahoo's REST API.. look at URI templates, replace this with a parameter,
11:11:33 <Stian> GK: This is not a REST API according to Roy Fielding 
11:11:36 <Stian> pgroth: But this is what the world does
11:11:38 <Stian> Luc: What is the pragmatic solution?
11:11:41 <Stian> Ivan: WSDL is independently form this coice.. you could also (ugh) build a SOAP interface to the same service. 
11:11:44 <Stian> GK: If we fix the form of the URI we are forcing a certain API.  
11:11:46 <Stian> Ivan: This is an option.. you use the URI of the resource, the return header, there is a reference to X... OR you use the REST API.. or you WSDL allows this - use the mechanism of well known URIs.  
11:11:50 <Stian> Ivan: There is an RFC that says "This is the way you can construct a well known URI. This group can propose that"
11:11:53 <Stian> Pgroth: Between the WSDL solution and well known URIs.. not good for our case. In the politics, people who have set up provenance services, they have all kinds of .. "ugly" URIs.
11:11:53 <tlebo> +1 @GK - uri templates are bad REST practice.
11:11:56 <Stian> Ivan: that means that.. not advodating here - that means mechanism itself of putting a provenance on a sort of URI that is related to the other URI - if this is true, then the mechanism widely used - is not interoperability - we can propose somethin that uses same approach, but standardize it. We can register the well-known-URI pattern with the IETF.
11:12:01 <Stian> GK: My proposal allows you to encode this practice.. 
11:12:04 <Stian> Ivan: Keep the old one, keep a redirection.. still a case.
11:12:06 <Stian> GK: A tension that is putting wind behind the URI Template stuff.
11:12:09 <Stian> Luc: How can we move forward?
11:12:11 <Stian> Pgroth: Would argue for.. 
11:12:12 <Zakim> +Sandro
11:12:14 <Stian> Luc: SQL query would be different, but could still be a provenance service
11:12:16 <Stian> GK: If we define a protocol we need to scope it.. These are the thins we do.. There are options. If we try to say, this is what we recommend. Then we n 
11:12:19 <Stian> Ivan: The scope of this WG should only be 'How to get to the provenance information' Full stop!  
11:12:20 <GK> @tlebo: I understood templates to be *good* REST practice
11:12:22 <Stian> GK: That's what I initially wanted
11:12:25 <Stian> Ivan: Anything beyond that is not scope of WG. SPARQL or what not. How to get it!
11:12:27 <Stian> GK: How to get it from several starting points. 
11:12:30 <Stian> GK: You might have URI for your source.. how do you get provenance from the provider of that resource. that's where Link: etc came in. 
11:12:31 <tlebo> @pgroth, describe your URI template filling in some "service description" and I'd be fine with it.
11:12:33 <Stian> GK: then other requirements, third-party provenance. Other people provide thrust-assessments about your data. 
11:12:33 <Zakim> -Sandro
11:12:36 <Stian> Ivan: HTTP header is not restricted to the same URI?
11:12:36 <GK> They allow the client to follow information provided by the server.
11:12:38 <Stian> GK: But you need to know where to start. Provenance service came in here..
11:12:41 <Stian> Pgroth: Where do you get provenance from.. In many cases, if you look around what people who have done provenance, most if it stuck in some Provenance Service.  Another way to do so is like in Dublin Core - just have a little graph/document that describe some provenance.
11:12:45 <Stian> Pgroth: Put it in a service - then you need to say "Hey, service, I am interested in provenance about X"
11:12:48 <Stian> Pgroth: And most services provide you a way to query to not get the provenance of the world. But there is not a single well-defined way to do so.
11:12:51 <Stian> Pgroth: We should just say here's where you get some provenance. If it is in a document, related resource, you can go straight to it. 
11:12:54 <Stian> pgroth: just being pedantic.
11:12:56 <Stian> SmileS: what's relation between the API and a SPARQL query. If I get the resource.. what does that mean?
11:13:00 <Stian> Pgroth: One thing we might say is, we need a query language.. we have a draft query language.. we come up with some patterns on how to use SPARQL to query, but that's only an informative thing.
11:13:01 <GK> Sure, you ned to know where to start, but that'simp;licit in REST.
11:13:04 <Stian> SmileS: So does it need sparql in the API? 
11:13:06 <Stian> Ivan: No, not int he API. The Service either gives me a whole graph - and I can do what I like with the graph. Outside scope. Or I get an URI to the provenance information. 
11:13:09 <Stian> Ivan: I can use that URI in a SPARQL service. In any case the query is done on the .... might be a different SPARQL engine.
11:13:12 <Stian> Pgroth: Does not ..(?)
11:13:15 <Stian> SmileS: so what you get back from the API is.. 
11:13:17 <Stian> Pgroth: Provenance information
11:13:20 <Stian> Smiles: Representation or URI?
11:13:21 <ivan> q+
11:13:22 <Stian> Pgroth/Luc: We need to decide on that.
11:13:25 <Stian> ------------- END OF PASTE
11:13:27 <Stian> (those are from various points above that needs to ve moved around)
11:13:30 <Stian> Luc: Two questions
11:13:32 <Stian> Luc: For the primer - what are the next steps, what do we need to continue
11:13:35 <Stian> TOPIC: Primer
<pgroth> Summary: Simon presented the current status of the primer. A key reason for not progressing farther is the differences between prov-o and prov-dm once those issues are resolved further work can be done. Longer term there is a goal to tailor a primer to different communities. In gerneral, the group was happy abou the primer's status. A discussion was had about having a common way to graphically illustrate provenance graphs. It was agreed that having a common convention would be good. Finally, the importance of the primer as an entry point to the entiry family was discussed. There was consensus that the group should aim for a synchronous release with the other documents.
11:13:37 <Stian> smiles: two thins that we thought would need to be done
11:13:40 <Stian> smiles: fill in missing parts - DM things we want to introduce in primer
11:13:42 <Stian> smiles: some impression this morning that we keep things breef - use Turtle in examples
11:13:45 <Stian> smiles: if we're happy with that we stick with that
11:13:48 <Stian> smiles: the reason we have not progressed.. PROV-DM and PROV-O differences - those need to be matched up
11:13:51 <Stian> smiles: had to raise issues on PROV-O for those
11:13:53 <Stian> smiles: derivation, notes.. assocation with.. alternateof, specialisationof, account
11:13:57 <Stian> smiles: some of these controversial
11:14:02 <Stian> smiles: longer term - primer should make sure communities that are to read the documents would all be compatible with it
11:14:14 <Stian> smiles: how to start with the document - now i takes some lines of starting up.. entities attributes
11:14:25 <Stian> smiles: but if people are just citing things.. is it easy for them to pick up and use?
11:14:33 <Stian> smiles: workflow people, how do we address those?
11:14:37 <Stian> smiles: pathways through documents
11:14:48 <Stian> ivan: q+
11:14:52 <Stian> q+ ivan
11:15:04 <Stian> q?
11:15:06 <Stian> q- ivan
11:15:14 <Stian> ivan: this is the first doc I Read, and i understood it
11:15:20 <Stian> ivan: my comments are minor - like 
11:15:32 <Stian> ... bothered my why you use namespace ex1
11:15:37 <Stian> ... in my mind I dropped 1
11:15:38 <Paolo> Paolo has joined #prov
11:15:44 <Stian> smiles: the reason was that there might be more than one example
11:15:52 <Stian> smiles: one example to show everything.. and to not confuse it
11:16:04 <Stian> ivan: thins you define as entity.. is not anywhere else, like article
11:16:19 <Stian> ivan: when I made my own drawings.. for me, when I have an activty, it's an active thing
11:16:25 <Stian> ivan: for me the natural thing of that is to use a word
11:16:33 <Stian> ivan: you use aggregated - and i use aggregate
11:16:44 <Stian> smiles: in concern using provenance.. you can describe arbitrary processes
11:16:46 <Paolo> Q+
11:16:52 <Stian> smiles: what provenance is used for is the *past*  - so past tense
11:16:59 <Stian> ivan: it's a personal thing..
11:17:06 <pgroth> q?
11:17:11 <Stian> ivan: that's how I hit these huge predicate names in PROV-O
11:17:16 <Stian> ivan: prov:wasGeneratedBy
11:17:27 <Stian> ivan: on a diagram it does not look good
11:17:40 <Stian> ivan: found section on revision and derivation very shallow
11:17:46 <Stian> ivan: could follow everything before that
11:17:54 <Stian> ivan: wasEventuallyDerivedFrom
11:18:04 <Stian> smiles: it's still being developed by the other task forces
11:18:05 <Stian> smiles: agree
11:18:13 <Stian> ivan: abstract notation.. skipped that
11:18:13 <Luc> Luc has joined #prov
11:18:21 <Stian> ivan: different discussion
11:18:40 <Stian> ivan: easily, in terms of figures.. an RDF Graph with part of that in the primer would be helpful
11:18:48 <Luc> q?
11:18:50 <Stian> ivan: the diagram that you put up in the beginning section 2
11:18:54 <Stian> ivan: is a copy of th eone in DM
11:19:06 <Stian> ivan: bu tnot sure if you use the terms in the diagram in the rest of the example..
11:19:13 <Stian> Luc: synchronization issue
11:19:24 <Stian> ivan: does not need a full diagram of ontology in primer
11:19:27 <Luc> q?
11:19:37 <Stian> smiles: is the overall what you expected from a primer?
11:19:44 <Stian> ivan: yes, this was my entry point
11:19:48 <Stian> ivan: I can use these diagrams
11:19:53 <Stian> ivan: works very well
11:20:04 <pgroth> q+
11:20:11 <Luc> ack paol
11:20:18 <Stian> Paolo: Question was if diagram or graphical notation explains some things
11:20:21 <Stian> Paolo: what notation to use
11:20:30 <Stian> ivan: I would do RDF graph - examples are in turtle
11:20:48 <Stian> Paolo: my original point - if I give this to half my colleagues - they would be happy to see this as technology/notation independeny
11:20:54 <Stian> Paolo: RDF all over the primer might scare..
11:21:12 <Stian> Paolo: important tha tthis is the first dive in.. then not alienate people who are not interested in RDF
11:21:17 <Stian> ivan: ok, so part of overall discussion
11:21:28 <Stian> ivan: other possibility is to do what OWL primer does.. with the buttons
11:21:49 <Stian> ivan: if I look at OWL primers I always click Turtle syntax - but friends of mine probably clicks Manchester syntax
11:21:53 <Luc> q?
11:22:00 <Stian> pgroth: agree on this
11:22:18 <Stian> pgroth: if other syntaxes like XML-native, JSON come up.. they can fit in
11:22:29 <Stian> ivan: ok, then even RDF/XML if you really want to
11:22:50 <Stian> pgroth: a graphical notation in OPM
11:22:56 <Stian> (?)
11:23:09 <Stian> Luc: not notation, illustration
11:23:17 <Stian> pgroth: illustrate graphically provenance
11:23:19 <GK> Is this discussion of using ASN a first consensus point to test our earlier discussion.  Is this group trying to be technology-independent, or are we defining a specification for the Semantic Web?
11:23:43 <Luc> q?
11:23:44 <kai> kai has left #prov
11:23:44 <Stian> pgroth: (..) or are we trying to just put data as RDF and produce figures?
11:23:57 <kai> kai has joined #prov
11:24:14 <Stian> ivan: could look at diagram at file:///home/stain/src/provenance-wg/prov/primer/Primer.html#intuitive-overview-of-prov-dm and think of it as RDF
11:24:28 <Luc> ack pgr
11:24:29 <Stian> ivan: there is not standard RDF Graph notation.. but if I add some kind of typing
11:24:36 <Stian> ivan: and from the shape I see it's an activity, agent, etc
11:24:42 <Stian> ivan: then I have some kind of notation that is understandable by others
11:24:54 <Stian> ivan: type information info RDF graph - explicitly, obscures everything
11:25:01 <Stian> smiles: Does it have to be fixed to th eRDF graph
11:25:20 <Stian> smiles: like in PROV-O some thins are more complicated then thay need to be in a diagram - wher eyou ahve n-ary relationships
11:25:46 <Stian> ivan: perhaps same technique of syntax switching can also be used for graphics
11:25:53 <Stian> Stian: but it's hard enough already to update the diagrams
11:26:02 <Stian> Paolo: was just meant like a classic ER diagram
11:26:14 <Stian> Paolo: I would support the idea of a suggested graphical illustration
11:26:17 <Stian> Paolo: first thing people do..
11:26:24 <Stian> Paolo: pictures on slides, etc
11:26:29 <Stian> Paolo: suggest at least
11:26:39 <Stian> Luc: Graphical illustration.. we do not mean that kind of picture
11:26:50 <Stian> Luc: We mean an instance of a graph
11:26:54 <Stian> Luc: PROV-DM has something like that
11:27:23 <Stian> ivan: but then it can be correct.. I can look at the picture.. if it's a circle, then it's not just a resource, but with some type information
11:27:27 <Stian> ivan: that would be perfect
11:27:42 <Stian> Luc: some edges in this illustrations are not properties
11:28:01 <Stian> Luc: like wasGeneratedBy or Used might be an instance
11:28:03 <tlebo> @luc, they are predicates
11:28:07 <Stian> Paolo: it can have additional elements
11:28:13 <tlebo> their qualified forms are classes.
11:28:19 <Stian> Luc: it was used.. 
11:29:06 <smiles> smiles has joined #prov
11:29:34 <Stian> http://dvcs.w3.org/hg/prov/raw-file/tip/model/ProvenanceModel.html#graphical-illustration
11:29:50 <Luc> q?
11:29:50 <Stian> pgroth: so an illustration of the graph should be easily represented as RDF
11:29:58 <Stian> Paolo: 10 people doing same graph in different ways
11:30:03 <Stian> Luc: we should as a WG be consistent
11:30:09 <Stian> ivan: so not take my slides public..?
11:30:19 <Stian> Luc: Oh, that's fine, but not in the PROV document
11:30:28 <Stian> ivan: these slides people will copy!
11:30:40 <Luc> q?
11:30:49 <Stian> ivan: my picture is just ovals in colours - would not work in generral!
11:31:00 <Stian> @ivan can we have a sneak-view of this..? :)
11:31:08 <Stian> Paolo: illustration of different perspectives
11:31:17 <Stian> smiles: if we can stick at one example, that is a good thing, makes it simpler
11:31:30 <Stian> smiles: why we though we need more than one example, is that it might be contrived to fit every concept into the same example
11:31:33 <Luc> q?
11:31:38 <dgarijo> +q
11:31:46 <Stian> Paolo: might flow into Best Practices document with several examples
11:32:05 <Stian> dgarijo: I see that you use the QualifiedInvolvement in the example, but not talk about it in the primer
11:32:06 <Luc> q?
11:32:09 <Stian> smiles: See what you mean
11:32:10 <Luc> ack d
11:32:17 <khalidbelhajjame> +q
11:32:18 <Stian> smiles: as PROV-O has changed duing development
11:32:22 <GK> q+ to ask if the focus on one example fits well with the focused examples used for specific points
11:32:29 <Stian> dgarijo: can be confusing with class vs. property
11:32:29 <Luc> ack kh
11:32:39 <Stian> khalidbelhajjame: Notion of role in the primer?  (???)(
11:33:11 <Stian> Stian: yes, roles have become downplayed for general attributes later
11:33:19 <Stian> (We had EntityInRole rather than QualifiedInvolvement)
11:33:46 <Stian> smiles: roles were more explicit before, now evolved with various qualifications
11:33:58 <Stian> khalidbelhajjame: perhaps it's best to keep it, explain roles which are more important (?)
11:34:07 <Stian> smiles: add something about roles being just one way to qualify
11:34:22 <Luc> ack gk
11:34:22 <Zakim> GK, you wanted to ask if the focus on one example fits well with the focused examples used for specific points
11:34:30 <Stian> GK: about single example.. was impressed with how the examples were introduced 
11:34:32 <tlebo> @stian, which shifted from describing the (EntityInRole) more characterized Entity to describing the (QualifiedInvolvement) triple between the Activity and the Entity.
11:34:36 <Stian> GK: if we force it to single example we might loose this!
11:34:46 <Stian> GK: so push this to make sure we keep the simple ocus in incremental development
11:34:53 <Stian> ---Lunch has arrived
11:34:58 <Stian> with 3 freeriders
11:35:03 <Stian> (?)
11:35:18 <Stian> smiles: point is that focus on common relations.. properties.. wassummaryof etc
11:35:26 <Stian> smiles: thinking of document from librarian perspective
11:35:42 <Stian> smiles: record of activities.. make you start to read, see if this is relevant to me
11:35:48 <Stian> smiles: so both kind of communities are encouraged
11:35:49 <Luc> q?
11:36:32 <Stian> smiles: last release in January.. suggests that in 6 times for something that addresses different communities.. on the way changes with intermediate releases to keep up to date
11:36:39 <Stian> ivan: so primer is a Note? 
11:36:43 <Stian> Stian: yes, informative
11:37:10 <Stian> Luc: if we simplify DM.. then alignment iwth primer is important - it's the first entry point - we should pitch it like that
11:37:27 <Stian> Luc: so it must be align with our changes -b ut can be incomplete and say not cover collections
11:37:45 <Stian> Luc: but if core thins change, then we must update primer
11:37:55 <Stian> smiles: so instead of primer folks lagging behind.. 
11:38:02 <Stian> smiles: treat it as a change request (?)
11:38:14 <Stian> Luc: align with milestones of DM and O
11:38:20 <Stian> Luc: even if not 100% synced
11:38:36 <Stian> smiles: if PROV-O is finished 1 week before deadline, we need to know what is updated or not
11:39:15 <Stian> Stian: so it's good with cross-taskforce mixing here, like myself is in PROV-O and Primer - Paolo is in DM and Primer
11:39:30 <tlebo> 35 minutes for lunch?
11:39:34 <tlebo> thx
11:39:43 <Stian> MEETING ADJOURNED UNTIL 13:15 GMT  (~35 mins)
11:39:49 <Stian> s/GMT/CEST
11:39:53 <Stian> MEETING ADJOURNED UNTIL 13:15 CET  (~35 mins)
11:41:02 <Zakim> -[VrijeUni.a]
12:16:52 <kai> kai has joined #prov
12:17:18 <smiles> smiles has joined #prov
12:18:27 <jcheney> jcheney has joined #prov
12:18:45 <Polo> Polo has joined #prov
12:18:58 <Stian> TOPIC: Best practic document(s)
<pgroth> Summary: The current best practices document describes how to extend the ontology to an application specific domain. Kai agreed to lead the development of a best practice document for using Dublin Core and Prov together. Danial, Graham and Simon agreed to help. It was agreed, not to reach out to people outside the group until the specifications have stabalized more. Ivan suggested that the Semantic Web wiki can be used to maintain examples coming from the group and best practices after the lifetime of the working group.
12:19:00 <Paolo> Paolo has joined #prov
12:19:12 <pgroth> we will try to talk again
12:19:22 <pgroth> try to phone in again
12:19:26 <Zakim> -tlebo
12:19:28 <Paolo> TOPIC best practice
12:19:35 <Stian> Scribe: Paolo
12:19:40 <Paolo> Luc; what should be there?
12:19:46 <GK> GK has joined #prov
12:19:53 <GK1> GK1 has joined #prov
12:19:54 <Paolo> should SPARQL queries be best practice?
12:20:02 <Paolo> Stian: started writing a section on serialization
12:20:03 <Zakim> +tlebo
12:20:47 <dgarijo> dgarijo has joined #prov
12:21:02 <Paolo> Luc: but is this part of PROV-O instead?
12:21:12 <Paolo> dgarijo: all examples from PROV-O have been placed in the BP
12:21:39 <dgarijo> http://dvcs.w3.org/hg/prov/raw-file/tip/bestpractices/BestPractices.html
12:21:57 <Paolo> Luc: should be connected to interoperability problem
12:22:27 <Paolo> Stian: BP is a good place for some limited hints at interop
12:23:03 <Paolo> Paul: BP should clarify for example the kind of reasoning that one is expected to be able to understand
12:24:07 <Paolo> Paul: interop is not a proper BP issue
12:24:49 <Paolo> Paul:  examples of BP: working with DC, working with OpenID, working with Creative Commons
12:26:03 <Paolo> Kai: DC is directly related in describing the provenance of things
12:26:37 <Paolo> Paul: it's about clarifying the relationship b/w DC terms and PROV terms
12:27:57 <Paolo> Paul: create mappings to that translators can be automatically built
12:28:18 <Paolo> Kai: fine, and volunteers to take responsibility to work on these mappings
12:28:28 <Paolo> Daniel joins in!
12:28:34 <Paolo> and Simon joins, too!!
12:28:46 <Paolo> and Graham!!! 
12:29:18 <Paolo> Kai: can we have some initial examples to bootstrap the process
12:29:24 <pgroth> Action: kai to bootstrap dc best practice
12:29:25 <trackbot> Created ACTION-53 - Bootstrap dc best practice [on Kai Eckert - due 2012-02-09].
12:29:28 <ivan> q+
12:29:52 <Paolo> Khalid, Daniel: example mappings to SKOS exist and can be used as examples
12:30:08 <Paolo> Luc: what are the scope and objectives  of this activity?
12:30:29 <Paolo> GK: start with illustrative mappings initially
12:30:41 <Paolo> smiles: simpler DC -> PROV 
12:32:06 <Paolo> Ivan: practically, some of these mappings should belong in the PROV-O ontology
12:32:45 <Paolo> (that is, if the mappings are simple and just involve subClassOf etc.)
12:33:12 <Luc2> Luc2 has joined #prov
12:33:41 <Paolo> Ivan: whenever these mappings are clear and OWL-expressible, they should be put in PROV-O
12:36:33 <Zakim> +[VrijeUni.a]
12:36:48 <pgroth> meeting room is back on zakim
12:37:23 <Paolo> Luc: need expectation management -- be realistic wrt timeline
12:38:04 <Paolo> Luc; having mappings is a nice proposition but it may be beyond what we can achieve realistically. Start small initially, then reassess
12:38:40 <Paolo> Paul:  need someone to drive the creative commons effort
12:38:57 <Luc2> Q?
12:39:23 <Stian> I've added a template section 2 for Kai et al in http://dvcs.w3.org/hg/prov/raw-file/tip/bestpractices/BestPractices.html 
12:39:44 <Paolo> Kai: from the Connection TF POV, connections should be established with CC people. Awaiting the results of this meeting before we can engage them so we have a concrete baseline for collaboration
12:40:36 <Paolo> Paul: idea still valid but to be postponed until last WD, before last call
12:40:44 <Paolo> Luc: to be revisited after WD5 is out
12:42:01 <Paolo> Kai: only engage people when we know we have a real chance
12:42:18 <Luc2> Q?
12:42:29 <Luc2> Ack I
12:42:52 <dgarijo> Paolo: what do you mean by retorical structures?
12:43:11 <Paolo> Paul: engaging HCLS group on "rethorical structures"  (SWAN etc.). keen on identify provenance issues
12:43:40 <Paolo> Paul: wil talk to them before end of Feb., using the primer
12:43:44 <Luc2> Q?
12:48:15 <Paolo> Khalid: is there a place in the doc suite when you can go deeper into some topics that have been determined to be not mature enough for PROV?
12:48:35 <Paolo> Luc: not precluded but no requirement in the charter to do that
12:48:36 <smiles> smiles has joined #prov
12:49:17 <Paolo> Luc: any need to have a collections-howto in the BP?
12:49:25 <Paolo> Stian, Paolo: yes
12:50:26 <Paolo> Stian, Paolo to contribute such examples
12:50:57 <Luc2> Q?
12:51:40 <dgarijo> dgarijo has joined #prov
12:52:45 <Paolo> initially to go into the BP doc
12:53:04 <Paolo> Luc: is BP a single doc?
12:53:38 <Paolo> or should it be modular
12:53:58 <Paolo> ivan: a note has no constraints on form
12:54:45 <kai> kai has joined #prov
12:55:00 <Paolo> no formal publication, it can be a web page but careful as it has to be maintained past the end of the project
12:55:28 <Paolo> Ivan: the SW wiki can be used to maintain live examples over time
12:56:10 <Paolo> Paul: good to have some "stamp" on the examples so that's a good technical solution
12:56:23 <Paolo> Ivan: so use the WG wiki to develop, then migrate to SW wiki
12:59:19 <Paolo> Luc: the current "best practices" doc is currently an extension of prov-o, it should be made to stand on its own
13:00:00 <Stian> so we will dismantle http://dvcs.w3.org/hg/prov/raw-file/tip/bestpractices/BestPractices.html and use mainly wiki pages (sparql example, collections) and separate notes (Dublin Core, ontology extensions)
13:00:08 <tlebo> hello
13:00:39 <tlebo> I'm on Zakim
13:00:48 <Stian> Zakim: who is on?
13:00:51 <Stian> Zakim, who is on?
13:00:51 <Zakim> I don't understand your question, Stian.
13:01:03 <Stian> Zakim, who is on the phone?
13:01:03 <Zakim> On the phone I see [VrijeUni], tlebo, [VrijeUni.a]
13:01:27 <Paolo> Topic: PROV-DM
<pgroth> Summary: Two topics were discussed in this session: accounts and identifiers. Accounts - The prime use of accounts was identified as being able to express the provenance of provenance. However, the current notion attempts to support more complex notions of multiple accounts, which adds complexity to the model. To address this complixty, the group agreed that accounts are going to be taken out and replace it with a "bundle" for a set of provenance assertions.  Identifiers - a key issue has been what identifiers denote in the data model. The group recognized that the key problem is that we were trying to address two use-cases. The term "scruffy" provenance was used to refer to using the prov-dm vocabulary with already exisiting web resources where the subject of a provenance assertion is just a URI. The term "proper" provenance was used to refer to the case where the thing should have a frozen characterisation. Both use cases were seen as being important. To address the use case of scruffy provenance instead the editors of prov-dm proposed to remove the distinction between entities and things in the document, which reflected these two use cases. There was consensus to move forward with the renaiming.
13:01:46 <Luc2> Q?
13:02:04 <Paolo> Paul chairs
13:02:28 <Paolo> Paul issues on identifiers should be addressed in a pragmatic way
13:02:55 <Paolo> Paul: need to avoid corner cases
13:03:07 <pgroth> q?
13:04:00 <Paolo> Luc: issue: {entity, thing, attributes, identifiers}. not specific to PROV-DM, see Paul's blog example
13:04:20 <dgarijo> http://www.w3.org/blog/SW/2011/10/23/5-simple-provenance-statements/
13:04:49 <Paolo> Luc: first issue to address here; account. 
13:05:47 <Paolo> Luc: prime use for accounts is provenance of provenance
13:07:13 <Paolo> Luc: initially accounts were meant to express provenance of provenance (PoP). When written in prov-dm, the concept became broader
13:07:53 <Paolo> Luc: provenance of accounts not ready for std because of outstanding issues,
13:08:04 <Paolo> however PoP req. can be addressed
13:08:09 <pgroth> q?
13:08:19 <Stian> do we need provenance of provenance accounts, or provenance of individual provenance records?
13:08:41 <GK1> My view: if the sole requirement is provenance of provenance, then I don't think account is needed.  I thought the requirement was to capture and compare differing accounts of the same process, and enable some level of reasoning over this different accounts.
13:08:43 <Stian> the second one is the hard one - first is the easy (GK) one
13:08:43 <Paolo> @Stian the latter
13:08:47 <khalidbelhajjame> +q (Is the ability of expressing provenance of provenance the only thing that motivated the notion of Account ?)
13:09:42 <Stian> I thought account was essential to different views and different granularities of what has happened
13:10:32 <tlebo> +1 @stian
13:10:44 <GK1> (Provenance of individual provenance records: this sounds a bit like the old discussion of RDF reification vs named graphs) 
13:10:48 <Paolo> Luc: propose to discard account records and just assume there is a mechanism for naming a "bundle of assertions". The specification of such mechanism is out of scope for us
13:10:52 <Stian> and different entity characterisations
13:10:56 <GK1> @stian me too
13:11:01 <dgarijo> @Stian: +1
13:11:33 <tlebo> naming "bundle of assertions" sounds reasonable (and seems to agree with the 4 +1s here)
13:11:51 <Paolo> Luc: with this, we won't be able to express many things related to accounts, these will not be addressed
13:12:00 <smiles> q+
13:12:02 <Paolo> Luc: the very name "account" could be dropped
13:12:30 <pgroth> q?
13:12:31 <kai> q+
13:12:40 <Luc2> Q?
13:12:41 <Stian> q+
13:12:42 <khalidbelhajjame> +q
13:12:43 <pgroth> ack smiles
13:13:26 <Paolo> smiles: supportive of proposal. But useful cases include granularity of provenance, should something be put in the best practice doc, or elsewhere?
13:13:29 <GK1> q+ to say re proposal, I think we can be even simpler: provenance is a resource, and hence the same mechanisms for ascribing provenance apply
13:14:22 <Stian> I think tlebo has done a rdf reification meta-provenance example
13:14:29 <Stian> but that's quite RDF-specific of course
13:14:40 <tlebo> (which example?)
13:14:42 <Stian> no?
13:14:53 <Stian> you do so many cool things I thought you had ;)
13:15:06 <kai> Actually I did that ;-)
13:15:12 <tlebo> I haven't written an example in my life.
13:15:31 <tlebo> @kai, link?
13:15:41 <tlebo> what do we want to do?
13:15:44 <Paolo> Luc: "finding the provenance of X in this account" is still a requirement. 
13:16:12 <Paolo> Paul: there is prior art from OPM but not enough to standardize it.
13:16:18 <pgroth> q?
13:16:22 <pgroth> ack kai
13:16:27 <tlebo> what is "it" that we want to do?
13:16:29 <Paolo> smiles:  just be careful we don't prevent this from being addressed/added later
13:16:46 <GK1> ?? ""finding the provenance of X in this account" is still a requirement."  is this a recursive requirement for accounts?
13:16:54 <pgroth> q?
13:17:24 <Paolo> Kai: agree we don't need accounts. in DC there is a "description set" that contains statements
13:17:33 <Stian> @tlebo is this not an example? http://dvcs.w3.org/hg/prov/file/7f0d26e48556/ontology/examples/ontology-extensions/commerce/commerce.ttl disagrees
13:17:39 <Stian> (not reification though)
13:18:07 <Paolo> but there is still a need to name a bundle of records. it may or may not be an "account"
13:18:42 <ivan> q+
13:19:09 <Paolo> Kai: there is a risk of creating something that cannot be implemented using the current RDF
13:19:12 <Stian> can accounts/bundles/ex overlap? Kai mentions an account 'for provenance of X' - then it might overlap (but not completely) with 'provenance of Y'
13:19:22 <GK1> @paolo sure.  This is actually what we (Wf4Ever) are doing for annotations in ROs.  It's just being able to distinguish resources.
13:19:47 <smiles> smiles has joined #prov
13:19:50 <Paolo> Luc: not clear that we need named graphs
13:20:03 <pgroth> ack Stian
13:20:09 <pgroth> ack khalidbelhajjame 
13:20:12 <Paolo> @GK: sorry that was the continuation of Kai's note... not my own!
13:20:15 <Luc2> Q?
13:21:10 <kai> Using reification for metametadata: http://dcpapers.dublincore.org/index.php/pubs/article/view/973
13:21:15 <Paolo> Khalid: is PoP really the only requirement? should it include "is this set of assertions consistent as a whole?"
13:21:33 <tlebo> (I just missed the last few minutes)
13:21:42 <tlebo> no more NGs?
13:21:57 <Paolo> Luc: but that can still be done, having identified a bundle. does not require an account record in the model
13:22:12 <pgroth> ack GK
13:22:12 <Zakim> GK, you wanted to say re proposal, I think we can be even simpler: provenance is a resource, and hence the same mechanisms for ascribing provenance apply
13:22:48 <dgarijo> dgarijo has joined #prov
13:23:03 <Paolo> GK: if we only need PoP then there is no need for accounts. other req is granularity/different perspective. For time reasons, we can defer the latter
13:23:21 <Paolo> GK: but if possible, it's a useful requirement to include
13:23:42 <tlebo> +1 "no need for accounts", as long as we keep "provenance" as a resource that is a "bundle of statements".
13:25:07 <pgroth> q?
13:25:32 <pgroth> ack ivan
13:25:32 <Paolo> Kai: the resource that represents a bundle of provenance assertions, can that be assigned a class, and wouldn't it be an "account"?
13:26:31 <GK1> q+ to say I don't think this is ACTUALLY DEPENDENT ON RDF GROUP " - named graphs" ...
13:26:33 <Paolo> Ivan: warning -- named graph discussion in the RDF group is still ongoing, but it's not advisable to build any dependency to it in PROV
13:27:26 <tlebo> q+ to say that we can use sd:NamedGraph (sd:name sd:graph) for what we need. We don't need RDF 1.1 wg b/c they need to reconcile with the same (now closing) SPARQL 1.1 spec.
13:28:34 <pgroth> ack GK
13:28:34 <Zakim> GK, you wanted to say I don't think this is ACTUALLY DEPENDENT ON RDF GROUP " - named graphs" ...
13:29:08 <smiles> q+
13:29:17 <Luc2> Q?
13:29:49 <Paolo> Tim:  concurs that there is no such dependency
13:29:51 <pgroth> ack tlebo
13:29:51 <Zakim> tlebo, you wanted to say that we can use sd:NamedGraph (sd:name sd:graph) for what we need. We don't need RDF 1.1 wg b/c they need to reconcile with the same (now closing) SPARQL
13:29:54 <Zakim> ... 1.1 spec.
13:29:57 <GK1> (cf. ORE)
13:30:47 <Paolo> smiles: agree that bundling does not require a provenance-specific concept
13:30:56 <pgroth> q?
13:31:00 <pgroth> ack smiles
13:31:50 <Paolo> Paul: PoP is clearly required, it's important to give a signal that it has been addressed
13:32:06 <GK1> @pgroth +1 - yes, indeed, let ppl know it's possible without new mechanism
13:33:05 <Paolo> Paul: "a bundle of provenance" would be good enough
13:33:22 <GK1> For "bundle of provenance" we could talk about "a provenance resource"?
13:33:31 <pgroth> q?
13:35:47 <GK1> q+ to say I don't really mind about assigning the name "account" - it seems as good as any
13:35:49 <tlebo> q+ to ask if "nesting" bundles stays
13:35:56 <pgroth> q?
13:36:20 <Luc2> Q?
13:36:32 <pgroth> ack GK
13:36:32 <Zakim> GK, you wanted to say I don't really mind about assigning the name "account" - it seems as good as any
13:36:46 <tlebo> +1 keeping name "account"
13:36:51 <pgroth> ack tlebo
13:36:51 <Zakim> tlebo, you wanted to ask if "nesting" bundles stays
13:36:53 <Paolo> GK: do we need to name these bundles?
13:37:02 <pgroth> repeat
13:37:25 <Paolo> Tim: does nesting of bundles stay?
13:37:40 <GK1> q+ to say that, for now, we say nothing about nesting.  Not prohibited, not defined.
13:37:53 <tlebo> no
13:37:55 <khalidbelhajjame> I think bundle is a better name than acocunt if we are only after expressing the provenance of a possibly random collection of provenance assertions
13:37:57 <Paolo> Luc: no
13:37:59 <tlebo> happy it's gone :-)
13:38:12 <pgroth> ack GK
13:38:12 <Zakim> GK, you wanted to say that, for now, we say nothing about nesting.  Not prohibited, not defined.
13:38:23 <Paolo> GK: we are agnostic wrt nesting
13:38:42 <tlebo> (btw, one could "nest" themselves using void:subset)
13:39:49 <tlebo> (btw, one could achieve "nesting" in their own modeling by using void:subset)
13:39:51 <Paolo> Luc: why do we name it?
13:40:00 <Paolo> Kai: because people expect it
13:40:09 <GK1> I lean to the idea that naming it makes it easier to discuss.
13:40:42 <Paolo> Kai: just define a new class that is unrelated to the rest of provenance. ProvenanceStatementSet? 
13:41:10 <GK1> q+ to say naming and defining a class are different issues...
13:41:40 <tlebo> why not just all it Provenance ?
13:41:46 <tlebo> s/all/call/
13:42:20 <Paolo> Stian: isn't this a topic for PROV-AQ?
13:43:33 <Paolo> Luc: the "hasProvenance" property is not in -O or -DM, currently only in -AQ
13:43:45 <smiles> q+
13:43:45 <pgroth> ack GK
13:43:47 <Zakim> GK, you wanted to say naming and defining a class are different issues...
13:43:57 <tlebo> - aq:hasProvenance is subproperty of dcterms:subject and inverse of foaf:topic .
13:44:02 <Paolo> GK: name and class are different issues
13:44:21 <Stian> sounds like it is an 'outer' type for perhaps 'any' kind of provenance resource..   aq:hasProvenance [ a aq:Provenance ]    - a prov:Account (if we need it) can be a subclass of aq:Provenance
13:44:31 <Stian> which is PROV provenance or even PROV-O provenance
13:44:31 <Paolo> GK; in favour of former but against the latter
13:44:45 <tlebo> @stian, I like.
13:44:57 <pgroth> ack smiles
13:44:59 <Paolo> GK: risk of over-specification
13:45:28 <tlebo> q+ to ask of aq:hasProvenance is subproperty of dcterms:subject
13:45:54 <dgarijo> http://dublincore.org/documents/dcmi-terms/#terms-provenance
13:46:08 <Stian> yaay
13:46:12 <Stian> our work is futile!
13:46:20 <dgarijo> :D
13:46:23 <tlebo> (modulo the directionality...)
13:46:30 <Stian> oh look, theres dcterms:created and dcterms:created as well
13:46:48 <pgroth> @tlebo is your question on this topic?
13:47:07 <tlebo> @pgroth, I guess the topic drifted.
13:47:11 <GK1> http://purl.org/dc/terms/ProvenanceStatement
13:47:11 <GK1> Label - Provenance Statement
13:47:11 <GK1> Definition - A statement of any changes in ownership and custody of a resource since its creation that are significant for its authenticity, integrity, and interpretation.
13:47:12 <pgroth> ok
13:47:23 <tlebo> q-
13:47:57 <Paolo> Luc: issue of introducing a class can be postponed
13:48:49 <Stian> an attempt to do meta-provenance with RDF reification: http://dvcs.w3.org/hg/prov/raw-file/tip/ontology/examples/metaprovenance.trig
13:49:01 <Stian> notably I did not find a way to link an rdfg:Graph with an rdf:Statement - which sounds quite essential
13:49:01 <pgroth> Guidance to editors: revisit the document dropping the notion of account records and make it consistent
13:49:12 <Stian> args
13:49:19 <tlebo> @Stian rdf:Bag!
13:49:46 <GK1> q+ to suugest: add to guidance for editors that the description of this idea should be as simple as possible.
13:49:52 <Paolo> Luc:  on "relationships across accounts"  -- entity e1 described in account1 wasGeneratedBy entity e2 in account 2
13:50:25 <tlebo> if you want to relate two resources, assert a triple between them :-)
13:50:26 <Paolo> Luc: would still like to be able to say this but not enough prior art, so suggest to accept that it's out of sope
13:50:30 <Paolo> s/sope/scope
13:50:32 <pgroth> guidance to editors: not trying to express relations across accounts
13:50:51 <smiles_> smiles_ has joined #prov
13:50:53 <pgroth> q?
13:51:08 <smiles_> I think it was ProvenanceStatement class from DC I was thinking of
13:51:16 <tlebo> +1 cross-accounts is out of scope (I'll just handle it with RDF)
13:51:27 <khalidbelhajjame> +q (So entities may exists without being associated within an account)
13:51:46 <Stian> that's q+, khalidbelhajjame :)
13:51:51 <pgroth> ack khalidbelhajjame 
13:51:54 <pgroth> ack GK
13:51:54 <Zakim> GK, you wanted to suugest: add to guidance for editors that the description of this idea should be as simple as possible.
13:51:55 <kai> @smiles: Yes, but that's just the range of dct:provenance, not something like the bundle that we had in mind.
13:53:02 <GK1> q+ to say I think we're confusing the language with the domain again
13:53:21 <tlebo> [ dcterms:description "I have a blue shirt on. I hit Joe yesterday. He has a bruise today."; rdf:type prov:Provenance ] .
13:53:48 <ivan> ack GK1 
13:53:48 <dgarijo> dgarijo has joined #prov
13:54:04 <pgroth> ack GK
13:54:04 <Zakim> GK, you wanted to say I think we're confusing the language with the domain again
13:54:53 <Paolo> Luc: second issue
13:55:05 <smiles_> @kai OK, but Im not sure I see the difference, really. arent they just 'data describing the provenance'? Probably not an important matter, anyway, except maybe for the mapping to DC
13:55:46 <Paolo> Luc (sorry) about identifiers
13:56:29 <Stian> flip chart:   :post prov:wasAttributedTo :Paul  
13:56:30 <pgroth> q?
13:56:30 <tlebo> am I flipchartless?
13:56:35 <smiles_> post wasAttributedTo Paul
13:56:36 <kai> @smiles: probably just some text, if people are using it. But could become interesting if it could be used to point to PROV data. Will have a look at it in context of the mapping.
13:56:38 <Stian> I turtlized it 
13:56:47 <Paolo> @Stian flipchart real time scribing!
13:56:57 <dgarijo> http://www.w3.org/blog/SW/2011/10/23/5-simple-provenance-statements/
13:57:21 <tlebo> @ivan dont' forget the @prefix defs.
13:57:26 <jun> jun has joined #prov
13:57:53 <dgarijo> @prefix ex: <http://www.example.org/> @prefix prov: <http://www.w3.org/ns/prov-o/> @prefix foaf: <http://xmlns.com/foaf/0.1/>  ex:post prov:wasAttributedTo ex:Paul. ex:Paul a foaf:Person.
13:58:08 <tlebo> Zakim, turn off these smiley faces.
13:58:08 <Zakim> I don't understand 'turn off these smiley faces', tlebo
13:58:11 <Paolo> Paul: central problem is: describing provenance is solvable if we are allowed to mint new IDs whenever we want
13:58:47 <Paolo> Paul: but we have an obligation to use existing IDs for existing resources
13:58:50 <tlebo> but we have specializationOf!
13:59:02 <Paolo> Paul which makes it complicated
13:59:03 <GK1> Where's this requirement?
13:59:03 <tlebo> and alternateOf
13:59:32 <Paolo> @Tim I suspect those are in the endangered list...
14:00:08 <Paolo> Luc: reusing a URI not enough anyways, because we want to identify specific perspectives on the resources
14:00:16 <smiles_> q+
14:00:23 <tlebo> +1 Luc
14:00:43 <Paolo> Luc: concept of {entity, thing, attributes} not well defined
14:00:45 <tlebo> identifyied specific perspectives can be associated to their less specific things with speicalizationOf
14:01:30 <pgroth> q?
14:01:32 <GK1> q+ to say the notion of entity is not *completely* defined, but I think that's OK.  But maybe we can duck the issue and approach it from a best parctices for dynamic resources angle.
14:01:40 <Paolo> smiles: should the example ":post prov:wasAttributedTo :Paul" be augmented to highlight mutable resources, ie., the blog was later edited
14:02:02 <pgroth> ack smiles_
14:02:37 <Paolo> Ivan: time was spent yesterday in the RDF group on mutability of URI-identified resources
14:02:50 <pgroth> ack GK
14:02:55 <Zakim> GK, you wanted to say the notion of entity is not *completely* defined, but I think that's OK.  But maybe we can duck the issue and approach it from a best parctices for dynamic
14:03:00 <Zakim> ... resources angle.
14:03:31 <tlebo> a "mutable URI" is actually THREE URIs. Two that are prov:specializationOf a third.
14:03:39 <tlebo> a "mutable URI" is actually THREE URIs. Two that are prov: specializationOf a third.
14:03:42 <Stian> :account1 can say something else about :post than :account2  - and :account2 might be the same provenance resource retrieved 2 days later
14:04:03 <Stian> the problems have then moved to identifying those accounts ..
14:04:08 <Paolo> GK: we can duck the entity mutablity issue, by ways of best practices i.e., adding timestamps to provenance statements
14:04:20 <Paolo> Ivan: these issues are not provenance-specific
14:04:27 <khalidbelhajjame> +q
14:04:33 <Stian> memento URIs, tag URIs as well
14:04:36 <Paolo> q?
14:04:56 <pgroth> ack khalidbelhajjame 
14:04:57 <GK1> Ivan: re dynamic resources and provenance "the group knows there are issues, but these are not provenance specific"
14:05:18 <Stian> luc can't identify the problem with identifying entities
14:05:19 <Paolo> @tim not sure  prov:specializationOf is the right way to track mutability of resources
14:05:43 <Stian> I think it's a straight forward way
14:05:57 <GK1> q?
14:06:02 <GK1> q+
14:06:55 <tlebo> @paolo, I think specializationOf is the only way to make sense of Entity.
14:07:00 <Stian> In <account35>:   <account35#post> a prov:Entity, prov:Agent, foaf:Person;   prov:specializationOf <http://example.com/Paul.foaf>
14:07:03 <Stian> tlebo: +1
14:07:13 <Stian> s/#post/#Paul/
14:07:43 <Stian> we don't need timestamps etc - that is metaprovenance that can be expressed in the provenance of the entity <account35>
14:08:30 <GK1> q+ to say I think we've just wandered into the same old weeds here... can't we just duck the issue initially by focusing on static resources, then explain (much) later how to deal with dynamic resources
14:08:39 <smiles_> q+
14:09:13 <pgroth> ack GK
14:09:13 <Zakim> GK, you wanted to say I think we've just wandered into the same old weeds here... can't we just duck the issue initially by focusing on static resources, then explain (much) later
14:09:17 <Zakim> ... how to deal with dynamic resources
14:09:52 <khalidbelhajjame> +q
14:09:57 <Paolo> GK OPMV got around the problem by assuming resources are static 
14:10:01 <tlebo> @pgroth, blog posters don't care which level of specializationOf that they are talking about - which is fine until someone starts assuming that the Entity that they were referring to is at an incorrect level of characterization.
14:10:57 <tlebo> we're drifting up and down levels of specificity. If we just acknowledge that IT IS THERE and let people describe them (with specializationOf), we're set.
14:11:01 <kai> q+ to propse dropping entities *duck and hide* -> move it to best practice.
14:11:28 <Stian> tlebo: +1
14:11:44 <dgarijo> http://www.w3.org/TR/cooluris/
14:11:51 <Stian> kai: that's a logical conclusion from what we agreed in the morning!
14:11:54 <tlebo> first rule of Cool URIs.... You don't talk about Cool URIs.
14:12:50 <Stian> one that has changed: <http://megaupload.com/>
14:13:28 <tlebo> <http://www.w3.org/TR/2011/WD-prov-dm-20111215/> prov: specializationOf <http://www.w3.org/TR/prov-dm/> .
14:13:51 <GK1> http://www.w3.org/Provider/Style/URI.html
14:14:42 <Stian> and <http://www.w3.org/TR/prov-dm/> prov:alternativeOf <http://dvcs.w3.org/hg/prov/raw-file/tip/model/ProvenanceModel.html>  (they have a common specialization which we haven't given a URI)
14:15:16 <GK1> @stian but we *could* mint a URI
14:15:20 <Stian> Luc writing:
14:15:25 <Stian> entity(post)
14:15:33 <tlebo> @stian, my transcription hero.
14:16:12 <Stian> entity(post, [ author="..", title="...", ??="..", time="..."] )
14:17:01 <Stian> he's pointing at 'post' in the last line - and the whole line 
14:17:43 <pgroth> q?
14:18:03 <Paolo> Luc: conclusion is that we are actually identifying the resource, not the entity
14:18:07 <tlebo> luc wants owl:keys (compound keys) to identify two named things - which is very different from URI identifying
14:19:08 <pgroth> ack smiles
14:19:10 <Stian> tlebo to get on the queue
14:19:51 <Paolo> smiles: agree with Tim and GK -- no particular problems. in the example, Post is a resource
14:20:36 <pgroth> q?
14:20:37 <Paolo> smiles: resources have implicit characterization -- minimally it's just identified by a URI, and that alone makes it an entity
14:20:40 <pgroth> ack khalidbelhajjame 
14:21:07 <Stian> smiles_: "...., a resource is an entity"
14:21:09 <Stian> @smiles +1
14:21:47 <tlebo> we're drifting up and down levels of specificity. If we just acknowledge that IT IS THERE and let people describe them (with specializationOf), we're set.
14:21:53 <MacTed> MacTed has joined #prov
14:21:56 <Stian> <http://megaupload.org/> prov:wasAttributedTo <http://example.com/theGuyWhoWasArrested> .
14:22:08 <Stian> but that's not true anymore - it's now attributed to the department of justice
14:22:22 <Stian> however that's up to each account when/what they are talking about
14:23:11 <Paolo> @Stian timestamp, just add timestamps to the entity assertion
14:23:28 <tlebo> specializationOf, then I'll die happy.
14:23:31 <pgroth> q?
14:23:48 <Paolo> @stian isn't that what you do when you reference a web site by URL in a paper?  "accessed on..."
14:23:59 <smiles> smiles has joined #prov
14:24:12 <Paolo> q+
14:24:17 <Stian> Paolo: yes, just some metaprovenance.. it could contain as much or little as possible.. such as "The web page when downloaded on my Samsung Nexus phone using Firefox"
14:24:29 <Stian> on saturday 15:02 from Uzbekistan
14:24:54 <tlebo> @paolo, I think the "accessed on" is a great example for how one is creating an Entity that is a specializationOf some more abstract Entity.
14:25:00 <Stian> but then within that account you can't have two different entities with the same URI
14:25:15 <Paolo> @Stian now you're telling us too much... is Uzbekistan a friend country
14:25:15 <GK1> q?
14:25:20 <Stian> tlebo: and probably something that should be core to the web-bit of PROV.. like wasAttributedTo
14:25:36 <Stian> the PAV ontology have a few things like that
14:25:38 <dgarijo> dgarijo has joined #prov
14:26:02 <Paolo> Kai: to propose to drop "entity"
14:26:37 <GK1> q+ to respond to Ivan - does this "characerized resource" (e.g. by time) have the same URI as tbe uncharactierized resource
14:27:42 <tlebo> -1. Entity introduces the important notion of "frozen characteristics", which is not provided by the current semweb.
14:28:04 <Stian> I've always thought of prov:Entity as an rdf:Resource which is rdf:subject of some rdf:Statements - not the group of statements/attributes
14:28:13 <Stian> tlebo: mmm
14:28:14 <Paolo> q?
14:28:17 <Luc> Luc has joined #prov
14:28:38 <tlebo> q- I can't keep up with the in-voice pace.
14:29:32 <Luc> Q+
14:29:33 <tlebo> q+ we're drifting up and down levels of specificity. If we just acknowledge that IT IS THERE and let people describe them (with specializationOf), we're set.
14:29:38 <Luc> Q+
14:29:49 <pgroth> ack kai
14:29:49 <Zakim> kai, you wanted to propse dropping entities *duck and hide* -> move it to best practice.
14:29:56 <Stian> tlebo: yes, as Ivan points out, it's a general RDF problem - but (I believe) we need it now
14:30:16 <smiles> I might say: An entity is a resource or a specific characterisation of a resource
14:30:41 <smiles> @tlebo +1
14:31:00 <khalidbelhajjame> +q
14:31:02 <tlebo> @ivan, I think so.
14:31:07 <pgroth> ack Paolo
14:31:23 <smiles> q+
14:31:47 <Stian> http://dvcs.w3.org/hg/prov/raw-file/tip/ontology/examples/metaprovenance.trig should be able to cover that (as long as the link between the prov:Account and rdf:Statement is a bit more obvious)
14:31:59 <Stian> to identify entity records
14:32:43 <Stian> (that one mints <http://dvcs.w3.org/hg/prov/raw-file/tip/ontology/examples/metaprovenance.trig#assertion1> and #assertion2 )
14:34:49 <GK1> ack gk
14:34:49 <Zakim> GK, you wanted to respond to Ivan - does this "characerized resource" (e.g. by time) have the same URI as tbe uncharactierized resource
14:35:02 <tlebo> : tweet_1 prov:wasAttributedTo :mad_Tim . :mad_Tim prov:specializationOf <http://purl.org/twc/id/person/TimLebo> . : facebook_post_2 prov:wasAttributedTo :happy_Tim . :happy_Tim prov:specializationOf <http://purl.org/twc/id/person/TimLebo> .
14:35:25 <Paolo> q+
14:36:19 <dgarijo> If you use the same identifier in the bundle, then you can't say that a post was derived from a previous version, because it would have the same uRI
14:36:39 <Stian> exactly
14:37:05 <Stian> if you want to use two different characterisation *in the same account*, then they  need two URIs and are two entities
14:37:27 <Stian> you can then relate these using specializationOf etc.. but if you don't do it, then you don't need to worry about it
14:37:40 <dgarijo> but on the other side, it is unrelaistic to pretend that people are going to create a new entity for each version of the blog.
14:37:56 <pgroth> ack Luc
14:38:05 <tlebo> @dgarijo, they don't need to. They're just asserting it at a higher level of specificity.
14:38:22 <Stian> @luc +1
14:38:34 <Stian> @luc this is the exact why we need account/bundle/xx
14:38:59 <Paolo> q+ to ask Tim to push his specializationOf proposal
14:40:37 <Paolo> jcheney careful about what is the first thing readers see when they approach PROV
14:41:05 <Paolo> jcheney then, how do you help people generate "cool provenance"
14:41:06 <GK1> "Cool provenance" doesn't (what?)
14:42:16 <tlebo> I'm wondering if Entities are effectively closing the open world assumption.
14:42:26 <Paolo> Ivan: most readers will be happy with the primer examples -- no time deps
14:42:30 <tlebo> If that's the case, it's easy to explain :-)
14:42:48 <pgroth> q?
14:42:55 <Stian> tlebo: (!)
14:42:56 <Paolo> Ivan: then if time dependencies are a concern, then we say how they are dealt with in a principled way
14:42:58 <pgroth> ack khalidbelhajjame 
14:43:11 <tlebo> @stian what?
14:43:50 <Paolo> Khalid: it's a "how to get people to use the model correctly" concern
14:44:04 <Luc> Q?
14:44:13 <ivan> ivan has joined #prov
14:45:28 <Paolo> smiles: essentially support the specializationOf idea when additional context is needed 
14:45:30 <smiles> ack smiles
14:45:47 <tlebo> +1 Simon's "and don't say how the specializtionOf is characterized"
14:45:55 <GK1> I think the question is: when necessary, do we contextualize the thing described or the description?  I'm deeply uneasy with the latter approach.
14:46:22 <Stian> agreed
14:47:20 <Stian> that is specializationOf
14:47:35 <Stian> almost
14:47:36 <Stian> :)
14:48:18 <Paolo> @GK it's the former (the resource)
14:49:03 <Stian> [a prov:State ] prov:frozen [ a prov:Thing ]
14:49:09 <Stian> question is if prov:State == prov:Thing here
14:49:19 <Stian> the old turtles-all-the-way-question
14:49:41 <tlebo> aha! Back to F2F1's EntityState :-)
14:49:44 <Stian> yaay
14:49:58 <GK1> @paolo - that's what we do now, but i think Ivan was proposing the other.
14:50:06 <Stian> I'm putting up my old EntityState fan posters
14:53:31 <tlebo> naive web users _are_ making characterizations, it's just that they're not naming them.
14:54:57 <tlebo> so Entity is becoming a Graph?
14:56:54 <Stian> GK: "every resource is a characterisation"
14:56:57 <dgarijo> dgarijo has joined #prov
14:57:02 <pgroth> entity is a resource
14:57:25 <tlebo> so, two ways to "freeze" a characterization: 1) mint a new URI under the abstract (and add specializationOf)    2) plop the description of the abstract into a graph and name it.
14:58:27 <Paolo> @Tim I get (1) but not (2) :-)
14:58:57 <tlebo> @paolo, (2) is more like an account
14:59:59 <pgroth> q?
15:00:37 <tlebo> characterization_1 { : paolo-missier foaf:name "Paolo" }             and characterization_2 {  : paolo-missier foaf:name "Batman"   }      (where :paolo-missier is http://data.semanticweb.org/person/paolo-missier)
15:01:06 <smiles> smiles has joined #prov
15:01:47 <Paolo> Batman?!? :-)
15:02:20 <tlebo> 1)      characterization_1 foaf:name "Paolo"; prov :specializationOf <http://data.semanticweb.org/person/paolo-missier> .      and characterization_2 foaf:name "Batman"; prov :specializationOf <http://data.semanticweb.org/person/paolo-missier> 
15:02:45 <Paolo> @Tim so characterization_1  specializationOf http://data.semanticweb.org/person/paolo-missier etc.?
15:03:06 <tlebo> (within 1, or 2?)
15:03:07 <Stian> uuuh
15:03:11 <Paolo> yes ok we crossed over
15:03:45 <tlebo> repeat 2)   : characterization_1 { : paolo-missier foaf:name "Paolo" }             and    : characterization_2 {  : paolo-missier foaf:name "Batman"   }      (where :paolo-missier is http://data.semanticweb.org/person/paolo-missier)
15:04:34 <Stian> Luc is enclosing entity(post) on flipover
15:04:37 <Paolo> (1) is the more natural one for me
15:05:20 <tlebo> (2) loses the "anchor" of : paolo-missier being the characterized (and more abstract) thing.
15:06:35 <tlebo> list use cases?
15:07:01 <tlebo> use case 1 is the linked data scruffies?
15:07:11 <tlebo> use case 2 is the "provenance field" ?
15:07:17 <Stian> yes
15:07:37 <Stian> where in #2 you say deliberately "I'm thinking about 'entity-frozen-version'-thingie "
15:07:40 <jcheney> q?
15:07:42 <jcheney> q+
15:08:01 <Stian> a kind of prov:FrozenEntity 
15:08:06 <tlebo> and use cases 1 and 2 are NOT intended to mesh well correctly, right? (please!?)
15:08:32 <Stian> tlebo: must be so - #1 is scruffy, and so can't mesh well
15:08:37 <Stian> #1 does not mesh with #1' either
15:08:41 <Zakim> +??P39
15:08:43 <tlebo> those scruffies!
15:09:03 <Stian> but.. are we then not inventing contextualised bnodes which happen to have URIs?
15:09:12 <Stian> which look very official but are not to be interpreted as such
15:09:14 <Paolo> q-
15:09:16 <pgroth> ack jcheney 
15:10:08 <tlebo> I like where this is going, it pulls the "proper provenance folks" back into their field, leaving the common denominator to be the intersection of them and linked data.
15:10:15 <dgarijo> then would we go back to the entity/entity state?
15:10:25 <Stian> no it's still an entity, just a more clearly defined one
15:10:30 <GK1> Hmmm.... could be anm academic paper here, maybe:  a theory of "lifting rules" for provenance (cf. Guha thesis).
15:10:37 <tlebo> "proper provenance" would be an extension
15:10:58 <smiles> q+
15:11:06 <Stian> graceful provenance degradation
15:11:42 <GK1> I think that if we follow Paul's proposal, entities go away (for now)
15:11:49 <Stian> mm
15:12:03 <Stian> instead of entities we just have owl:Thing  (any resource)
15:12:07 <tlebo> Entity should be in the "proper provenance" extension of the prov rec. It should be subclass of rdfs:Resource .
15:12:23 <Stian> +1
15:12:34 <tlebo> we're making interoperability happen!
15:13:45 <Paolo> @tim can you clarify "proper provenance" in a sentence -- I'm still getting there...
15:14:36 <GK1> @paolo suggest "proper provenance" is validly mergable provenance. (First cut)
15:15:24 <stephenc> stephenc has joined #prov
15:15:56 <Paolo> @GK validly what?! :-)
15:15:58 <tlebo> "proper provenance" is the model that "provenance researchers" use to clearly distinguish the aspects that they find important (Luc in Boston and Luc Luc), while the rest of the world, aka "scruffies" would use (what remains in) the model to say some unclear things that they still find useful.
15:16:05 <GK1> q+ to run withj Paul's position
15:16:25 <smiles> ack smiles
15:16:42 <GK1> @paolo: logically valid
15:17:14 <Paolo> 2Tim ok got it. But Paul just zapped specializationOf which seems the right way to relate a "state" resource to its "original" resource
15:17:24 <Zakim> -[VrijeUni.a]
15:17:38 <Zakim> -??P39
15:17:40 <Zakim> -tlebo
15:17:41 <smiles> q?
15:17:54 <tlebo> @paolo, right, but specializationOf would be included in the "proper provenance" extension to what remains in the model.
15:18:28 <tlebo> *what remains in Paul's new Radically Reduced Model
15:19:13 <Zakim> +??P11
15:19:49 <smiles> q+
15:20:25 <tlebo> it's a problem in general for any information system.
15:20:34 <Paolo> Paolo has joined #prov
15:20:43 <Paolo> got kicked out
15:20:45 <Zakim> -??P11
15:21:07 <tlebo> RT @paolo, right, but specializationOf would be included in the "proper provenance" extension to what remains in the model.
15:21:28 <Zakim> +??P11
15:21:53 <jcheney> jcheney has joined #prov
15:22:31 <Zakim> +[VrijeUni.a]
15:22:42 <kai2> kai2 has joined #prov
15:23:03 <kai2> kai2 has joined #prov
15:23:19 <pgroth> pgroth has joined #prov
15:23:23 <GK> GK has joined #prov
15:23:33 <pgroth> ?
15:23:35 <pgroth> q?
15:23:38 <pgroth> ack GK
15:23:38 <Zakim> GK, you wanted to run withj Paul's position
15:23:46 <khalidbelhajjame> khalidbelhajjame has joined #prov
15:23:58 <pgroth> ack smiles
15:24:08 <jcheney> jcheney has joined #prov
15:24:13 <jcheney> q?
15:24:39 <jcheney> q+
15:24:47 <Paolo> smiles: a consequence of Paul's proposal is that attributes disappear
15:25:13 <dgarijo> +q
15:25:21 <Stian> q+ would attributes be any different from normal RDF properties in an RDF resource?
15:25:31 <Stian> q+
15:25:32 <Paolo> Paolo is confused about this
15:25:35 <Paolo> q+
15:25:48 <pgroth> ack jcheney 
15:26:30 <Paolo> James, Ivan: lots to remove from the doc, then reconstruct
15:26:50 <Paolo> Luc: but with no prior art, we are starting from scratch at a late stage in the process
15:27:37 <tlebo> what prior art is missing?
15:27:42 <Paolo> Paul: most of the model stays, we just need to define a new domain for most of the relations. domains are "looser"
15:28:04 <Paolo> Paul: need to be careful about the ramifications. 
15:28:16 <Paolo> jcheney what we have now is largely consistent
15:28:41 <pgroth> ack dgarijo 
15:28:49 <Paolo> jcheney strip material first, then see what we can do with what is left
15:29:00 <Zakim> +Satya_Sahoo
15:29:05 <Paolo> dgarijo: what happens to versions?
15:29:36 <tlebo> Version isn't core, it can be phrased within core terms.
15:29:53 <GK> I thought we were exploring a possibility rather than trying to frame a proposal
15:30:03 <satya> satya has joined #prov
15:30:22 <Paolo> Luc: propose to remove distinction b/w entities and things, this is enough to address the scruffy provenance (SP)
15:30:32 <smiles> smiles has joined #prov
15:30:45 <Paolo> then address what more is required to formulate Proper Provenance (PP)
15:31:07 <kai> +1
15:31:18 <tlebo> ProP
15:31:26 <dgarijo> :D
15:31:38 <dgarijo> ProP-O
15:31:43 <Paolo> and ScruP?
15:32:57 <tlebo> Characterized things are things....
15:33:05 <GK> I think a formal semantics of "scruffy provenance" would be somewhat different from the current semantics, and either trivial or rather interesting.
15:33:09 <tlebo> (so are turtles)
15:34:09 <Stian> yes!
15:35:31 <tlebo> specializationOf and alternateOf leave RRM and go into ProP.
15:36:45 <GK> q+ I think there's more here than "just explaining it" (scruffy vs proper)
15:36:50 <tlebo> - owl:sameAs does NOT serve save purpose as alternativeOf or specializationOf...
15:36:56 <tlebo> s/save/same/
15:37:03 <GK> q+ to say I think there's more here than "just explaining it" (scruffy vs proper)
15:37:43 <Stian> tlebo: no, but the need for alternativeOf/specializationOf changes slightly if we reconstruct what kind of links we really need on ye Frozen thingies
15:37:46 <pgroth> ack Stian
15:37:50 <Stian> q-
15:38:31 <tlebo> what is being said?
15:38:50 <pgroth> @tlebo can you hear now?
15:38:53 <tlebo> no
15:38:56 <tlebo> just voices
15:39:28 <Luc2> Luc2 has joined #prov
15:39:44 <tlebo> q+
15:40:00 <tlebo> q-
15:40:10 <tlebo> q+ to ask for a recap of that last bit of discussion
15:40:48 <Paolo> there are a few things I don't understand.
15:40:50 <Stian> Stian: I said had an old comment.. something like: I believe attributes on a prov:Entity is just like properties on an RDF resource within an RDF Graph, that is it is somehow valid within the scope of the graph. (ie. the prov:Account if you like). It is the general problem Ivan has talked about what that scope is. 
15:41:04 <Paolo> 1) what exactly happens to specializationOf
15:41:10 <Paolo> 2) what happens to attributes
15:41:12 <satya> Can't hear properly
15:41:28 <tlebo> satya, hop onto a skyper
15:41:36 <satya> ah ok
15:41:54 <dgarijo> I can call you on skype satya
15:42:03 <satya> thanks Daniel!
15:42:04 <pgroth> pgroth has joined #prov
15:42:05 <khalidbelhajjame> khalidbelhajjame has joined #prov
15:42:30 <Stian> now everyone is mumbling
15:42:38 <Stian> I can't hear anything either :)
15:42:41 <Stian> q?
15:42:54 <tlebo> @stian, you're not there?
15:42:58 <GK> GK has joined #prov
15:43:09 <Zakim> -Satya_Sahoo
15:43:17 <Stian> Stian: propose to put a line, finish the queue, and then break
15:43:21 <Stian> NOTHING OUTSIDE QUEUE
15:43:37 <Stian> Luc: Just 45 minutes left
15:43:55 <Stian> Luc: propose take 5 minutes brea, then include people on the phone in PROV-O talk
15:44:00 <tlebo> I guess I lost my window for a recap on the end of that discussion.
15:44:11 <dgarijo> Tim and Satya are on Skype
15:44:19 <dgarijo> they can hear now well :)
15:44:31 <pgroth> who can not hear?
15:44:36 <satya> thanks again Daniel!
15:44:42 <dgarijo> no prob
15:45:15 <Stian> are we following the queue?
15:45:59 <GK> My version of what happened in the last hour or so.  We considered a radical alternative approach to address a "scruffy" use case for provenance, and did not come to a clear conclusion of which way to jump.
15:45:59 <dgarijo> summary - replace entity with thing in the document. Accounts are going to be taken out and now there is a "bundle" for a set of provenance assertions.
15:46:02 <tlebo> so, Core, RRM, and ProP ?
15:46:27 <tlebo> ivan: clearly separate sections in prov-dm for these three
15:46:46 <tlebo> q-
15:46:51 <dgarijo> 5 min break
15:46:52 <Stian> ----- 5 minute break - then talk about PROV-O
15:47:04 <GK> I think care is needed: if we address the scruffy use case as proposed, I think there are knock-on effects for the more formal uses.
15:47:08 <GK> ack gk
15:47:08 <Zakim> GK, you wanted to say I think there's more here than "just explaining it" (scruffy vs proper)
15:47:20 <Paolo> ack
15:47:23 <Paolo> q?
15:47:26 <Paolo> q-
15:54:18 <tlebo> who is not physically at the meeting?
15:55:40 <dgarijo> satya, tim, yolanda, mcted, stephen, sandro, mike, 
15:57:34 <tlebo> macted, are you tall ted from RDF 1.1 F2F2?
15:58:18 <MacTed> tlebo - yes, that's me
15:58:20 <Luc> Luc has joined #prov
15:59:26 <Paolo> TOPIC PROV-O
15:59:27 <Stian> tlebo: oooh.. that's an entity!
15:59:29 <Luc2> Q?
15:59:46 <dgarijo> dgarijo has joined #prov
15:59:51 <smiles> q?
16:00:02 <tlebo> @paolo, scribed out? Is that like Paul's "interoperability-y" from earlier?
16:00:07 <Stian> Satya and Tim - can you hear us?
16:00:10 <tlebo> yes
16:00:17 <dgarijo> satya?
16:00:19 <satya> yes - some mumbling
16:00:31 <Stian> Tim - can you talk?
16:00:50 <GK> GK has joined #prov
16:01:18 <Paolo> Tim: it's been very difficult to make progress on it
16:01:25 <GK> TOPIC: PROV-O
<pgroth> Summary: Concerns were raised about the ability to synchronize prov-o with prov-dm. In particular, about how to know what is changed and what is not in the prov-dm. A process was agreed on to facilate synchronization. An ontology that reflects the current WD-3 version would be produced for review. Because of the possibility of the change in accounts, the updated ontology does not need to reflect accounts. Again, it was encouraged that the ontology follow owl-rl.
16:01:31 <jcheney> jcheney has joined #prov
16:01:33 <smiles> smiles has joined #prov
16:01:37 <Paolo> Tim:  with RDF encoding being a second class citizen
16:01:45 <smiles> q?
16:01:46 <Paolo> TL not good RDF-based examples
16:01:57 <Zakim> +[OpenLink]
16:02:02 <pgroth> pgroth has joined #prov
16:02:12 <GK> TL: Problem to make progress with PROV-O - lacking sufficient raw content to make progress.
16:02:12 <MacTed> Zakim, [OpenLink] is temporarily me
16:02:15 <MacTed> Zakim, mute me
16:02:25 <Paolo> Tim: prov-DM not useful to approach the ontology, and so unable to make progress for past few weeks
16:03:16 <pgroth> Zakim, who is on the phone?
16:03:27 <Zakim> +MacTed; got it
16:03:31 <Zakim> MacTed should now be muted
16:03:33 <satya> q+
16:03:56 <GK1> GK1 has joined #prov
16:04:20 <Stian> Luc: Two aspects: a) writing ontology  b) writing the document
16:04:26 <Zakim> On the phone I see [VrijeUni], ??P11, [VrijeUni.a], MacTed (muted)
16:04:27 <Paolo> Luc: there are two aspects: writing ontologies and docs
16:04:43 <satya> q+
16:04:59 <Paolo> Tim: both cannot be done but not against the current DM as it's a moving target.
16:05:45 <Paolo> q+
16:05:47 <Paolo> q?
16:06:03 <Mike> Mike has joined #prov
16:06:27 <satya> @Paolo: Zakim is lagging in keeping up with speaker queue?
16:06:28 <Paolo> q+ to ask Tim what it would take for DM to be able to resume progress
16:06:53 <Paolo> Satya: ontology cannot be built piecemeal
16:07:15 <Paolo> Satya: it can only be modelled when DM is in mature state
16:07:33 <Paolo> Satya: uncomfortable with the piecemeal approach
16:07:55 <GK1> (I have a lot of sympathy with Tim et al -- it's hard to track DM -- especially after today's discussion)
16:08:02 <Stian> +1
16:09:01 <Paolo> Satya: as a consequence, current ontology is not a coherent whole 
16:09:25 <tlebo> q+
16:09:53 <tlebo> q?
16:10:17 <satya> q-
16:10:22 <Paolo> q-
16:10:26 <Paolo> q?
16:10:49 <Stian> Luc: we should talk about process instead of technical issues here now  - if something in DM does not work, then that should be expressed [in the WG] and raised as issues
16:10:58 <Paolo> Luc: need suggestions on how to proceed
16:11:19 <jcheney> q+ to point to ProvRDF mapping draft
16:11:30 <Stian> +1 the same, I have to re-read PROV-DM everytime I look at it 
16:11:33 <Paolo> Tim: every change to prov-o requires a fresh re-read of DM
16:11:47 <khalidbelhajjame> khalidbelhajjame has joined #prov
16:12:10 <smiles> smiles has joined #prov
16:12:47 <pgroth> pgroth has joined #prov
16:12:58 <Paolo> Tim: also, previous versions of prov-o are needed to rework each example for a new version
16:13:56 <satya> q+
16:14:35 <Paolo> GK: how long before you can complete ontology and doc once DM has been stabilized
16:15:11 <Paolo> GK: propose to pause the -O work until DM is stable
16:15:36 <adamretter> adamretter has joined #prov
16:16:17 <Paolo> q+
16:16:25 <pgroth> ack tlebo
16:16:32 <tlebo> @GK, yes, I like your suggestion. after DM is "frozen", we could nail it in a couple of weeks. But what we _produce_ needs to be reviewed by the group AND considered for each subsequent change to DM.
16:16:32 <pgroth> ack satya
16:16:47 <Stian> tlebo: exactly - need to close the loop
16:16:57 <Stian> for instance we made QualifiedInvolvement - that has not influenced DM
16:17:06 <Paolo> Satya: the whole of the ontology is impacted whenever changes are made to -DM
16:17:26 <tlebo> for each proposed change to DM, it's affect on PROV-O should be a first class citizen (not "prov-o" will figure it out)
16:17:33 <pgroth> but I thought QualifiedInvolvement was to support the relastions in DM
16:17:37 <Paolo> Satya: are we introducing contradictory concepts in the DM
16:17:48 <khalidbelhajjame> +q
16:17:54 <dgarijo> @Tim: I think that the core of the model has been "frozen" for some time: use, generation, association, activities and entities.
16:18:02 <pgroth> q?
16:18:39 <Paolo> Luc: some of the core concepts have been stable in DM for a long time
16:19:20 <tlebo> there is a difference between "stable" and "stagnant"
16:19:22 <GK> GK has joined #prov
16:19:31 <tlebo> we've been stagnant, unfortunately.
16:20:00 <Paolo> Satya: difference between entities and entity records has an impact in -O
16:20:15 <pgroth> q?
16:20:21 <pgroth> ack jcheney
16:20:21 <Zakim> jcheney, you wanted to point to ProvRDF mapping draft
16:20:53 <jcheney> http://www.w3.org/2011/prov/wiki/ProvRDF
16:21:03 <satya> @Tim, Stian: I also agree with "closing the loop" from DM->O->DM and so on
16:22:12 <pgroth> q?
16:22:13 <MacTed> RDF isn't a syntax...  do you mean RDF/XML, RDFa, Turtle, N3....?
16:22:43 <jcheney> @MacTed: No idea, just writing abstract triples.
16:23:03 <ivan> q+
16:23:12 <tlebo> a frozen DM will help.
16:23:14 <ivan> ack Paolo 
16:23:16 <pgroth> ack Paolo
16:23:41 <dgarijo> @tlebo: I thought that we were working with the releases of the dm.
16:23:52 <dgarijo> @tlebo: as "frozen"
16:24:13 <ivan> q-
16:26:06 <pgroth> @MacTed - i'm sorry
16:26:10 <pgroth> it's been a nightmare
16:26:29 <pgroth> I have a speaker phone on but that seems to fall off
16:27:44 <pgroth> q?
16:28:17 <pgroth> ack khalidbelhajjame 
16:28:35 <satya> Can't hear anything!
16:28:49 <tlebo> q+ to say we have a poor measure of "up to dateness" for prov-o
16:28:53 <satya> oh Daniel lost connection I believe
16:28:54 <tlebo> ( I can't hear anything)
16:28:57 <Luc2> Luc2 has joined #prov
16:29:14 <jcheney> out phone connection dropped!
16:29:23 <Paolo> Khalid: most of the -O time has been used in resolving mapping issues rather than in making updates wrt older versions
16:29:33 <Zakim> +[IPcaller]
16:29:37 <jcheney> khalid: most of prov-o telecon has been on how to model PROV-DM.
16:29:48 <Zakim> -[IPcaller]
16:30:22 <tlebo> q?
16:30:49 <dgarijo> khalid: most of the time on the prov-o telecons was spent on the n-ary relationships modeling.
16:30:49 <Paolo> Khalid: mapping took a long time
16:31:01 <Paolo> Khalid: but there was indeed some chasing
16:31:44 <satya> @Khalid +1
16:31:46 <Luc2> Q?
16:31:48 <tlebo> +1 to reorganizing for a better story, instead of a dump of properties.
16:31:50 <tlebo> q?
16:31:58 <pgroth> ack tlebo
16:31:58 <Zakim> tlebo, you wanted to say we have a poor measure of "up to dateness" for prov-o
16:32:07 <GK> GK has joined #prov
16:32:20 <Paolo> Tim: what would help is a measure of "up-to-dateness" and of coverage 
16:32:48 <dgarijo> @tlebo: so basically, more feedback from the rest of the group?
16:32:49 <pgroth> q?
16:33:05 <Paolo> Tim: we don't have a good perception of the completeness of the work.
16:33:18 <satya> @Tim: agree, we should have feedback on PROV-O also
16:33:18 <Paolo> Tim: raising issues against the document is fine
16:33:40 <smiles> smiles has joined #prov
16:33:50 <Paolo> Luc: there hasn't been any request for review of the draft
16:35:05 <Paolo> Satya: got no feedback after first draft
16:35:13 <tlebo> @satya, but that makes us the "target movers" :-)
16:36:56 <jcheney> jcheney has joined #prov
16:37:14 <satya> @Tim ;)
16:37:15 <Paolo> Tim: need feedback on current draft
16:37:18 <pgroth> q?
16:38:11 <pgroth> q?
16:38:18 <Paolo> Stian, dgarijo:  missed a clear iteration loop for -O, with stable milestones 
16:38:27 <Luc2> Q?
16:38:31 <tlebo> q+ to verify that latest WD of DM is coming out "today"?
16:38:44 <Paolo> Satya: next iteration should begin once DM is frozen 
16:39:14 <tlebo> wanted to propose that we develop the complete OWL of the latest DM.
16:39:22 <tlebo> is "latest" coming out today?
16:39:39 <Luc2> Yes, release today
16:39:59 <satya> @Tim: good one :)
16:42:32 <tlebo> 1) we catch up to WD3 2) we ask for review from wg
16:42:41 <Paolo> Paul:  propose that the PROV-O team attempts to reflect on the current -DM release
16:43:05 <Paolo> Paul: when done, it is released for feedback
16:43:23 <tlebo> +1
16:43:27 <dgarijo> @Paul: +1
16:43:50 <Paolo> Paul: then Paul will work to identify the further changes needed in view of the upcoming changes to PROV-DM that are happening starting tomorrow
16:44:04 <tlebo> both
16:44:17 <Paolo> Luc: what is the next PROV-O release:  ontology, doc?
16:44:23 <satya> both
16:44:54 <tlebo> for each construct: edit HTML, edit OWL.
16:45:12 <dgarijo> dgarijo has joined #prov
16:45:17 <pgroth> why not just ontology?
16:45:36 <tlebo> b/c the axioms need an explanation and a connection back to DM.
16:46:55 <Paolo> Paul: suggest to circulate ontology first, it's faster and nearly everyone in the group can understand and provide feedback
16:46:55 <tlebo> @pgroth, makes sense.
16:47:27 <jun> how about including some brief annotations in the ontology?
16:47:35 <pgroth> +1 jun
16:47:40 <jun> @pgroth +1
16:48:34 <pgroth> ivan saying owl rl is important
16:48:52 <tlebo> +1 @ivan, heavy semantics is undesired.
16:48:54 <Paolo> Ivan: prov-o looks like an OWL-RL ontology
16:49:19 <khalidbelhajjame> khalidbelhajjame has joined #prov
16:49:24 <Stian> what current document also does is show RDF examples (OK, in RDF/XML) which for myself is also a good way to visualise an ontology (Given only an OWL file, I would write down such examples)
16:49:46 <tlebo> @stian, let's make an examples file, too.
16:49:51 <Paolo> Ivan and that's good news from the perspective of a path to implementation
16:49:53 <Stian> which is what Tim used to do back in the good days :)
16:49:59 <Stian> yes
16:50:18 <tlebo> http://www.w3.org/2011/prov/wiki/PROV_OWL_ontology_components ?
16:50:19 <khalidbelhajjame> http://www.w3.org/TR/owl-profiles/#OWL_2_RL
16:50:39 <Paolo> Paul: (explains the process again -- see above)
16:50:43 <satya> audio dropping intermittently
16:50:44 <ivan> q=
16:50:46 <ivan> q+
16:51:07 <satya> can't hear
16:51:27 <pgroth> ack ivan
16:51:29 <satya> Paul can you please repeat?
16:51:35 <tlebo> +1^10
16:51:39 <Paolo> Luc: we have also agreed to coordinate the two groups in a specific confcall 
16:51:50 <pgroth> Process
16:51:55 <Paolo> Ivan:  please avoid RDF/XML, use Turtle itself
16:52:04 <Stian> (in the document)
16:52:08 <dgarijo> +1
16:52:14 <MacTed> +1^1000 Turtle, -1^1000 RDF/XML   :-)
16:52:18 <tlebo> http://prefix.cc/prov
16:52:27 <tlebo> http://www.w3.org/ns/prov-o/
16:53:01 <satya> didn't hear anything in last 5 mins
16:53:07 <Paolo> @Satya Paul essentially repeated the process as I tried to capture earlier
16:53:08 <pgroth> are you on zakim
16:53:14 <tlebo> I can hear
16:53:26 <Paolo> @Satya we are trying to skype you back in
16:53:46 <satya> ok thanks!
16:54:12 <tlebo> rdfa
16:54:20 <GK> Ivan: why not prov: instead of prov-o:
16:54:55 <tlebo> @ivan, hash or slash ;-)
16:55:04 <satya> yes, I can hear now!
16:55:18 <ivan> tim, I let you decide that:-)
16:55:20 <pgroth> Process-
16:55:32 <ivan> actually? with a document of this size, I think slash is simpler
16:55:34 <tlebo> +1 to process Paul outlined.
16:55:40 <pgroth> 1) prov-o team to reflect wd3 prov-dm only in an ontology
16:55:54 <pgroth> 2) when complete prov-wg to review after notification
16:56:21 <tlebo> @ivan, size is big or small?
16:56:21 <pgroth> 3) when new prov-dm becomes available chairs will compare and determine what they think is necessary to update
16:56:28 <ivan> By the way: http://en.wikipedia.org/wiki/Provo_(movement)
16:56:32 <tlebo> +1
16:56:35 <dgarijo> +1
16:56:58 <ivan> tlebo:  what I meant is the number of terms in the ontology is relatively small
16:57:07 <tlebo> Thanks.
16:57:14 <Luc2> Btw, without Account ....
16:57:35 <dgarijo> @Luc: we don't have account in prov-o right now.
16:58:32 <tlebo> mission - owl:Annotations and rdfs:comments galore in prov.owl
16:59:22 <pgroth> luc: don't spend cycles on modeling accounts 
16:59:39 <khalidbelhajjame> Alignment with prov-dm as released today minus accounts
16:59:53 <tlebo> lost sound
16:59:58 <tlebo> and your food is getting cold.
17:00:13 <pgroth> we start at 9:00 cet
17:00:22 <pgroth> thanks!
17:00:24 <pgroth> thanks tlebo
17:00:25 <tlebo> i get to sleep in tomorrow!
17:00:26 <Zakim> -MacTed
17:00:30 <tlebo> ttyl, all.
17:00:34 <satya> bye
17:00:36 <khalidbelhajjame> Tim, well deserved :-)
17:01:50 <Zakim> -[VrijeUni.a]
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00001753