See also: IRC log
<trackbot> Date: 24 November 2011
pgroth: I can scribe
<pgroth> thanks stain!
<pgroth> Scribe: stain
will you do the magic things for bumping to the next agendum
<pgroth> i actually don't know how to do it
ok, I'll do it
<pgroth> I'll do the topics
that's what I meant :)
can we add an agenda item to ask when we should do the xmas break?
<dgarijo> well it looks like many people are on holiday today :)
short meeting today
<pgroth> PROPOSED to accept the minutes of the Nov. 17 telecon
<pgroth> ACCEPTED Minutes of Nov 17 telecon
ACTION-43 - Pgroth organising now - just waiting for actual confirmation before sending out email - hopefully by end of tomorrow
ACTION-44 on Graham - we can come back to this when we talk about PAQ
<GK> Oops, that fell of my Radar
Stian asked about what we do over Christmas break
Luc: Propose to have last call just before Christmas, Thurs 22 - not call 29th - resume on 5th of Jan
<GK> (I'll be on holiday on 22 Dec)
pgroth: sounds reasonable - but if too many o vacation 22nd we'll cancel
<dgarijo> I'll be on holidays, but I think I can make it
<scribe> ACTION: Pgroth to Send email about holiday break [recorded in http://www.w3.org/2011/11/24-prov-minutes.html#action01]
<trackbot> Created ACTION-45 - Send email about holiday break [on Paul Groth - due 2011-12-01].
(I can probably make it, I will be in EDT for once)
dgarijo: discussed Luc's issues
on Monday, wrapping up
... updated document - almost ready for release
I'll timestamp it
pgroth: issues with (?) section - did you plan to address that?
dgarijo: not aware about concerns over constraints. Planning to put it in an annex - but to put it in a different document
<satya> @Luc: Are we discussing the PROV-O?
Luc: dgarijo don't seem to be aware of comments on section 4 and 5, we said that they should not be part of the FPWD - instead they should be included in the (?) document
<khalidbelhajjame> Luc, that wasn't discussed in the last telecon
Luc: what is happening with section 4, 5
satya: had a discussion on
section 4. In email to Luc and Paul, we think that
extensibility of PROV-O is important to show - but we
understand they are really long
<dgarijo> when did discussion happened? I was not aware :(. Sorry.
satya: also reviewing content of
section 4 - but believe some content should be there in
... on section 5.3 - they have moved to appendix - should improve readability
... can revisit these after issues in PROV-DM are propagated to PROV-O
Luc: believe sec 4 is not by the charter - we should be domain independent
<khalidbelhajjame> Can then Section 4 be released as a note?
Luc: Section 4 explains how one
can extend ontology for specific needs - how can this be
normative? There are many different ways to extend it. Not by
the charter - not what applications can do to represent
... Focus on provenance exchange - not reached conclusion on how to represent provenance internally
... now section 5 -> appendix - most issues that are closed are removed or no longer relevant as PROV-DM has changed completely in tis point of view
... It does not show WG in a good light with raised issues flagged in document, when they have been closed
... what is the message of all those issues?
... For purpose of simplification of FPWD I would recommend to remove the whole section from the document
Satya: The issues raised in
section 5 removed from PROV-DM happened after I raised - or
... when we raise issues, and changes in PROV-DM - but we know propagating those changes in PROV-O will take time
... with section 4 - as GK mentioned in chat, 2 issues. Sec 4 is not normative, but we can make it even more explicitly clear. But we think it is important to show these examples to illustrate
<dgarijo> what is the problem of releasing section 4 in a separate document? I don't see the issue there.
satya: for instance if you did crime file example - how would you do it with existing concepts and wit extended concepts. And same for workflow. But we are not stating it is normative
<jcheney> I think we should say explicitly that it is non-normative, or put it into a non-normative document
GK: Agree with satya, don't think
it violates charter to discuss extension mechanism. In fact
charter invisions an extension mechanism.
... so it *is* supported by charter
<Zakim> GK, you wanted to say that I don't think explaining extension mechanisms violate the charter constraint of app independence
Could I propose to just make it clearer that it is non-normative
Luc: wit Workflow example, there were a number of.. domain-specific concepts
(but it's an example of a domain-specific approach?)
<dgarijo> @Luc: wf:seenAtPort, wf:sawValue, etc.
Luc: could not see the corresponding PROV-O concepts. But that was problematic for interoperability exchange needs. Even if we make it non-normative there would be problems.
stain: is issue that the example customizes PROV-O to the point of customizing away from PROV-O so that you can only see the PROV-O statements using OWL reasoning?
Luc: yes, that's what I meant
satya: using standard mechanism
should make it possible for semantic web applications - could
you point out exactly what are the issues so we can address
... in particular if it prevents interoperability
Luc: (?) belongs to scientific workflow namespace
pgroth: I think we need to
... q1 is if showing example of expansion shows interoperability..
... q2 is where this belongs
<GK> @paul - good intervention!
pgroth: in charter, extensibility
is often done through best practices
... now where sould this extensibility description/example go? that's main question.
... Right now this is a very long piece of detailed description on how to extend, and should go in a best practice note
... and confuses the issue of PROv-O just because it is large/long
... technical issues can then be discussed after FPWD
<Luc> +1 to Paul's comment
+1 to make a Best Practice document
Luc: not saying to bin examples, just to see them in a Best Practic document
<Luc> what about releasing a fpwd of teh best practice containing thes examples?
<GK> @satya - I still have sympathy for mentioning extension mechanism in prov-o, but maybe more briefly, and use best practice to provide the illustrative material?
stain: do we make a Best Practice document for the FPWD or just keep these on the shelf (remove from PROV-O) document for the first FPWD?
<dgarijo> +1 to Lucs comment: The examples are already done, right?
satya: did mention that we need to shorten the section - but should mention something - as PROV-O does not mention domain-specific - say you come for geospatial information - then we don't have that. If such a user comes to see what is the use for me
<GK> ... the extension mechanism used here is RDF specific, and prov-o is (in part) telling us how to use RDF to carry DM
satya: then section 4 should show
that PROV-O can be specialised
... Stian's wf example is a good example of modelling provenance information - but we can move it to a Best Practice document and leave a small example in section 4
... then it should not distract from the main point of PROV-O document
khalidbelhajjame: there are other examples on how to specify relationships specified in PROV-DM
<satya> @GK +1
khalidbelhajjame: don't like this medium solution with smaller examples
<dgarijo> +1 to Khalid's comment. Why not just add a reference to the best practice?
khalidbelhajjame: if this is not a good place, then they should all be removed and have an extension section only
GK: difficult now as we don't have such a Best Practice document - would be easier to talk about and refactor it once we have that.
<Zakim> GK, you wanted to tentatively suggest that we look to refactoring the text when we have a best practices document on the table. Meanwhile, just signal the current as
GK: suggestion is to recognize that it would happen - but for time being don't do it - just signal non-normative
pgroth: issue is that it is a lot
... as a first public workflow draft it makes a particular impression
... different people have different impressions of FPWDs
... good start for a Best Practice document - .. but..
GK: if worried about first impression, could it be sufficient with a big flag to say explicitly that this material will go to a best-practice document?
pgroth: would prefer just to move it out for now
khalidbelhajjame: People don't always read the whole document to know they can skip it. They look at TOC and just jump down
<Luc> what's the issue with creating today a first draft of the best practice document?
khalidbelhajjame: and so tey might not see it is non-normative
<GK> (So if readers don't go there, have they been given an adverse fiurst impression?)
Luc: OK, can do that :)
just copy and delete
<Luc> @stain, yes, plus a small intro
pgroth: two options a) Label Section 4 wit a big notice b) Just copy whole of section 4 and make it first draft of best practice document - and actually link to it
<pgroth> option a
option a) Keep 4 as it is - label with NON-NORMATIVE-and-will-go-to-best-practice
option B) Create new Best PRactice document - just section 4 moved there
<GK> (a) +0.5, (b) +0.5
<dgarijo> +1 to b.
+1 to b
<khalidbelhajjame> @GK :-)
<satya> +1 to b
<smiles> +1 to b
<dcorsar> +1 to b
<khalidbelhajjame> +1 to b
I can take the action
<jcheney> Happy with either.
<Luc> proposal: release both documents at the same time as fpwd
<scribe> ACTION: Stian to Move section 4 of PROV-O to new best-practice document [recorded in http://www.w3.org/2011/11/24-prov-minutes.html#action02]
<trackbot> Created ACTION-46 - Move section 4 of PROV-O to new best-practice document [on Stian Soiland-Reyes - due 2011-12-01].
satya: so think we should keep a paragraph about extension and linking to best practice document
pgroth: so keeping first paragraph (before 4.1) on http://dvcs.w3.org/hg/prov/raw-file/cc338a6ccf28/ontology/ProvenanceFormalModel.html#specializing-provenance-ontology-for-domain-specific-provenance-applications
satya: yes, and with link to examples in best practice
Luc: sounds reasonable
RESOLVED ..whatever we argued about :)
<pgroth> Resolved: keep roughly first paragraph of section 4, move rest of section 4 to best practice document
<GK> I heard: examples will be removed, but v brief descrioption of extension mechanism will remain
but that is the same
pgroth: Annex A Provenancespecific constraints to be removed - as it makes us look bad
<GK> @Stian yes --- I was typing that before Paul's summary got in.
satya: what Luc/Pgroth wants is that those issues sould not be seen. Some of them have not gone away! But should not be seen in the document?
I think it should be in ere if PROV-DM and PROV-O is in kind of conflict
<khalidbelhajjame> We need another button: Show Issues only to WG members :-)
<satya> @Khalid :)
pgroth: Keeping track of them..
PROV-DM changes that have not been reflected in PROV-O
... but we commented it out from the FPWD
satya: ok, we can comment it out [from the FPWD], but keep it in the document
pgroth: does that resolve it?
Luc: Believe so
(issues are public anyway, remember!)
pgroth: then we should be ready to do an FPWD, right?
Luc: propose to vote on releasing both PROV-O and Primer FPWD [ at the same time ]
<dgarijo> +1 to that
the Best PRactice document
(which does not yet exist! ;) )
<khalidbelhajjame> Is there anything else that should be added to Best Practice document other than Section 4 of prov-o document?
GK hang, on, I'll be quick in mercurial!
it will only be section 4 for now
pgroth: sould vote on FPWD on PROV-O with intention to vote on Best Practice FPWD next week
<jcheney> I agree with not voting on FPWD for best practices now.
can't we link to Best Practice doc in Mercurial ?
Luc: (?) that best practice doc will contain the examples in 4.1 and 4.2 of PROV-O
<pgroth> Proposed: release PROV-O as first public working draft with above mentioned changes
+1 (witout the ] thing)
(we're all waiting for Luc!)
<pgroth> Accepted: release PROV-O as first public working draft with above mentioned changes
Luc: supportive - but don't vote as a chair
pgroth: but I've been voting as a chair !!
<satya> @Paul :)
pgroth: editors draft of best practice document which should be good to come along
<Luc> congrats to the prov-o team!
GK: moved issues to boxes -
cleaned up - not much else
... happy to do remaining things - but if I had problems.. could pgroth pick up if GK drops the ball?
pgroth: happy to do the test
GK: might not be available in the near future
<Zakim> GK, you wanted to say Can we really vote on a documen t that doesn't exist yet?
pgroth: getting close to FPWD
<pgroth> lots of echo
Luc: we voted on a number of
proposals, those changes are being implemented
... some questions on derivations
... being edited as we speak
... some proposal from Yolanda on agents.. and edits are in progress as well
... still very much editors draft, bouncing Luc <> Paolo
... you can have a look at it, but not yet ready for internal review
... don't file issues on the actual current document yet
... hoping to have feedback soon
... and mke it availabile to WG for internal evaluation
... hope is to have second working draft released as soon as possible
(You mean before christmas?)
<Luc> @stain, yes, hopefully, 2 weeks time
Paolo: Question on please do not
.. PROV-O alignment
... most changes would be simplifying
... and not throw everyting up in the air again
@Luc btw - when did we resolve vote on Process Execution -> Account ? I remember voting -1 ..
Paolo: flurry of activity last weeks.. nice things with chain of responsibility
<dgarijo> @Stian: you mean Activity, right?
<Luc> @stain, what is this? PE -> account?
so when do we get the internal review?
if second WD is in 2 weeks
<Luc> @stain, hopefully, next week
pgroth: possilibity about note on
doing PROV-JSON with some support. How would we proceed?
... Southampton have actually worked on this - a JSON serialisation of PROV-DM
... then discussion on how WG would like to proceed
... given time.. let us hear about it
DongHuynh: observing WG
... first time in meeting
... in Southampton capture provenance in many applications
... to have a common format
... ow to represent in JSON? Here's our document showing thihs.
... when implementing this we wanted to ensure interoperability. Not just our 3 applications, but also future applications
... so stay close to PROV-DM
... as it will likely widely adopted when it is a W3C recommendation.
... so also lightweight - like using JSON datatypes where possible - but witout loosing expressitivity like custom data types
... don't want to bother with complex configurations when not needed.
... introduced some [shortcuts?]
<Luc> design rationale http://users.ecs.soton.ac.uk/tdh/json/#introduction
DongHuynh: says that that
Document you just saw was derived from a document int he
... with a few examples they are all from PROV-DM - the PROV-DM namespace is the default
DongHuynh: second example
... introduces a prefix for applicatoin specific information
(line 35 is not valid JSON btw)
DongHuynh: in first level,
prefix/entity/activity, etc.. PROV-DM level
... at next level is the entity
... at third level attribute value pairs
<Luc> @stain, yes, looks like a typo
GK: (skipping the queue!)
... Providing possibility to link fairly well with RDF, but difficult to tell at first ga
DongHuynh: will look at JSON LD for hints/clues
khalidbelhajjame: in examples..
... is there a mechanism for (?) actually is.. (?)
... JSON schema?
... to say how it can be serialised
DongHuynh: could not hear very well..
khalidbelhajjame: you specify how
to specify PROV-DM assertions using JSON
... if you have a JSON document.. is there a way to know that it is valid PROV-DM [PROV-JSON] ?
... like using existing JSON Schema approaching
... to say ow instances of PROV-DM looks like in JSON
DongHuynh: one rational is to
... so we want a two-way mapping from PROV-DM to PROV-JSON
... no tool for checking conformity
... working on this
DongHuynh: have workin progress
wich can convert a PROV-DM record in PROV-ASN to PROV-JSON
... next step is the reverse to check semantics
... aware of JSON Schema
... could be good to describe what is now in the HTML
... not convinced about popularity of JSON Schema
... is it really used
... more useful to have a document that describe mapping by example
<khalidbelhajjame> Thanks Dong
DongHuynh: main readers would be developers, and examples should help to kickstart process
pgroth: we are running out of
... very interesting work
... would want to discuss this more on the mailing list on how we want to proceed
Luc: Is it possible to have a
sense here now?
... who would be interested in working on this spec?
<jcheney> +0.5 (what exactly is the specification going to specify?)
<khalidbelhajjame> +1 (I am far from being an expert but would like to participate)
Luc: not *this* specification - but A PROV-JSON specification from the WG
<GK> It depends on timing, and principles. I'd want us to see DM very stable first.
@GK perhaps this is a spring project
<GK> Yes, maybe in spring.
<jcheney> @GK - I also think this is lower priority and can happen later - otherwise we will have too many moving parts to sync
I am fully loaded with PROV involvement at the moment
<jcheney> same with PROV-XML
<GK> @jcheney +1
pgroth: ok, as chairs we will look at scheduling this
<dgarijo> happy thanksgiving
<pgroth> trackbot, end telcon
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: stain Inferring ScribeNick: stain Default Present: pgroth, Luc, stain, dgarijo, jcheney, khalidbelhajjame, GK, [IPcaller], Bjorn_Bringert, Satish_Sampath, Paolo Present: pgroth Luc stain dgarijo jcheney khalidbelhajjame GK [IPcaller] Bjorn_Bringert Satish_Sampath Paolo Regrets: Christian Runnegar Agenda: http://www.w3.org/2011/prov/wiki/Meetings:Telecon2011.11.24 Found Date: 24 Nov 2011 Guessing minutes URL: http://www.w3.org/2011/11/24-prov-minutes.html People with action items: pgroth stian WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]