Provenance Incubator Group Teleconference -- 22 Jan 2010

<trackbot> Date: 22 January 2010

<scribe> Scribe: Luc Moreau

<scribe> ScribeNick: Luc

<scribe> Agenda: http://lists.w3.org/Archives/Public/public-xg-prov/2010Jan/0015.html

<YolandaG> thanks for doing this Luc!!

<scribe> Agenda: http://lists.w3.org/Archives/Public/public-xg-prov/2010Jan/0015.html

<scribe> chair: Yolanda Gil

<JoseMGP> who's on the phone?

user requirement 1 and technical requirement 1

UR1 -> UR6b, TR1 -> TR6b

http://www.w3.org/2005/Incubator/prov/wiki/Requirements#Versioning

are there commonalities with other use cases

how can we share TRs across use cases/dimensions

YolandaG refers to the editors...

iterations are required by editors

Do we need global IDs for requirements so we can refer to them.

PaulG had proposed URIs for these

Action Jim Myers to propose a naming scheme for TR and UR

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

what if we find a requirement that is not reflected in a use case?

Do we have to modify use cases?

YolandaG: in the list of requirements, there is no reference to versioning?

The requirements should be made more specific to versioning.

If appropriate, make reference to other areas, which have their own requirements.

Flag requirements that may not have been captured by use case, but appear to be relevant to provenance in the current context.

It is recognized that Use Cases will not illustrate all requirements.

With requirement, suggest how original use cases may need to be modified to expose the requirement.

In a first instance, let's not modify the narrative of use cases. We will do it in a second phase.

Final step will be to link requirements to state of the art.

So conclusion, requirements should be as specific to the dimension as possible.

<ssahoo2> I agree, yolanda

michaelp: requirement to construct the version trail and reconstruct all versions of a particular document

what access points are needed for that?

- Management:Publication (http://www.w3.org/2005/Incubator/prov/wiki/Requirements#Publication

Management: Publication (http://www.w3.org/2005/Incubator/prov/wiki/Requirements#Publication

luc didn't have time to look at this week, sorry!

Jun: Use case: how timely the data is

YolandaG: what does it mean to publish *minimum* provenance information
... we need the ability to publish provenance with different levels of details
... the term minimum seems to imply there exists such a minimum and it's unique.

Jun: multiple levels of details also related to scalability

<Deborah> +1 to different levels of details for provenance. that might correspond to "required" provenance for a particular application

Jim mentions this is also present in Accountability, where details relevant to contract are exposed, but not internal information.

Use: Understanding (http://www.w3.org/2005/Incubator/prov/wiki/Requirements#Understanding

<Deborah> suggestion on UR3 - not just SMEs - I have applications that need to be able to provide explanations to different categories of users - not just SMEs

<Deborah> +q

<Paolo> @deb: agree

<Deborah> and other types of users may have their own special requirements for presentations of the explanations

JoseMGP: provenance aware systems should be aware of the users they are interacting with

michaelp: what is regarded/perceived as provenance is domain specific

<Paolo> I was (as far as I remember)

<ssahoo2> I think Paolo is there

<Paolo> yes I can help

Trust: http://www.w3.org/2005/Incubator/prov/wiki/Requirements#Trust

<Deborah> I would add TR 1.4 Applicstions should enable users to be able to annotate trust assessments at varying levels of granularity for web data and allow users to access this annotation

Paolo: is there a need for aggregation function on provenance?

<Paolo> ack

<ssahoo2> +1 for including reasoning

<Deborah> +1 for including reasoning or for having some kind of trust calculus. I think this is quite important and i can give a use case if you want

Paolo: should the UC be detailed to the point that it mentions reasoning?
... it is not clear we can always aggregate provenance of sets of data

Jun: add UC to dimension: allow users to contribute to trust of data

Requirement for vocabulary for user contributed trust information

Deborah: requirement for an explicit annotation of trust (whether calculated or annotated)

Trust required at different levels of granularity: tuple, sets, documents

<JoseMGP> +1@Deborah's proposal

Deborah: what's your third requirement?

Paulo: trust for what? how is it used? computing trust is nice, but we need to know what the user would want to do with it.

<Deborah> third requirement is supporting reasoning. I have applications that require trust computation, propagation, and combination methods.

Thanks

<Deborah> I have applications that require extensibility for types of trust combination methods (not just standard probabilistic combination)

<cgi-irc> if we expand from trust to general attention (when do I want to be alerted),it is even more clear that th trust/attention metrics have to be extensible/customizable

<Deborah> +1 for the updating of trust point

ssahoo2: how is trust updated?

Paolo: trust could be presented to the user in the form of confidence

Paulo: but trust has also an element of subjectivity: user-specific rules

YolandaG: surprised to see 'causal graph' as a requirement. Is it requirement or assumption?

<Paolo> there was a new use case sent to the list ercently.

<Paolo> what do we do about it?

<Paolo> from someone external I think?

F2F meeting at www conference

To take place on 25-26, a day before the conference starts

<Deborah> i need to do a workshop on monday

trackbot, end telcon

- DRAFT -

Provenance Incubator Group Teleconference

22 Jan 2010

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output