<trackbot> Date: 26 November 2010

<scribe> Scribe: Luc Moreau

<scribe> ScribeNick: Luc

<YolandaGil> hi Irini, it's great to "see" you!

Yolanda: rule of engagement. No reference to specific languages.
... discussion should be at conceptual level, rather than specific level
... examples to be discussed should be from our flagship scenarios

<YolandaGil> http://www.w3.org/2005/Incubator/prov/wiki/Recommendations_for_scenarios

Yolanda: OK, we have agreement.
... we should keep in mind those requirements/recommendations

A formal thank you to Yolanda for her amazing chairing of the incubator.

<pgroth> clap!

<jun> +1

<DGarijo> yeah, thanks!

<Jose_> +1!

<SamCoppens> +1

<Irini_> +1

Paul: I tried to group the set of suggested concepts

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

Paul: proposal, go through the list of concepts, identify issues with grouping, identify missing concepts
... then go through timeline. Feedback from Yvan to be discussed

<DGarijo> yes

Paul: concept 1
... concept 2: Process

Paulo: qualification: do you talk about an execution of experience, or a process that can be repeated agian, and again?

what about unix process?

<jun> but as long as the definition is clear, I dont' see that as a problem

it's an execution

<DGarijo> i agree with jun

<Irini_> what about a query?

Paul: it's an execution we talk about, an instance of execution

<ssahoo2> In DL - the process is a concept and the execution of a process is a instance of the process

<ssahoo2> TBox vs. ABox

<DGarijo> i agree

Paul: by process, we mean execution of a program or execution of workflow

<Jose_> I agree wiyh Paul's definition

Paul: the next concept is recipe, which is a program to be executed

<jun> I agree with Paul, as long as we mean Process refers to an execution, I am fine with it

<ssahoo2> I agree

Paul: i agree there is a difference between a program and an execution. Concept 2 is an execution.

<SamCoppens> +1

Paul: are we fine with a notion of execution?
... concept 3: recipe, is a program, a workflow, a set of rules. Something that can be executed.

<jun> why is that not just a Resource?

<JimM> +q

Yolanda: i would be concenred to add this to a charter of a WG
... it's difficult to reach consensus on this
... it's very important, but I would suggest the group to drop this one

Paul: what is needed is a link to a recipe, not a recipe itself.

Jim: agreement with Paul, we don't want to standardize on recipes.

Yolanda: OK

reminder: rules of engagement!!! No ref to vocabularies!

<Jose_> +1 to jun's point

I could understand you Paulo, can you write what you said?

<ssahoo2> so, I think both the notions of "recipe" and "execution of a recipe" are needed

Paul: we talk about an execution of a process, and it would be useful to refer to what is being executed, i.e. recipe
... do we agreement we need a concept "Recipe Link", i.e. a pointer to a recipe

<JimM> +1

<DGarijo> +1

<jun> Paul: do we need a propety call recipelink, we don't standardize the concept recipe

+1 to Paul

<ssahoo2> no, it is necessary to explicitly model a process, since a process itself can have properties

<SamCoppens> +1 for the link

<jun> +1

<jun> re @ssahoo2, I think that should be done by a specific community, to build their own extensions for that purpose

Paul: OK, we have support for Recipe Link
... standardizing recipes would be totally out of scope

Paul, OK, let's move on to next concept

Paul: concept 4: agent. In most case, it is a person.

<ssahoo2> I agree

<DGarijo> +1

<JimM> yes - agent in the broad sense (corporations as legal persons, etc.)

PLuc: should we leverage existing notions of agents (e.g. foaf)?

Paul: do we recognize the need for agents, if so we should recognize it here, and leave to the WG to decide how to standardize it (inc. reusing a definition out there)

Yolanda: notion of responsibility

Paul: let's leave it to the end
... is agent = source?

<JimM> source might be the concept of responsible agent...

<SamCoppens> I see source as a specialization of agent

<ssahoo2> +1 @Sam

Paul: is source a specialization of agent?

<JimM> though sources such as documents don't seem to be agents

i thought a source could be a database?

Paul: do we need a concept to mark that something acts as a source?

<ssahoo2> No, source is just a specialization of agent

Paul: some say that a document can be source

<ssahoo2> In that case, source will be a specialization of "Resource"

Paul: suggestion to remove Source altogether

<ssahoo2> and the information derived from the document

<YolandaGil> source is now gone, just refresh the page. i added a note that the agent can be a creator or a contributor

Paulo: need a concept that is actionable, capable of making assertions
... is provenance container something that knows something?

<JimM> +q

Paulo: we need a knowledge container

Jim: we need to be able to say something comes from a person or from a database

<Jose_> +1 to Jim's point

Jim: do we decide now, or we leave it to the WG

Paulo: source is a connection between a resource and an agent
... do you mean an agent says? or an agent is responsible for?

<JimM> -q

<ssahoo2> Yolanda: Why are we removing the other examples from the grouping page for the agreed on terms?

<SamCoppens> +1

<DGarijo> +1

what was the resolution? I dropped off the call.

<jun> we agreed to keep the agent and removed source

<YolandaGil> resolution was to use agent and drop source since it meant contributor etc

Paul: Role, we need this notion, even if in a given realisation (e.g. DL) we drop it, maybe because we encode it differently

<YolandaGil> this notion of query seems strange to me

<JimM> user query is a type of recipe?

<JimM> and then out of scope since we don't type recipes

Paul: Query: i dont' see why we need this for a general provenance model

Paulo: you can get an answer, but not for the question that was asked

<JimM> or is it just a type of input (role = query)?

<JimM> +q

<YolandaGil> +1 go away

Jim: user query can be seen as role, each community could define the kind of roles they consider important

<SamCoppens> +1

<Paulo> -1

0

<DGarijo> i'm not sure, it query could be seen as a justification... 0

we are not suggesting to standardize on what queries are here? right?

<jun> I don't understand what this concept does, so I can't vote

<Jose_> an example is necessary to illustrate his concept

isn't a query a kind of artifact?

<ssahoo2> yes @Luc

<DGarijo> could we make an exception and let Paulo put an example that is not from the scenarios?

<ssahoo2> I think we should explicitly put it under Resource

<ssahoo2> instead of completely reoving it

<ssahoo2> removing

Paul: to move on, let's leave it there for now

<Jose_> it will need to be revised...

Paul: can we modify the page, and indicate it could be subclass of resource or role
... next concept: Location. There are many ontologies for location.

<ssahoo2> The notion here refers to a property

<jcheney> +1 for not reinventing wheel...

Jim: location is not universal, and is specific to domains

<YolandaGil> +1 for leaving it out of the core

<Jose_> location does not look core to me either

Satya: it's just a link to location, rather than location itself, we need

but isn't this already defined in location ontologies?

<DGarijo> i agree with satya. It's not reinventing the wheel, just pointing to other ontologies...

<Jose_> if it's pointing out, then it's not core

<YolandaGil> is there an example of location use in the 3 flagship scenario?

Satya: there exists a notion of locationOf

where disease was declared maybe?

<ssahoo2> yes

<DGarijo> yolanda, yes: if the sensor is a buoy, in the disease outbreak scenario, then it's important to know where was it produced

<JimM> -q

Paulo: Location is a property of a concept

<Jose_> sorry, I have to run. will catch up with the minutes

<YolandaGil> why would the location where the disease was declared deserve a special treatment more than other entities?

I think this discussion is very OWL specific concept/property!!

<jun> given that our disease scenario shows a need for location expression, I am prone to have a notion of location in the core

i agree with you Yolanda, we could talk about color, too!

<YolandaGil> why location and not "consumable resource"?

Paul: we need to move on, turn location into a link, which must point to another ontology

<DGarijo> +1

Paul: like we did for recipe lonk

<ssahoo2> yes, it is a link

<ssahoo2> +1 for link

<jun> +1

<SamCoppens> +1

<DGarijo> +1 for derivation

Paul: next: derivation

<YolandaGil> +1

<jun> +1

<ssahoo2> +1

+1

<SamCoppens> +1

Paulo: it is not minimal, it can be derived from processes

<DGarijo> agnostic aproach?

<jun> I don't agree. It's a very important shortcut, when people don't want to express the image copying process in details

<JimM> +1 as a shortcut

+1, this is a dataflow view ... we may not know the process

<YolandaGil> I think there are a lot of +1

Paul: there is majority of people for keeping it

Paul Use and Generation

+1 to both of them

<ssahoo2> 9, 10, 13

Satya: participation could be combined with them too

i thought participation was like agent control

<jun> I think they are quite different, as seen from the examples

<jun> I think the sub-classing should be done by the WG

I don't think we should group Use and Generation

<DGarijo> nope

Paul: OK, agreement
... ordering of process

<JimM> +1 - links from processes to inputs(used), outputs(generated), and things that participate

<YolandaGil> it seems that derivation, generation, use, and participation are all shortcuts, they will be particularly useful when the provenance is incomplete

Paul: useful for a control view of the world
... OK agreement

<YolandaGil> same for ordering

<DGarijo> +1 For control

Paul: notion of Control (11)

<YolandaGil> does control releate to the notion of responsibility

Paul: no objection

<JimM> and subtype of participation...

<DGarijo> to be the agent responsible of an object couldn't be a role?

Paul: notion of versioning
... we would want some "lightweight" solution

<JimM> +1 for a link

<DGarijo> +1 for versioning, but could be grouped with derivation

Paul: otherwise, standardizing a versioning system could be scary

<ssahoo2> I think notion of versioning is important

<ssahoo2> +1

<jcheney> maybe it can be made optional/experimental?

<Irini_> +1 for jcheney

<DGarijo> +1 for link

Paul: we should not it should be a link, so rather lightweight/optional

+q

Paulo: i cant' see the difference between participation and control

<ssahoo2> :) good example

<JimM> participant maps to dc:contributor versus dc:creator for control - broader than control/own

Satya: it's not a control link, but indicates the presence

<ssahoo2> yes, presence

Paulo: does it have influence?

<JimM> participation is a link between a mutable resource and a process that is part of its lifecycle

<jcheney> I keep getting dropped

why is this core?

<JimM> a web server participates in providing a response but does not control it...

scribe: but if the web server wasn't there there wouldn't be any response

<jcheney> Wanted to ask whether there is redundancy between provenance containers, accounts, and more general collections.

<jcheney> E.g. an account could be viewed as a subcollection of provenance statements.

Paul: participating has influence on something

<ssahoo2> I agree @Paul

Paul: Control is subclass of participation
... we should not the relationship between participation and control, and the fact they influence processes
... container

<YolandaGil> I noted on the wiki that Control is a subclass of participation, and put Control after Participation in the list

<DGarijo> +q

Satya: is provenance container a resource?, same for collection

Paulo: why not use named graph?
... i don't see the provenance container as a kind of source

who said resource is not mutable? on the web, they definitely are!

<ssahoo2> Resource (from provenir:data perspective) is definitely mutable, although opm:Artifact definition is for immutable

<JimM> w.r.t., the processes being described

<ssahoo2> I think we should discuss it in WG

<jun> +1 to ssahoo2

<JimM> companies can go through mergers to create new companies

may i suggest we expand provenance container to containing provenance assertions

<JimM> +1 on the larger topic - I think account is needed and there is a need to be able to treat them as resources with their own provenance

<ssahoo2> yes, @Paul provenir:data is for both mutable and immutable

for Resource, can we add a line that we need to distinguish the Resource and its States

<JimM> +q

<jun> it's a complex problem that cannot be solved in one telcom

<Irini_> +1 for sun

<DGarijo> -q

<Irini_> s/jumjun

<JimM> mutability is a role relative to a set of processes and one resource may be immutable relative to some and mutable relative to others

Paul: add the distinction of mutable and immutable resources under concept 1

<jun> yes. we need both. and IMO the WG should decide how to separate them

<JimM> -q

Paul: we agree we want a provenance container (which could end up being a named graph)

<DGarijo> +q

Oaul: view/account

<ssahoo2> exactly @Daniel

Daniel: can they be seen as provenance container?

<YolandaGil> Satya: what was your example of "Participation"

<ssahoo2> Other than what is listed on the wiki?

<YolandaGil> yes, i'd like a good example that refers to one of the 3 flagship scenarios

Luc: accounts are conceptually different from provenance containers

I dropped off again

<ssahoo2> I will have to re-read the 3 flagship scenarios

<ssahoo2> I can send you by mail later?

<YolandaGil> yes!

I can't dial in anymore

<YolandaGil> I think it is good to keep both

<YolandaGil> +1 for time

<ssahoo2> Paul: Both accounts and containers are retained

<DGarijo> +1 for time

<SamCoppens> +1

<jun> +1

<JimM> +1

+1 for time

<ssahoo2> Paul: Agreement on keeping Time

<ssahoo2> Paul: Next concept Collection

it seems I can't call in anymore at this time :-(

<jcheney> my take: save collections for 2.0 - probably not enough consensus

<YolandaGil> Sorry Luc :-( we'll transcribe

As I can't talk, I would like to say that collections would be a very big chunk to standardize on

We can't do it in two years.

<YolandaGil> Satya points out we should have it as a link, not as a concept

<ssahoo2> Paul: Collections is a difficult to model

Defintely useful, but this is not mature yet for standardization

<YolandaGil> Paul mentions this would be very hard to do and should be left for the future

<jun> +1 to Satya

<YolandaGil> Satya says it is a containment relationship

<JimM> perhaps all that's needed is the idea of extraction (source) - one resource is something came from a larger resource

<JimM> you created a doc, I edited a chapter, the chapter came from your doc

That's not the issue, who do collections evolve when being transformed. It's complex to describe.

<JimM> trying to keep that out of scope

<ssahoo2> Yolanda: Can consider modeling collection subclass of Resource

<JimM> +q

<jun> Yolanda: we should model Collection as a specific type of Resource. Would that be sufficient?

<ssahoo2> Jim: Important to represent information that is source-oriented

<ssahoo2> Paul: We will not model concept of collection in WG and is a specific type of resource

<DGarijo> +1 for option 1

<ssahoo2> +1 for option 2

<YolandaGil> option 1: a collection is a type of resource

<jun> +1 for option 2

<YolandaGil> option 2: we keep it as a very lightweight notion

<jcheney> +1 for option 2, more minimalistic for now

<YolandaGil> +1 for option 1

<JimM> +1 on 2

<SamCoppens> +1 for option2

i don't know what we vote on, but, please make it small!

<Irini_> +1 for option 2

<ssahoo2> Paul: Include notion of containment as a property

<pgroth> Paul: but it must be a lightweight notion

<ssahoo2> Paul: Yolanda to include notion of responsibility

<jcheney> is this the same as attribution?

<jun> is that more specific or broader than controlled by?

<ssahoo2> Jim: Seems to be closer to notion of source

<jcheney> I think control does not imply responsibility and vice versa...

<DGarijo> the controller, or the role played by the controller?

<Irini_> very close to attribution I think

<JimM> +1 for something to manage responsibility

<SamCoppens> +1

<ssahoo2> Paul: Include term for responsibility

<DGarijo> yes, +1

<jcheney> +q

<jun> i think we can list responsibility on the list, and maybe mention it's related to controlled by

<ssahoo2> Yolanda: Responsibility is distinct from control

<ssahoo2> James: Are there existing terms for modeling responsibility?

<SamCoppens> a piece of information can be derived from a process, but an agent can digitally sign the information taking responsibility for the generated information. That is why it should be seperated with controlled by

<ssahoo2> James: Similar to trust, responsibility can be derived from provenance

I see responsibility as something not primitive. We can imagine a process that allocates responsibility to a user, all this controlled by some agent. So with the basic terms, we ahve we can model responsibility.

<JimM> +q

<ssahoo2> James: Need to proper to differentiate between responsibility and endorsement

<jcheney> +1 for useful shortcut

<ssahoo2> Paul: Agreement to keep Responsibility as a note

<ssahoo2> Paul: Any missing terms?

<JimM> no :-)

it's not a new term, but what do we say about security

is it in scope of the WG do define ways of signing provenance graphs?

<pgroth> i think we don't time

<jcheney> should wrap up

<jcheney> thanks Paul

<jun> thanks Paul

<DGarijo> yeah, thanks!

great Paul!

<ssahoo2> good work Paul!

<SamCoppens> thanks everybody

<YolandaGil> Ok, I transcribed everything at http://www.w3.org/2005/Incubator/prov/wiki/Suggested_Concepts

<YolandaGil> let me know if I missed anything from today's discussion

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)

Succeeded: s/jum/sun/
WARNING: Bad s/// command: s/jumjun
Found Scribe: Luc Moreau
Found ScribeNick: Luc

WARNING: No "Topic:" lines found.

Default Present: Yolanda, Luc, +30281076aaaa, Irini, jun, SamCoppens, +1.915.603.aabb, jcheney, DGarijo?, +49.166.4.aacc, +1.706.461.aadd, +1.217.417.aaee
Present: Yolanda Luc +30281076aaaa Irini jun SamCoppens +1.915.603.aabb jcheney DGarijo? +49.166.4.aacc +1.706.461.aadd +1.217.417.aaee
Agenda: http://lists.w3.org/Archives/Public/public-xg-prov/2010Nov/0041.html
Found Date: 26 Nov 2010
Guessing minutes URL: http://www.w3.org/2010/11/26-prov-xg-minutes.html
People with action items: 

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