See also: IRC log
<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
Yolanda: OK, we have
... we should keep in mind those requirements/recommendations
A formal thank you to Yolanda for her amazing chairing of the incubator.
<DGarijo> yeah, thanks!
Paul: I tried to group the set of suggested concepts
Paul: proposal, go through the
list of concepts, identify issues with grouping, identify
... then go through timeline. Feedback from Yvan to be discussed
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.
Paul: are we fine with a notion
... 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?
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.
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
<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> 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
... 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
<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
... 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?
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?
<ssahoo2> Yolanda: Why are we removing the other examples from the grouping page for the agreed on terms?
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)?
<YolandaGil> +1 go away
Jim: user query can be seen as role, each community could define the kind of roles they consider important
<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
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?
<DGarijo> yolanda, yes: if the sensor is a buoy, in the disease outbreak scenario, then it's important to know where was it produced
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
Paul: like we did for recipe lonk
<ssahoo2> yes, it is a link
<ssahoo2> +1 for link
<DGarijo> +1 for derivation
Paul: next: derivation
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
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
<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
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
... we should not the relationship between participation and control, and the fact they influence processes
<YolandaGil> I noted on the wiki that Control is a subclass of participation, and put Control after Participation in the list
Satya: is provenance container a resource?, same for collection
Paulo: why not use named
... 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
<jun> it's a complex problem that cannot be solved in one telcom
<Irini_> +1 for sun
<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
Paul: we agree we want a provenance container (which could end up being a named graph)
<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?
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
+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
<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
<ssahoo2> Paul: Include term for responsibility
<DGarijo> yes, +1
<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.
<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!
<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[End of scribe.perl diagnostic output]