<trackbot> Date: 29 January 2010

<Yolanda> satya: i started the trackbot already, can you scribe

yes yolanda

yolanda: paul groth discusses the requirements document

paul: discuss three of the requirements: justification, dissemination, and accountability

requirements document: http://www.w3.org/2005/Incubator/prov/wiki/Requirements

paul: user requirement is distinct from technical requirement
... for process - provenance graph is a technical requirement

yolanda: process should be reproducible from provenance

jose: agent is not a technical requirement

<michaelp> "Agent" in the process requirement does not mean "user agent"

jim: technical requirement repeats user requirement for process requirement

luc: UR3 for process requirement needs to be refined

<Yolanda> I think "agent" is more accurate than "people", since it includes software entities that do a process

yolanda: TR 2.1 is too broad?

<Deborah> Deborah McGuinness and Jim McCusker joined in both chat and phone (phone starting with 518276)

luc: TR2.1 is a user requirement

jose: TR2.1 reflects the reasoning with process
... not from exemplar use case

<Luc> UR2: this is not a user requirement on provenance but on processes

<Yolanda> I think UR2 falls out of the scope of our use cases and we should not include it

<Deborah> +1 on jim's points. i need this on much of my work

jim: description of process as provenance

<Deborah> is there a url we should be reviewing now? (sorry joined late)

<Luc> I don't think we can enumerate all the possible kinds of reasoning/inferences we can make with provenance

<pgroth> http://www.w3.org/2005/Incubator/prov/wiki/Requirements

<JoseManuel> http://www.w3.org/2005/Incubator/prov/wiki/Requirements

yolanda: TR2.1 is a specific solution and may not be added to the process requirement

jim: UR in accountability may be modified to include derivation instead of provenance
... UR 2 and UR 3 in accountability requirement

paul: TR.2.1 to be removed from process requirement

<ivan> no...

<ivan> :-)

<JimM> maybe some requirements are for 'larger systems' including a provenance component

yolanda: technical requirement do not have to include existing solution

<JimM> versus provenance requirements

yolanda: provenance should be "factorizable"

luc: TR should be requirement with respect to provenance

<JoseManuel> The QR thing in TR2.1 is just an example not a requirement itself

<lkagal> +1 for Luc's point of reqs identifying what elements need to be available in provenance

<jun> +1 to Paul's summary

pual: moving to justification requirement

<jcheney> me neither

<jcheney> +q

<Deborah> why on ur1 does it need to be just sociological studies? maybe just results need to justified by linking to source and intermediate data

james: TR should be independent of particluar domain

paul: members can help define TR for UR in justification requirement
... moving to dissemination requirement

<Yolanda> i like the "SEE ALSO" note at the end of Justification. Seems very useful to cross link requirements across dimensions

paul: good set of UR and TR for dissemination requirement

<Luc> I don't want to interrupt the flow of the presentation. But I have a question. Sometimes, it's not obvious why a TR addresses a UR. Or alternatively, there could be alternative design to address the requirement. So the question is: how do we justify TRs?

paul: discussing accountability requirement

<lkagal> +q

jim: accountability requirement for attributing, closure on provenance information, sign statements on provenance
... semantics of entities enhanced by provenance

paul: create a UR for different perspective of a process

<Luc> what is the notion of accounts here? OPM's?

<dlm> general question on how specific the urs are to be. for example, should ur1 have the general statement of something like "allow users to verify that work meets previous agreements" and then add something like for example, verify that work is compliant with a previously signed contract

paul: meta provenance from contract use case

yolanda: talk about license in this requirement

<lkagal> maybe we could replace license with usage/privacy policy ?

jim: UR5 refers to license

<dlm> +1 to this point in general of how general the URs are to be. possibly the template is write the general statement and then write a for example with respect to use case xxx, and then do the more specific statement

paul: need to have general statements and then specific statement with respect to use case

<dlm> ps. dlm is deborah (had irc problems)

<JimM> Acct-UR5 tries to give the general case of which license is one example

paul: requirements to be completed by thursday next week

<Luc> I wonder whether Acct-UR3 is realistic as such? Can this be decided?

yolanda: jim suggested for unique identifier for requirements
... connect with other W3C groups
... W3C RDB2RDF group contacted to work with this group

<pgroth> http://www.w3.org/2001/sw/rdb2rdf/wiki/LinkedDataAspects

<JimM> yes

yolanda: provenance in RDB to RDF conversion process

<dlm> I am also happy to help as a secondary

<ivan> s/ediburgh/edinburgh/

james: volunteer to liason with RDB2RDF working group

<dlm> I am co-organizing Linked Data meets AI along with Harry - sss meeting at stanford in march

<pgroth> please no :-)

<ivan> ws announcement

<JimM> re: Acct-UR3: I'll rephrase and we can then discuss - it doesn't mean to me now what I meant when I wrote it :-)

ivan: new version of RDF, workshop in june
... issues including named graphs for provenance tracking in RDF
... additional features in new version of RDF to address some of the TRs in the requirement document

<pgroth> i think we could do something

<pgroth> as a summary of use cases?

<dlm> +q

ivan: end of march for submission of position paper to the workshop on new version of RDF

<pgroth> could be possible...

ivan: use some of the TR from the requirement document as input to the workshop

<JoseManuel> +1 on the synthesis of the TRs and selection

<JimM> a position paper could cite a req. or two that suggest a need for RDF work with a promise to talk about more...

deborah: requirements for provenance in linked data being presented in AAAI spring symposium

ivan: feedback from prov-xg on the new SPARQL document
... couple of members create a draft for discussion in the group meeting

<lkagal> bye

<jun> bye

<jun> exit

<afreitas> exit

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

FAILED: s/ediburgh/edinburgh/
No ScribeNick specified.  Guessing ScribeNick: ssahoo2
Inferring Scribes: ssahoo2

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: Deborah JimM JoseManuel Oleksiy UR2 afreitas dlm ivan james jcheney jim joined jose jun lkagal luc mccuskej michaelp paul pgroth prov-xg pual satya trackbot yolanda
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Agenda: http://lists.w3.org/Archives/Public/public-xg-prov/2010Jan/0018.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 29 Jan 2010
Guessing minutes URL: http://www.w3.org/2010/01/29-prov-xg-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report