See also: IRC log
<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[End of scribe.perl diagnostic output]