Provenance Working Group Teleconference -- 23 Jun 2012

<CraigTrim> pgroth: maintain subProperty hierarchy in PROV-O since it exists in DM

<Luc> q/

<Luc> proposed: constraints that don't appear in prov-dm should not be encoded in the ontology

<jcheney> +1

<TomDN> +1

<khalidBelhajjame> +1

<CraigTrim> +1

<Curt> +1

<dcorsar_> +1

<Paolo> +1

<zednik> +1

<tlebo> +.98

<Dong> +1

<Luc> accepted: constraints that don't appear in prov-dm should not be encoded in the ontology

<Curt> I would word it "It should be possible to express anything compliant with the DM using the ontology"

<pgroth> +1 for curt

<pgroth> +q

<TomDN> That's exactly what makes it a nice line between syntactic validity and "semantic" validity

<TomDN> (or "constrained" validity, whatever)

<jcheney> Since the constraints & inferences are still allowed/encouraged, in a REC, I don't think we lose anything here - just observe that there is an instance of PROV-O that bakes them in

<Curt> (keep a CM tag for the version of the .owl just prior to removing all the constraints)

PROV-N

<TomDN> Paulo: about PROV-CONSTRAINTS: could we have a notion of "well-formed"-ness

<TomDN> Luc: Back to PROV-N: any issues?

<Zakim> Paolo, you wanted to make a point later on prov-constraints regarding validation

<TomDN> pg: for internationalization: we can go to LC, and ask internationalization responsibles if it's allright

<TomDN> ... or how we can do it

<pgroth> ACTION: ivan to check when we should do internationalization and how for PROV-N [recorded in http://www.w3.org/2012/06/23-prov-minutes.html#action01]

<trackbot> Created ACTION-94 - Check when we should do internationalization and how for PROV-N [on Ivan Herman - due 2012-06-30].

<TomDN> Luc: In an earlier version there was a language tag over Strings, and it was removed

<TomDN> ... Any technical issues?

<TomDN> Luc: There is an issue for LC, that if a MIMETYPE is used, a request needs to be put in

<TomDN> Luc: 1st question: is the group fine with a MIMETYPE in PROV-N?

<TomDN> Luc: 2nd question: are we happy with the name?

<pgroth> text/prov-n

<TomDN> tlebo: we're already covered for RDF types (existing stuff out there)

<TomDN> jcheney: why not text/prov ?

<TomDN> ... It automatically maps to prov-n

<Zakim> jcheney, you wanted to ask why not text/prov

<TomDN> tlebo: recommend keeping the n

<TomDN> ... because of the various ways to specify provenance

<TomDN> +1 tlebo

<TomDN> hook: +1 tlebo

<TomDN> ... imagine prov-json etc

<TomDN> jcheney: I planned for this! hahah!

<TomDN> ... (and you matched my expectations)

<Luc> accepted: mime type for prov-n is text/prov-n

PROV-CONSTRAINTS

<hook> text/prov-{textual encoding scheme}

<TomDN> Luc: coming back to the compliance section

<Dong> @hook the MIME type for JSON is application/json

<TomDN> jcheney: We need a clear idea whether there is consensus if something like what we have now is acceptable

<Dong> @hook I don't think we should have new MIME types for XML, JSON, and RDF

<TomDN> ... so maybe more people should read it

<tlebo> @dong (is there a mimetype for xml?)

<TomDN> ... To respond to Paulo's question (is it feasible to check validity?): we shouldn't include anything that's impossible to check computationally

<Dong> tlebo: I thought it was application/xml

<Curt> prov-json is more specific (more tightly defined) than application/json e.g.

<TomDN> ... So nothing undecidable

<tlebo> @dong, ya. application/xml

<TomDN> ... I've tried to organize things in terms of inferences and definitions you can comply with

<TomDN> ... We still need to specify what to do with optional arguments

<TomDN> ... We may want uniqueness constraints.

<zednik> @Dong, tlebo: application/xml and text/xml

<TomDN> ... We also want to be able to say that some things are not allowed. (like cycles and stuff)

<TomDN> ... We also might want some normalization in there

<TomDN> ... So there are both technical and representation issues remaining.

<TomDN> Paulo: Are the provenance descriptions intended to be distributed?

<TomDN> jcheney: yes, but it's up to the asserter to specify this

<tlebo> @jcheney, as it should be "it's up to the reader to decide" what circumscribes the assertions.

<tlebo> +1 @jcheney

<TomDN> Paolo: it's basicly validating a set of assertions, regardless of where they are

<TomDN> pg: We addressed the distributed validation pretty well with validators in the Semantic Web

<TomDN> pg: This document is very important for building a validator

<jcheney> Can we collect the feedback from developers somewhere?

<TomDN> ... it's part of the compromise of scruffiness

<TomDN> ... to have a validator

<TomDN> +q

<Dong> +1 to validator

<jcheney> As I unerstand it there will have to be implementations of validation for the prov-constraints to proceed on REC track

<pgroth> but they work - good enough

<TomDN> tomdn: So that corresponds to what Luc said before, a validator is one of the implementations we really want to have

<TomDN> ,,, and the CONSTRAINTS are the basis for that

<TomDN> ... and the CONSTRAINTS are the basis for that

<TomDN> ... so everything should be computable (cfr. jcheney)

<pgroth> something like http://inspector.sindice.com/

<tlebo> @paulo, not enough prior art for us to standardize. You're expressing practical concerns that are application-specific, which we can't help as a WG.

<TomDN> Paulo: we can't impose a closed world assumption

<TomDN> dong: I like the idea of the 2 levels of compliance, syntactic and "semantically"valid

<TomDN> kind of like HTML strict, right?

<jcheney> Just to be clear, curently VALID means "satisfies all constraints"

<TomDN> (kind of)

<tlebo> +1 @paolo "distribution is a secondary problem" that distracts from a validator.

<TomDN> paolo: There's a good basis for this validation (ignoring the distribution issues), combined with what's out there

<Paulo> coonstraints and best practices may be co-designed

<TomDN> Luc: So I don't see technical objections raised against the compliance section, except maybe the 2 levels of validation

<TomDN> jcheney: agreed

<Curt> I would call the levels "DM compliant" and "CONSTRAINTS compliant"

<TomDN> pg: I think it's fine to say there's only one level of validity, but that the validator has levels of response

<TomDN> ... it's up to implementer of the validator, not to us

<TomDN> jcheney: agreed

<TomDN> Paulo: Validating everything at once is very hard, but smaller parts might be feasible

<TomDN> Curt: I would define the levels of compliance with DM and CONSTRAINTS separatly

<TomDN> Paolo: It's not clear to me if there are problems with the decidability of the constraints

<TomDN> Paolo: The technical discussion should be had offline, before dismissing the document

<TomDN> +q to ask if we should just make this a reviewer question: Are there things in the document that lead to undecidability?

<TomDN> Luc: maybe it shouldn't be called CONSTRAINTS, but VALIDITY?

<Zakim> TomDN, you wanted to ask if we should just make this a reviewer question: Are there things in the document that lead to undecidability?

<TomDN> Luc: i don't hear objections to the compliance section, on the contrary, there is large support for it

<TomDN> jcheney: Could use some help in editing the constraints

<TomDN> ... but input such as today's is valuable

<TomDN> ... We should keep in mind: There's no point in standardizing something that's not computable.

<TomDN> ... Would be happy with a proposal to comfirm this.

<Luc> proposed: prov-constraints document should ensure decidability of constraints

<TomDN> +1

<jcheney> +1

<khalidBelhajjame> +1

<tlebo> +1

<zednik> +1

<dcorsar> +1

<Dong> +1

<Curt> +1

<TomDN> actually, +MAX_INT

<Luc> accepted: prov-constraints document should ensure decidability of constraints

<pgroth> trackbot end telcon

<khalidBelhajjame> bye

<pgroth> trackbot, start telcon

<trackbot> Date: 23 June 2012

<pgroth> Guest: Hook Hua

<dgarijo> are the minutes from yesterday available somewhere? I'd like to know what happened with contextualization :)

<Luc> http://www.w3.org/2011/prov/meeting/2012-06-22

<dgarijo> thanks!

Remaining Notes (prov-dc, prov-xml, prov-json, prov-bestpractice, prov-sem)

<tlebo> Luc: We want to identify remaining work.

<tlebo> ... so we can write credible charter extension.

<pgroth> +q to respond

<pgroth> 1-

<pgroth> other notes?

<tlebo> Tim: RPI is looking to submit a member submission for PML 3.0

<tlebo> Luc: The charter decided that mappings would not be done by the WG, but the individual organizations.

<tlebo> Daniel: concerned that he has been the only one working on the prov-dc. Not enough feedback.

<tlebo> Luc: moved everything to W3C infrastructure?

<tlebo> Daniel: yes.

<pgroth> @tlebo you could use the irc names :-)

<pgroth> use tab

<tlebo> luc: schedule?

<tlebo> dgarijo: mappings by end of month, with bnodes.

<tlebo> dgarijo: second stage of the mapping, removing the extra data - can't get to this.

<tlebo> dgarijo: by end of month can get the document that they promised.

<tlebo> dgarijo: many members will be away.

<tlebo> luc: how important is the second part? can it be self-contained?

<tlebo> dgarijo: the most important part is the direct mappings (we have concensus).

<tlebo> luc: I'm trying to identify the reachable goals.

<tlebo> ... end of july need charter extension.

<tlebo> ... need to know what to put into the extension request. What to promise?

<tlebo> dgarijo: will go discuss on Wed meeting with DC folks.

<tlebo> pgroth: dc doc direct mappings are straight forward. No reason not to have direct mapping document.

<tlebo> ... does not need to be delivered like Rec documents.

<tlebo> ... reasonable to have direct mappings as a minimum.

<tlebo> ... yes DC doc as Note, we're done and its small.

<tlebo> ... no reason for @dgarijo to go nuts.

<tlebo> luc: the WG will produce a Note deliverable mapping DC and PROV.

<Luc> proposed: the WG to produce a note DC to PROV mapping

<dgarijo> +1

<tlebo> +1

<jcheney> +1

<Curt> +1

<dcorsar> +1

<zednik_> +1

<reza_bfar> +1

<Luc> accepted: the WG to produce a note DC to PROV mapping

<tlebo> ACTION: dgarijo to discuss note and make timetable and type of work with DC folks, when will it be done for final internal review? [recorded in http://www.w3.org/2012/06/23-prov-minutes.html#action02]

<trackbot> Created ACTION-95 - Discuss note and make timetable and type of work with DC folks, when will it be done for final internal review? [on Daniel Garijo - due 2012-06-30].

prov-xml

<tlebo> subtopic: prov-xml

<tlebo> luc: not much work on prov-xml. draft xml schema created and udpated by @luc

<tlebo> ... seems that since we're about LC for DM, prov-xml can start up.

<tlebo> zednik_: the stakeholders were interested in XML.

<tlebo> luc: would be nice to have a few people to look over the schema.

<tlebo> curt, hook, stephan, david offered to help.

<tlebo> hook: patterns on ISO lineage spec that we can borrow.

<tlebo> pgroth: more importantly, how much text does prov-xml want to write?

<tlebo> ... as in prov-o, narrative around the constructs.

<tlebo> ... there hasn't been effort around the narrative on prov-xml.

<Curt> Using PROV-XML will require the user to read PROV-DM

<tlebo> ... can we make sure that we have no major narrative.

<tlebo> hook: mirror prov-o in that mirrors DM?

<tlebo> prov-o's "no constraints" in prov-xml?

<tlebo> pgroth: nobody explaining the prov-xml schema.

<tlebo> ... we should avoid that level of effort b/c we dont' have it.

<tlebo> ... what _exactly_ are we committing to.

<reza_bfar> Is there an extension to Protege that generates XML from OWL?

<reza_bfar> Can we just use a code generator?

<reza_bfar> to go from Prov-O to Prov-XML?

<Luc> accepted: the WG to produce a note for prov-xml with minimal narrative

<Curt> a hand generated PROV-XML will be more friendly to use...

<tlebo> luc: not accepted!

<zednik_> Do we have UML that we can generate XML from?

<Luc> proposed: the WG to produce a note for prov-xml with minimal narrative

<Curt> +1

<khalidBelhajjame> +1

<jcheney> +1

<dcorsar> +1

<zednik_> +1

<dgarijo> +1

<tlebo> +1

<reza_bfar> +1

<Dong> +1

<CraigTrim> +1

<Luc> accepted: the WG to produce a note for prov-xml with minimal narrative

<tlebo> repeat: curt, hook, stephan, david offered to help.

<tlebo> subtopic: prov-json

<tlebo> luc: charter did not mention json

<tlebo> ... Dong has been doing json at SH. There has been interest in prov-json.

<tlebo> pgroth: NO!

<tlebo> ... it is important for uptake, but we have a lot of bandwidth issues on Rec docs already.

<tlebo> ... (feature creep)

<tlebo> ... use a member submission.

<tlebo> reza_bfar: xml and json, code generation from prov-o?

<jcheney> community group? see http://json-ld.org/spec/latest/

<tlebo> ... a lot of work to keep in sync between all of the encodings.

<tlebo> ... "Brazil" extension mapped OWL to XML.

<Curt> OWL-> XML is hard, XML -> JSON is easy

<tlebo> zednik_: rdf to json (rdf-json)

<tlebo> pgroth: as jcheney says, with json, there is "json-LD" which is json encodings of rdf.

<tlebo> ... we don't know enough to fix it.

<tlebo> dong: tried json-ld mapping, result was undesireable.

<tlebo> ... didn't serve purposes.

<tlebo> ... big hassle.

<tlebo> pgroth: propose that SH does member submission.

<Zakim> pgroth, you wanted to propose member submission from southampton

<tlebo> @jcheney not that json-LD, but also a process for community groups to develop things like this.

<tlebo> ... if a large group that wants it, then let them do it.

<Luc> proposed: the WG will not produce a prov-json note

<tlebo> +1

<TomDN> +1

<reza_bfar> +1

<Curt> +1

<jcheney> +1

<khalidBelhajjame> +1

<CraigTrim> +1

<zednik_> +1

<dcorsar> +1

<dgarijo> +1

<Dong> +1

<Luc> accepted: the WG will not produce a prov-json note

<tlebo> subtopic: prov-best practice

<tlebo> ( http://dvcs.w3.org/hg/prov/raw-file/tip/bestpractices/BestPractices.html ? )

<tlebo> pgroth: reads from charter

<tlebo> tlebo: best practices can help answer public question

<Zakim> jcheney, you wanted to ask whether this is an appropriate home for collections

<tlebo> jcheney: can Collections go to best practices?

<tlebo> zednik_: best practices come from lots of experience. finding out what works.

<tlebo> ... picking a best practice from the beginning is odd.

<tlebo> ... it is a development iteration.

<tlebo> ... we need experience from the real world.

<Curt> rename to PROV-EXAMPLES or PROV-COOKBOOK

<reza_bfar> Agree with Stephan. Could this be a document that we do post recommendation? I (and other implementers) could help

<tlebo> pgroth: suggest not doing a best practice document. we have DC and Collections.

<tlebo> ... we have examples in the primer.

<tlebo> ... best way to do it is to mint Notes out of thin air as we go along. But let's not commit to it.

<tlebo> zednik_: best practices are iterative, needs time to evolve.

<dgarijo> (I've lost all sound)

<Luc> hi daniel, we have to redial, we were running out of credit

<dgarijo> ah ok, sorry, I didn't hear the last part because had to attend a phone call.

<Luc> back in 10 sec

<tlebo> luc: seemed that best practice is not something that we should commit to doing. Because of iteration and development.

<tlebo> ... if we do it, we'll do it later. Not part of the extension request.

<Luc> proposed: the WG will not include a best practice deliverable in the charter extension request

<khalidBelhajjame> +1

<reza_bfar> +1

<Dong> +1

<Curt> +1

<TomDN> +1

<tlebo> +1

<dcorsar> +1

<zednik_> +1

<jcheney> +1

<dgarijo> +1

<Luc> accepted: the WG will not include a best practice deliverable in the charter extension request

<tlebo> subtopic: prov-collections

<pgroth> we agreed it was a note

<tlebo> luc: where do Dictionaries go?

<tlebo> pgroth: the resolution said into a Note

<tlebo> luc: note by itself?

<tlebo> pgroth: by itself, there's enough content.

<tlebo> curt: needs to be its own primer.

<tlebo> luc: goes into charter extension?

<tlebo> ... a lot of work went into dictionaries.

<Curt> It has 2 purposes: 1) define prov for collections 2) show how to build extensions on top of PROV-DM in general

<tlebo> pgroth: its' something that we agreed on doing.

<tlebo> ... we need to be careful about looking like were adding to the charter.

<tlebo> luc: "Collection" was already in the charter.

<tlebo> tlebo: it was almost Rec, would be drastic to drop it from a request for extension

<jcheney> http://www.w3.org/2005/Incubator/prov/XGR-prov-20101214/#Proposed_Charter_for_a_Provenance_Interchange_Working_Group

<tlebo> jcheney: cites from charter, which corresponds to our Collections decision.

<tlebo> ... Dictionary fits as "best practice"

<dgarijo> I can barely hear khalid.

<Luc> proposed: the WG will produce a prov-dictionary note as a form of "best practice"

<TomDN> +1

<khalidBelhajjame> +1

<jcheney> +1

<tlebo> tlebo: 1) stian has expressed (but with short term committment concerns) 2) the mateiral is "done" already, just needs rearranging.

<Curt> +1

<CraigTrim> +1

<dgarijo> +1

<dcorsar> +1

<tlebo> +1

<zednik_> +1

<Dong> +1

<reza_bfar> +1

<tlebo> *stian has expressed _interest_

<Luc> accepted: the WG will produce a prov-dictionary note as a form of "best practice"

<khalidBelhajjame> +q

<tlebo> khalidBelhajjame: timescales for Notes?

<tlebo> Luc: it's up to us to decide.

<Zakim> tlebo, you wanted to ask if there is any public review process for Notes (to make them better?)

<tlebo> luc: Primer has been doing through public review, so we have the spectrum of review.

<tlebo> luc: these are the deliverables that WG will be working on.

<tlebo> hook: mimetypes?

<tlebo> ... consistency on mimetype mechanisms to make it sync wiht prov-o and prov-xml

<tlebo> ... looking at atom, rss, rdf all in application

<tlebo> ... parameters define encoding scheme

<tlebo> rdf+xml

<tlebo> why isnt prov something like application/prov+rdf, application/prov+xml

<tlebo> ... why deviate?

<TomDN> seems fair to me

<TomDN> text is for prov notation, no?

<GK> Please don't go down the route of creating a new MIME type for PROV in RDF.

<tlebo> +1 @GK

<TomDN> what zednik said

<tlebo> does DC have a mimetype? changing a vocab doens't deserve a mimetype.

<GK> RDF is a perfectly good MIME type, and PROV in RDF may be combined with other information that is not PROV.

<Zakim> tlebo, you wanted to oppose any new mimetype for prov-o, we already have ~12 :-) "it's just a vocabulary"

<pgroth> graham are you on mute

<pgroth> http://www.w3.org/2001/tag/2002/0129-mime

<GK> I'm noty on the phone. I'm not really here

<tlebo> it doesn't seem like changing a vocabulary deserves a new mimetype.

<tlebo> it seems that only prov-n deserves a new mimetype. it's about syntax.

<GK> (Looking at link)

<GK> There's nothing in http://www.w3.org/2001/tag/2002/0129-mime that siuggests provenance in RDF should not be served as application/rdf+xml.

<pgroth> ACTION: paul to seek advice on the mimetype for documents from w3c [recorded in http://www.w3.org/2012/06/23-prov-minutes.html#action03]

<trackbot> Created ACTION-96 - Seek advice on the mimetype for documents from w3c [on Paul Groth - due 2012-06-30].

<tlebo> @GK, mimetypes shouldn't be used to delineate the vocabulary used within a serialization, should they?

<tlebo> subtopic: prov-constriants

<GK> (It's Saturday and I'm at home ... I just happen to have the IRC channel running so I can periodicaly peek at what's happening. But if I got on the phone, domestic unrest might ensue :) )

<pgroth> proposed: The current approach to the constraints document is a good pattern and should be taken forward. The constraints document is important for providing a foundation for the development of validation services.

<tlebo> pgroth: we should endorse what has been happening and its important.

<tlebo> jcheney: looking at charter: conceptual model, formal model (with optional semantics).

<GK> @tlebo broadly, I agree. I think I've seen an even more compelling argument, but I can't bring it to mind. Unlike XML, where the document *syntax* depends on the XML scheme used, RDF is a single uniform syntax. MIME types aren't really up to conveying semantics.

<GK> ^^ RDF/XML

<tlebo> ... why do we need a prov-constraints? It's not in the charter, and we're facing timeline.

<tlebo> ... we need to be clear on the rationale

<TomDN> +q

<Zakim> pgroth, you wanted to say that this is fundamental

<tlebo> pgroth: key for me: constraints distinguishes scruffy and proper.

<tlebo> ... scruffy shouldn't kill proper provenance.

<tlebo> ... how do we realize the difference?

<tlebo> ... prov-constraints is our definition of proper

<tlebo> jcheney: we've discovered half way though that we have something that wasn't in the charter.

<GK> (Constraints is part of DM, which *is* mentioned in the charter - we decided to split it out to make the document more approachable.)

<tlebo> ... can at least do scruffy prov.

<tlebo> ... prov-constraints could be a note.

<pgroth> +1 to GK

<tlebo> ... wants to have the discussion and be clear on why we're taking this on and it wasn't in the charter.

<tlebo> curt: the rational for the document is the feedback.

<tlebo> ... responding to community.

<tlebo> luc: prov-constraints split for editorial reasons.

<tlebo> ... but it's really a single document

<tlebo> TomDN: it's even easier: we're making a standard. Logical step that computes the compliance with it.

<jcheney> @GK Deliverable 1 says D1. PIL Conceptual Model (W3C Recommendation). This document consists of a natural language description and a graphical illustration of concepts involved in PIL. Such a document will help broaden the appeal and uptake of provenance beyond the community of technical experts.

<tlebo> ... it's good, compact, quick read, structured well. going from PROV to Normal and validating.

<jcheney> @GK Nothing about constraints or validity

<tlebo> ... stress that and structure.

<tlebo> Paulo: 1) what is relationship between prov-o, prov-constriants, prov-sem?

<tlebo> luc: prov-o is a OWL encoding of DM.

<tlebo> .. DM does not contain constraints.

<tlebo> Paulo: we are missing 20 years of effort.

<tlebo> ... we are mixing approaches that others have had to deal with.

<tlebo> ... planning community: robot planning.

<tlebo> ... situation calculus.

<tlebo> ... event calculus

<tlebo> ... fluid calculus

<reza_bfar> IMHO, may be this can be alleviated by stating that these are not all the possible constraints, but constraints that are required for minimal validity

<tlebo> ... my problem is implications of definitions .

<tlebo> luc: this needs to be raised in the formal ISSUE process.

<TomDN> @Paulo: note that the definitions in the editors draft of the constraints are not up to date

<Luc> action paulo to raise an issue regarding definitions of dm and their implication on constraint document

<trackbot> Created ACTION-97 - Raise an issue regarding definitions of dm and their implication on constraint document [on Paulo Pinheiro da Silva - due 2012-06-30].

<TomDN> (alternate, specialization, entity, are not the same as in the DM yet)

<GK> @jcheney but as I understand it, "constraints" were always part of the conceptual model.

<reza_bfar> FWIW, the constraints document, as is, which I reviewed last night, is very useful for implementers.

<tlebo> Paulo: to simplify the nature of the problems, constraints says "exists" all the time, "exists" means exists now. Tomorrow it may be invalid.

<reza_bfar> I'd say without the constraints document, the implementers may be either confused or just go in too many different directions and create interoperability issues.

<Luc> action paulo to raise issue about the notion of 'exist' in prov-constraints

<trackbot> Created ACTION-98 - Raise issue about the notion of 'exist' in prov-constraints [on Paulo Pinheiro da Silva - due 2012-06-30].

<jcheney> @GK OK, and that is how it was interpreted, but (devil's advocate) I'm just saying that reading the charter, we could drop or delay it if we want.

<tlebo> zednik_: discussing a validator, validing scruffy PROV. very important for the community.

<tlebo> ... the constraints doc is what leads to a validator.

<tlebo> ... where do they start?

<reza_bfar> +1 to zednik_

<pgroth> +1

<tlebo> ... critical for making a validator.

<Dong> +1 to zednik_

<GK> @jcheney ack.

<tlebo> luc: many have said that they wouldn' tknow what a validator would be without the constraints doc.

<TomDN> +1

<tlebo> paulo: wants a regression validator.

<tlebo> ... yest. we're talking about time.

<tlebo> ... many possible things that can be executed.

<tlebo> ... the technical term is regression validation.

<tlebo> jcheney: one thing to say it's important, another to know that we're in a position to do it.

<tlebo> ... coming up wiht some time that fleshes out the consistency/validation that's suggested in document is feasible but will take work.

<tlebo> ... obvioulsy will be asking for help from those that say they want it.

<tlebo> ... don't see a feasible plan to do it in the 6 months that we have.

<reza_bfar> +1 to jcheney

<tlebo> ... how to pin it down?

<reza_bfar> The issue, IMHO, is the scope of validation. Having consistency, well-formed, provable validation is a completely different thing than having practical minimal validation.

<tlebo> ... nothing in DM that says an Actiivty has a computational content. Need a notion of that, but we don't have it.

<tlebo> ... no way to standardize it.

<Luc> ?

<Curt> +1 reza

<reza_bfar> The same problem exists when people write OWL reasoners...

<tlebo> pgroth: the naive people that read the constraints doc, from implementation angle say "that's super useful for us".

<tlebo> ... "we can make a valdiator from that"

<tlebo> ... what more needs to be done?

<tlebo> ... does @jcheney see that there's more work?

<tlebo> jcheney: what is there is a sketch of how to do it.

<tlebo> ... there are a bunch of rules with the same form that we need to spell out.

<tlebo> ... how to expand optional attributes

<tlebo> ... avoiding the special cases.

<reza_bfar> +q

<tlebo> ... waiiing for clear idea on how that will work from rest of docs.

<tlebo> ... if an algorithm, here is how you run it.

<tlebo> ... check computability.

<tlebo> ... slash until it's computable

<tlebo> Paulo: I'm the trouble maker.

<tlebo> ... I'm very pragmatic.

<tlebo> ... the problem of validating a document.

<reza_bfar> This sounds like a QA effort on the constraints doc that's only achievable via trying to implement a minimal validator based on these constraints. How much time do we have for this? If we have some time, then I can do the QA effort as a part of actually writing a validator...

<tlebo> ... the theories have been discussed in W3C already.

<tlebo> ... OWL-S spent 2 years, and they failed.

<tlebo> ... we are dealing with the same things with semantic web services.

<tlebo> ... we have a very naive approach to validation.

<tlebo> ... the theory behind it is not simple.

<tlebo> ... do not want to get tangled in process.

<GK> Methinks it's not the group's job to implement a validator, but if someone outside the group were to do so that would support the spec's progress along the REC track

<tlebo> ... concerned about formal specification.

<tlebo> (I'm hearing contradictions)

<pgroth> @gk agree

<tlebo> reza_bfar: you need constraints on import/export.

<tlebo> ... I need to know its valid.

<tlebo> ... from a practical standpoint.

<pgroth> +q to say we vote

<tlebo> ... what jcheney needs is QA'ing the document.

<tlebo> ... willing to help jcheney QA it (as a user)

<TomDN> +q

<tlebo> pgroth: part of the implementations process.

<tlebo> reza_bfar: freezing of doc?

<tlebo> pgroth: with LC, WG is done

<tlebo> ... then WG must respond to all criticisms to fix them.

<tlebo> ... even after Cand Rec, proposed changes can affect it.

<tlebo> ... prov-constraints will LC after DM and PROV-O

<tlebo> reza_bfar: I'll take it offline to help jcheney

<tlebo> jcheney: paolo has been looking at it, too.

<tlebo> jcheney: I've need to hear that people think it' a good idea. If it's a good idea, I need more feedback.

<Zakim> pgroth, you wanted to say we vote

<tlebo> TomDN: I'll help. Not much left, it needs to wait to fix the frozen versions of DM to get consitent.

<pgroth> proposed: the current approach to the constraints document is a good pattern and should be taken forward. The constraints document is important for providing a foundation for the development of validation services.

<Curt> +1

<Dong> +1

<reza_bfar> +1

<jcheney> +1

<dcorsar> +1

<TomDN> +1

<tlebo> +1

<khalidBelhajjame> I+1

<dgarijo> +1

<pgroth> accepted: the current approach to the constraints document is a good pattern and should be taken forward. The constraints document is important for providing a foundation for the development of validation services.

<Luc> scribe: dong

Session 5: call for implementations & exit criteria

<Luc> http://www.w3.org/2011/prov/wiki/ProvCRExitCriteria

Luc: We'll need to have exit criteria for the WG to demonstrate the recommendations are implementable

<reza_bfar> Can you please clarify "have been demonstrated"?

Luc: Looked at COTS(?) for examples

<pgroth> +q

Luc: 2 independent implementations needed
... for each feature
... implementations can produce or consume a "feature"
... There'll be vocabularies extending PROV
... these are examples of PROV adoption

<reza_bfar> +q

Luc: An implementation report will be needed
... with matrixes of implemented features

<pgroth> here is an example of an implementation report from skos: http://www.w3.org/2006/07/SWD/SKOS/reference/20090315/implementation.html

<TomDN> +q

Luc: we'll need to track issues raised against CR and respond to all of them
... care must be taken when defining exit criteria

<khalidBelhajjame> +q

<tlebo> +1 to rename "use" to something like "support"

zednik: for each feature, "support" is better than "use"

pgroth: if there is only one implemetation uses a particular feature
... should it be in the rec

<pgroth> SPARQL implementation report: http://www.w3.org/2001/sw/DataAccess/tests/implementations

luc: 1. implementability of a features
... 2. interoperability of features

<pgroth> sorry this one: http://www.w3.org/2001/sw/DataAccess/impl-report-ql

pgroth: links to other impl. reports
... prefers the SKOS's report
... in SKOS, a lots of constructs were not supported by impl.

reza_bfar: Does impl need to be public?

pgroth: just need to list the impl.

<reza_bfar> -q

pgroth: with responses to questionaires

<tlebo> (yes, APIs and applications are "implementations")

TomDN: should we include the notion of interchangability between encodings

zednik: this has been addressed in Luc's point 2

khalidBelhajjame: concerned about point 2, the interchangability of a feature

<pgroth> suggested change = At least two implementations have been demonstrated to interchange provenance that is they consume provenance features generated by other implementations.

pgroth: propose update to no. 2

<Zakim> pgroth, you wanted to suggest a new phrase

<tlebo> we lost "for all features" in there!

khalidBelhajjame: it's hard to show 2 impls interchange provenance for every feature

<tlebo> I feel like we should be writing a \sigma equation :-)

zednik: should not add encoding conversions to the criteria

<reza_bfar> +q

Luc: A validator, if implemented, should be able to consume every feature

<tlebo> luc: validators, visualizers, and converters tend to cover them all

Luc: Visualisations and converters for PROV do as well
... PROV-XML will not in REC
... no obligation to demonstrate the exit criteria for it

<Luc> ack

reza_bfar: Can we defined a impl to support at least 4 major PROV concepts?
... how about 3 out of 4?

<khalidBelhajjame> +q

<Curt> a library just wants to attach attribution and nothing else

pgroth: there might be validation systems that look only at derivations, for ex.

<Zakim> pgroth, you wanted to respond

pgroth: so it's possible there are systems do not support all the core features

khalidBelhajjame: in some cases, activities are not needed for ex.

hook: in RDF impl. report, there is a good mixture of impl.

<TomDN> +1 hook

hook: can be sure there are real applications that use PROV, rather than just API implementions.

pgroth: agreed with hook
... but there a leading time before uptake of the rec
... we'll need to push for implementations

<hook> reference for RDFCore Working Group Implementation Report http://www.w3.org/2001/sw/RDFCore/20030331-advance.html

<pgroth> straw poll?

Luc: we don't need to agree on the exit criteria today
... but how do the WG feel about the current criteria?

<Luc> straw poll: should the WG adopt these CR exit criteria ?

<reza_bfar> +1

<khalidBelhajjame> +1

<Curt> +1

<dgarijo> +1

<CraigTrim> +1

<TomDN> +1 (good basis)

<dcorsar> +1

<pgroth> +q

<zednik> +1

<jcheney> +1

<tlebo> +.9

tlebo: the basis for exit criteria is good, but phrasing needs improvement

pgroth: should check the criteria with W3C

Luc: The list of features need to be there

<pgroth> ACTION: paul to run exit criteria pass the w3c team [recorded in http://www.w3.org/2012/06/23-prov-minutes.html#action04]

<trackbot> Created ACTION-99 - Run exit criteria pass the w3c team [on Paul Groth - due 2012-06-30].

Luc: What are the features the WG have in mind?

zednik: could you repeat what you said here

Paulo: Do we have any use case for PROV?

<Curt> we have frequently referred back to them

Luc: No
... it's not part of the charter

<zednik> zednik: we should include a description of how we intend to structure our implementation report when taking the criteria to the W3

tlebo: it's useful to have an example report against the criteria

<khalidBelhajjame> +q

khalidBelhajjame: is that every term a feature?

<pgroth> does someone have a us phone, so we can call the pizza guy?

<zednik> @pgroth, I do

khalidBelhajjame: suggest to list all the relations as features

<pgroth> list in dm terms all relations as features

<TomDN> So every relation that's described in PROV-N, essentially?

pgroth: suggests to follow the section headings in Prov-dm
... use them as features

jcheney: are we expected to have 2 implementations of optional features, like prov-constraint

pgroth: we could have generic criteria or specific ones for each document

jcheney: needs clarification on the "at risk" features

Luc: contextualisation should be a feature
... but if feedback is not good, we can drop it
... interchangeability does not apply to contraints
... so 2 implementations are sufficient

reza_bfar: is there forward influence on what PROV compliance means?

pgroth: the way we list features can be used to make statements about compliance

<Curt> compliance = all the "MUST"s in the spec

reza_bfar: is there a link between the features being discussed now with a definition of compliance later?

pgroth: will check this

<pgroth> ACTION: paul to ask about the notion of compliance to the w3c and its connection to the implementation report [recorded in http://www.w3.org/2012/06/23-prov-minutes.html#action05]

<trackbot> Created ACTION-100 - Ask about the notion of compliance to the w3c and its connection to the implementation report [on Paul Groth - due 2012-06-30].

Luc: who plans to do impl. of PROV?
... producing the impl. report is a significant effort
... which is important for PROV to be a REC
... who could help with this effort?

pgroth: we will implement PROV
... generate PROV assertions
... shell script tracking

TomDN: we will have applications producing provenance

<pgroth> +q

TomDN: there will be ones consuming provenance as well

<pgroth> +q to ask about pizza

<TomDN> (remove 's' :) one of each will be sufficient this summer)

CraigTrim: there are plans to use PROV-O, but cannot disclose yet

Luc: proof of concept prototypes will also be good

<tlebo> Four from me: 1) abstracting csv2rdf4lod's PML 2.0 to PROV 2) native PROV generation in DataFAQs data quality evaluation framework 3) PML 3.0 ontology 4) PROV vis to OmniGraffle

tlebo: see above
... thanks, tlebo :)

<jcheney> pepperoni

<reza_bfar> +1

<reza_bfar> +1 to Pepperoni

<tlebo> subtopic: fooding

Dong: Southampton will have 2-3 applications producing provenance using a python library that fully supports PROV-DM
... and a Provenance Web Service (i.e. provenance repository) is also in the pipeline

<Zakim> pgroth, you wanted to ask about pizza

Paulo: coordinate with RPI to develop PROV extension to PML3

<satya> We are also developing a query dashboard for proteomics data using PROV-O based ontology for molecular systems biology (SemPoD)

<Luc> thanks satya

<satya> SemPoD initial prototype: http://ncsserver.case.edu:3001/homes

hook: will likely to migrate the OPM-based earth sci sys. to PROV

<dgarijo> @satya: the link doesn't work for me :(

Curt: definitely generating PROV, likely visualisation + browsing

<TomDN> +q to ask later what the timeframe is? august? september? october? ...

<satya> Sorry, maybe a univ. firewall issue (I will post more permanent link soon)

dcorsar: applications generating + consuming PROV-O

khalidBelhajjame: exporting PROV, workflow and PROV (Taverna), validating PROV-N

<satya> Another application is in clinical medicine - integration of provenance-driven querying of patient information using PROV-O based ontology (PhysioMIMI: http://physiomimi.case.edu/physiomimi/index.php/Main_Page)

Luc: ProvToolkit

satya: What is the timeline for impl.?

<hook> migration of Earth Science extension of OPM-O to PROV-O. needs to be simple to be practical, simple Jena rules + classification, visualization, faceted navigation of provenance

Luc: we'll look at the timetable later today
... but hope the impl. will start from Sep/Oct

<Zakim> TomDN, you wanted to ask later what the timeframe is? august? september? october? ...

Luc: and results soon, hopefully

satya: what are the criteria for working impl.?

<TomDN> +q to say that if the implementation deadline is indeed in the fall, I might have bandwidth for a validator as well

Luc: Questionaires for implementor to fill

<reza_bfar> +q

dgarijo: exporting PROV, mydata?

<dgarijo> @Dong: export provenance traces from scientific workflows, and several projects from UPM have expressed interest in the model, but I can't say how we will be using it right now.

Paulo: could people contribute to a wiki telling about what they will be doing?

<Zakim> TomDN, you wanted to say that if the implementation deadline is indeed in the fall, I might have bandwidth for a validator as well

Luc: Agreed
... Can any one help with the impl. report?

zednik: I will help

<reza_bfar> What are the list of things to do?

<reza_bfar> I'm not clear... example actions/tasks?

pgroth: I'll participate, keep track of the tracker

<reza_bfar> I volunteer to help Stephan

Luc: in response to reza_bfar, we need to finalise the criteria, produce list of features, produce the questionaire, collection impl. data, write the impl. report
... we need to make sure that things get implemented in the group
... someone needs to read all the feedbacks and track them in the tracker

pgroth: some activities are not part of the impl. report though

<reza_bfar> I'm not familiar with the W3C tools, etc. (tracker?, etc.), but I can help with listing features, producing tables, etc...

Dong: will help with data collection and the impl. report

Luc: so Paul, Dong, reza_bfar, Stefan will help with the impl. report
... will put a call the the WG as well

Session 6: timetable for all work

pgroth: suggest to discuss on PROV-AQ, PROV-SEM first

Luc: What remains before last call?

Session 7: prov-aq / prov-sem

<reza_bfar> Is it permissible to discuss a technical topic that was not brought up (with Prov-QA) prior to F2F3? If not, no big deal.

<reza_bfar> Kind of a question actually...

pgroth: There a a number of outstanding issues on PROV-AQ

<reza_bfar> +q

pgroth: first, all the issues need to be resolved
... need to finalise the features as well
... the current issues can be resolved
... before the end of summer, PROV-AQ can go to last call

reza_bfar: can the protocol and service can be decoupled?

<pgroth> issue: can the protocol be decoupled from the service definition in prov-aq

<trackbot> Created ISSUE-433 - Can the protocol be decoupled from the service definition in prov-aq ; please complete additional details at http://www.w3.org/2011/prov/track/issues/433/edit .

<hook> +q zednik_

reza_bfar: prov-aq seems to refer to REST
... but there are users of SOAP

pgroth: we'll try to decouple completely the protocol and the content

Luc: could people have a look at the document and make suggestions?

reza_bfar: a recommendation for REST-SOAP mapping could also be useful

pgroth: we'll look into this issue

<Luc> q/

hook: should there be a formal service description for prov. service?

<zednik> WADL: http://www.w3.org/Submission/wadl/

hook: a machine-readable service desc. will be useful

Luc: concerned about the available resources

<pgroth> issue: look at wadl or some other description language for the service - is it possible? do we have time? paq

<trackbot> Created ISSUE-434 - Look at wadl or some other description language for the service - is it possible? do we have time? paq ; please complete additional details at http://www.w3.org/2011/prov/track/issues/434/edit .

hook: is AQ is part of impl. plan?
... there are existing tools that do AQ, generate WADL

pgroth: we don't have a good impl. of the protocol yet
... although it is simple, before going to LC, we need at least 1 implementation
... to make sure it works

Luc: suggests make PAQ as a feature, not as a rec criteria, but as a way of getting feedback from implementators

pgroth: OK
... if anyone has more issues with PAQ, pls raise them now
... Any other extra feature for PAQ?

<hook> s/existing tools that do AQ, generate WADL/existing REST frameworks to implement AQ with, that also auto-generates WADL for PROV-AQ/

<reza_bfar> Question: are you trying to "stream" provenance records between multiple points?

tlebo: suggests we need a mechanism to post back provenance to the source

<Luc> looks like PAQ is becoming PAQR (R for record ...)

tlebo: can downstream client file copies back

<reza_bfar> Don't want to interrupt the conversation, but can someone type in a use-case here? I'm confused

Luc: asks tlebo whether he wants an interface to store any provenance, or a mechanism to tell about the existence of provenance

tlebo: use-case desc.: data.gov's data (CSV) -> RPI (linked data) -> Oxford

<Curt> If a scientist d/ls data from a data center, then writes a paper about that data, he cites it from his side, but it would be nice to also tell the data center that he used their data

tlebo: but data.gov not aware of this

<TomDN> ack pizzaguy ?

tlebo: there is no forward linking that allows this to happen

<hook> @tlebo, sounds like you are describing a PROV repository and/or LOD? "prov-pedia"?

Curt: suggests providing a way to tell the data center that we're using your data
... it is currently done manually
... agreed this is a good idea

Luc: due to resource constraint, storing provenance by a prov service was not on the plan

reza_bfar: is "track-back" optional or not?

tlebo: it's optional
... is is not recording prov., it's a notification (a la ping back)

<reza_bfar> just an idea is you could have optional parameters in the POST that identify track-back. That's also ACID and Atomic.

<reza_bfar> In fact, I THINK for REST at least, that was one of the intents of POST. That the parameters that get sent to the server and what come back are packed in a single thing...

Luc: will we have a good PAQ doc before extension request

pgroth: sees no significant challenge
... we can spend something discussing the features being proposed

<reza_bfar> Paul\Tim - thanks for the explanation...

pgroth: to see whether it is feasible to implement those

<Luc> proposed: all features requests for PAQ to be submitted as issue before June 30th

<Luc> accepted: all features requests for PAQ to be submitted as issue before June 30th

we break for lunch

<pgroth> we are back

<dgarijo> It's getting late here in Spain, so I will leave now. Good bye!

<pgroth> thanks daniel

Semantics document

<reza_bfar> Paul: we want to talk about the status of the semantics document

<reza_bfar> jcheney: document itself was reconciled with the third working draft back in March or April and very little has been done since then.

<pgroth> @reza if you use tab you get the names of people

<jcheney> http://www.w3.org/2011/prov/wiki/FormalSemanticsWD5

<scribe> Scribe: reza_bfar

jcheney: If we talk about bundles talking about SPARQL data sets, then there may be number of issues that force refactoring
... would like to see what the group thinks needs to be published before making the final push to finishing

<jcheney> http://www.w3.org/2011/prov/wiki/FormalSemanticsWD5#Semantics_of_Bundles_and_Contextualization

luc: I haven't had the chance to look at Contextualization, but I see Semantics as important in the sense that in DM we've been intentionally loose with the definitions (English definitions as indicated in the charter)
... I don't know what the message will be with the document. It could be many other possible semantic interpretation for DM. Is the message that this is the one and only one or is it that this is one of the possible interpretations?

jcheney: From the beginning the goal was to provide a rational as opposed to something that is the only way to think about things
... one alternative is that if there is overlap with things that are in the constraints, we could move what's there in the semantics as an appendix to constraints.
... it would be good to have it somewhere close to the part of the recommendations that it is most relevant to.
... We want people who would implement to pay close attention to it.

luc: Should this be informative, not normative?

pgroth: you have to be very careful about that.
... scheduling forces: do we dump it, do we commit to it, or do we leave it for later?

jcheney: Contextualization will be straight-forward to integrate, but need help.

pgroth: I think it can wait till after the last call specially given that we have given overwhelming support for the constraints document and this is all a bit much for one person to do.

jcheney: There are not hundreds of developers emailing us and asking us about semantics
... Correction - contextualization will not be easy to integrate...

<Curt> we've defined precedence of specs with DM on top

luc: Within the context of the recommendation, these are the technical features that must be complied with to be comliant with the standard. We can't suddenly make it normative. This is decided by the charter.

paulo: can we move to make something that is eventually normative?

pgroth: We can make a number what are called Notes. These are referrencable documents for the community at large.
... You produce notes as a way to inform the commuinty about the WG thoughts as opposed to making things a standard.

paulo: I'm more favorable to semantics that lead to 1 interpretation than those that can lead to multiple interpretations

pgroth: At the last F2F, there was a huge discussion about the difficulties in rectifying proper provenance versus scruffy provenance
... No resolution. Plan to move forward is we still want to do this, but not the highest priority thing.

jcheney: if we really want to make this happen, we want additional resources than just James working on this or get a time extension.

tlebo: I can't read the semantics document because I have no background in it and I don't understand it. But knowing that it is there gives our efforts some credibility. I also know that I've seen this kind of response when discussing Prov-O.

Seems to appease folks when they know those semantics exist.

<TomDN> +q

tlebo: Seems to appease folks when they know those semantics exist. For me, it's important to have that box checked.

TomDN: I have the same issue as tlebo. Do we have people who can review this document?

jcheney: You don't want to stick something like this out there without proper review.
... For some sense, that is an argument for having it to be part of the process so that external folks with the right background can do the proper level of review.
... Are there people within or outside of the group that can do the type of review needed?
... I will send out the presentations shared at the second F2F and send it out to the team.

Paulo: I see some mismatches between the terms used in the semantics document and Prov-DM

jcheney: are there specific problems you see? Can you send me those?

pgroth: when we get to the last call on Prov-DM, James - would you be willing to update the document?

jcheney: I don't think anything will prop up in the semantics that will make us want to change DM.

pgroth: It seems more reasonable to investigate and discuss any potential mismatches off-line

Paulo: I still need to understand some definitions when I read the DM and Constraints document

jcheney: if there are gaps where the semantics document is required for understanding DM or Constraints document, then issues should be raised against DM and constraints documents instead of making semantics document required.

luc: Ultimately, the problem is that there are dependencies between the documents and some are out-of-sync

pgroth: the usual mechanism is that when you review a document that pops out at you, then you either email the mailing list or you raise an issue

<TomDN> +q

pgroth: Another way is that we have a mechanism to take feedback from the outside world. We synchronize things before releasing to the outside world.

TomDN: I don't think Paulo you need to worry about synchronization of documents. If you see a problem with a document, just raise an issue.

<Dong> +1

pgroth: James wants to know who can contribute to the semantics

luc: I will do my best to contribute.

<Paulo> I will also do my best to help with the semantics

jcheney: it would be much easier if we had people with formal backgrounds to review at least.

pgroth: Is anyone interested in semantics

jcheney: I guess the conclusion is that if it slides, it slides.
... I'll do what i can.

pgroth: I think that's a reasonable conclusion. The response is that it's a good idea and people like it, but we're running out of bandwidth

luc: for the record, Jan had some comments.

jan (sp?)

pgroth: next up - time-table and planning

<TomDN> (he was very positive)

timetable

pgroth: we should focus on last-call time-tables

<Luc> https://docs.google.com/spreadsheet/ccc?key=0An15kLxkaMA3dFVCWm9aREZFemNOYjlGQjdPRkdFZXc#gid=0

pgroth - The draft for internal review of Prov-DM was 2 weeks late.

pgroth: question is given that we have either addressed or resolved all technical results, how long will it take to produce another draft for review?

luc: 3 key changes to make - 1. Dictionaries out. 2. Get contextualization sorted out 3. Clean up Influence\traced-to. For DM, I should be able to finish before end of next week
... It would be good to have some people review the docs.
... For Prov-N, I'm working on the hypothesis that Paolo can't help here so it would take a few days after that or maybe Paolo can help and it could happen at the same time.

pgroth: July 5th? next call, but the one after that?

luc: 6/29 for Prov-DM and 7/4 for Prov-N

pgroth: creating an updated spreadsheet as a copy

tblebo: don't we agree that Contextualization is at risk?

pgroth: we agree on that, bu it would be better to rename and get it in.

luc: We could have contextualization as a topic for teleconference on Thursday

tlebo: Then, in addition to the ontology, I can do the narrative for bundle.

pgroth: can we vote on 7/12 to release as last call?

tlebo: I will have narrative done by 7/6

pgroth: Reviewers on DM have already reviewed DM and identified the defects so ideally, you don't have to do a full regression of the entire document
... given that, I would suggest that we move everything back a month
... we releae mid-July.

luc: we have to release by the end of July
... To simplify, let's assume the docs are out Aug 1st. That means that mid-sept we're at the end of review period.

pgroth: from Ivan - 2 months for the PR to REC transition is fine.

luc: my view is that may be we can get it out last week of July, but let's be safe and go for Aug 1st.
... This means that Oct 15th would be the publication of the CR.
... we need to check with Ivan to make sure this is reasonable.
... public review is 4 weeks after publication of CR so that would be Nov 15th.

luc: does this work with your time-table Curt?

<pgroth> reza_bfar: the amount of time seems fine

pgroth: after the last call announcement, we'll have a call for implementation, because we said we want it that. We don't necessarily have to have that if we can prove we have enough for exit criteria.
... According to Ivan - 2 months for the PR to REC transition is fine. Minimal voting period is 6 weeks.
... ... if the voting includes a major holiday, then you add 2 weeks.

luc: I think this is the best guess we can make now.
... The best place we could save time, is CR.

pgroth: I don't want implementation, development, etc. to go too far into 2013
... we would be safe to go 2 years since typical charter goes for 2 years and we shot for 18 months to begin with.

luc: so, let's make it end of March and that will be exactly 2 years

pgroth: Let's talk about constraints.

jcheney: this entire conversation has reinforced that I want to stay away from recommendation as possible. I think it's feasible to have something for people by August. what makes me nervous is that there are some large gaps with unlike the other documents
... I could write something that I'm happy with.
... I think there is a pretty substantial risk that it will take longer if there is not consensus or if there are technical issues.
... It will also help me once the other documents are finalized

luc: Are we going for 6 weeks or 4 weeks?

curt: In sync is better

luc: that would mean last call review for constraints is 15th of Sept.

pgroth: we need to decide what is the implementation of constraints?
... I would try to shorten the last call for review cycle.

jcheney: we better let people know this is coming.
... if we think this is important, but there is a descent chance that we won't have a great product, then it's better to make it a note and not a recommendation.
... that's a likely out-come anyways

luc: what we can do (to be on the safe side) is to delay things by 2 weeks.

pgroth: black-out period is week of 16th of July
... Dec 14th to Jan 2nd no publication

break

<pgroth> beginning again

Timetable for Notes

@pgroth: am I still the scribe?

<Luc> scribe: zednik

<pgroth> proposed: for all notes 1 Nov last call release Jan 15 final release

<TomDN> +1

<Dong> +1

<Curt> +1

luc: caveat on prov-sem note, is best effort

<satya> +1

<pgroth> accepted: for all notes 1 Nov last call release Jan 15 final release

<tlebo> +1

<reza_bfar> +1

luc: implementation TF members happy with questionnaire, CR exit criteria, implementation report plan settled by end of Sept.
... ^ above was a question

<pgroth> accepted: end of september for set-up of the implementation report (e.g. questionnaire, exit criteria, plan)

timetable next f2f

pgroth: W3C encourage another F2F 29 Oct. - 2 Nov in Leon, France

<TomDN> (probably only relevant to me, but those are exactly the dates of ACM Multimedia in Japan)

pgroth: co-locating our next F2F meeting with ISWC in Boston (ISWC Nov 11 - 15) is a possibility

<hook> http://iswc2012.semanticweb.org

<pgroth> proposed: seek to colocate next f2f with iswc 2012 in boston

<TomDN> +1

<Curt> +1

<satya> +1

<CraigTrim> +1

<jcheney> +1 (prefer to avoid 14th though)

<tlebo> +1

<Dong> +1

<reza_bfar> +1

<pgroth> accepted: seek to colocate next f2f with iswc 2012 in boston

<GK_> I'm getting a bit concerned at what I'm reading about expanding the scope of PROV-AQ (WADL, PAQR) about 12:15 your time. I think it's too late to consider adding significant new material.

messaging

<Curt> @gk -- there are issues to *consider* them

<GK_> Also, the discussion of track-back - we don't have a spec yet.

pgroth: opportunity when sending out last calls to engage community
... ... having the right messaging is important

<Curt> @gk track-back also -- the issue is to consider it

<GK> @curt I'm not aware of any issue to consider WADL - I thought I checked the issue list fairly recently

pgroth: ... blog posts have been very helpful to the community

<TomDN> @GK the issues were raised today

<GK> ... and I thought we'd decided to defer track-back.

pgroth: asking for new/fresh messaging ideas

<Curt> @gk wadl is issue 434

hook: domain specific communities can be used to evangelize use of prov (e.g. ESIP Fed, NASA ESDSWG)

<Curt> even have a "PROV tutorial" there

<pgroth> ACTION: curt to engage esdwg community [recorded in http://www.w3.org/2012/06/23-prov-minutes.html#action06]

<trackbot> Created ACTION-101 - Engage esdwg community [on Curt Tilmes - due 2012-06-30].

reza_bfar: is the messaging focused on provenance users or implementors?

pgroth: messaging primarily aimed right now for potential implementors
... also, we should be careful to not make the documents sounds too complicated

hook: should there be a coordinated effort to track domain-specific prov extensions?

<pgroth> ACTION: pgroth to make available a overview slide on prov on the main page [recorded in http://www.w3.org/2012/06/23-prov-minutes.html#action07]

<trackbot> Created ACTION-102 - Make available a overview slide on prov on the main page [on Paul Groth - due 2012-06-30].

pgroth: implementation report should track community vocabularies that extend prov

luc: we should maintain a messaging page to coordinate

<Dong> I guess we need manual ping back from the WG

<pgroth> ACTION: make a uses of prov wiki page [recorded in http://www.w3.org/2012/06/23-prov-minutes.html#action08]

<trackbot> Sorry, couldn't find user - make

<pgroth> ACTION: pgroth to make a uses of prov wiki page [recorded in http://www.w3.org/2012/06/23-prov-minutes.html#action09]

<trackbot> Created ACTION-103 - Make a uses of prov wiki page [on Paul Groth - due 2012-06-30].

<hook> @pgroth, how would overview slides be different from a subset of PROV tutorial slides at ISWC2012? should there be a consolidated list of known W3C PROV tutorial resources?

<pgroth> trackbot end telcon

<pgroth> rrsagent make logs public

<pgroth> trackbot, end telcon

- DRAFT -

Provenance Working Group Teleconference

23 Jun 2012

Attendees

Contents

PROV-N

PROV-CONSTRAINTS

Remaining Notes (prov-dc, prov-xml, prov-json, prov-bestpractice, prov-sem)

prov-xml

Session 5: call for implementations & exit criteria

Session 6: timetable for all work

Session 7: prov-aq / prov-sem

Semantics document

timetable

Timetable for Notes

timetable next f2f

messaging

Summary of Action Items

Scribe.perl diagnostic output