- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Fri, 05 Aug 2011 09:40:57 +0100
- To: public-prov-wg@w3.org
Hi Simon, On 08/05/2011 08:49 AM, Simon Miles wrote: > Hi Luc, > > OK, the distinction makes sense, but leads to some thoughts. > > If "role name" is used to identify a parameter/input/port name, then > "role type" may be interpreted as the data type of that > parameter/input. We will have to be clear that it is about the > relation of the entity to the process, not the type of entity required > by the process. > > Yes indeed > I wonder how people will use "role name" in practice - it is clear for > web services or method calls, but not so obvious for document editing, > surgery or publishing. I have not thought it through deeply, but might > it be that "role name" and the constraint of its uniqueness only makes > sense in specialised contexts? Not every process is accurately > replayable. As an alternative, I could imagine the model only talking > about role in the sense of role type, and then having a "workflow > profile" to the model which requires role types to match parameter > names and be unique per execution. > Even for edits, roles can be useful. Stephen C "replays" edits by applying a patch to a document. I think the use case for replay/validation/checking is strong enough, that we should not drop the idea of role name. (We can change the terminology if appropriate!) > My view on role type itself is that, as the value of the role type is > one place where domain-specific information can be put when using the > language, it would be good to make this explicit in the document (see > issue [1]). I guess this means it needs to be included in the language > somehow, e.g. as an additional parameter of the used/generated/etc > relations. > Even for role names, we say that their interpretation is outside the scope of this document, and left to process execution ontology designers. > With regards to formalisation, a role type on a used edge says "how, > specifically, the process execution used the bob" (and equivalently > for other edges). I think this matches exactly the meaning of > rdfs:subClassOf / rdfs:subPropertyOf, i.e. to specify a role type you > are simply specialising the Uses class / property. This implies that > we do not need "role type" to be explicitly part of the formal model > as RDFS already captures the concept. I think this is the approach > taken by OPMV. > Note that the model is supposed to be independent of RDFS. However, I agree with you that role types may be left out of the model. Given a mapping role-name x process execution -> role-type, we should be able to derive role types. On the other hand, it's not unrealistic to write a query such as "give me all contributors to this document", and role types may become useful. > I note that roles only apply to use, generation and control relations. > For role type at least, I'm not sure why derived relations would be > excluded. If we say "X is a prior version of the same thing as Y" or > "X was the template for Y", then we are expressing specifically how X > was involved in Y's derivation. This doesn't seem different in kind to > role types on other edges. > > Roles apply to use/gen/control, because they are "about the relation of the entity to the process execution" as you say. Roles for derivation seem to make less sense. Luc > [1] http://www.w3.org/2011/prov/track/issues/65 > > Thanks, > Simon > > On 4 August 2011 21:25, Luc Moreau<L.Moreau@ecs.soton.ac.uk> wrote: > >> Hi Simon, >> >> I am in agreement. Paolo and I discussed the idea >> of distinguishing role type from role name (like parameter name and >> parameter type). >> Uniqueness property applies to role name, not to role type. >> >> One of the reasons for the uniqueness property is the ability to replay >> executions. >> You need to be able to know which value to "plug" to which input/port. >> >> Currently, all the constraints and definitions pertaining to roles in the >> specification are about role names. >> >> One might argue that role types could be found in the process execution >> specific >> ontology that declares role names. Alternatively, we can make them >> explicit in PIL. >> >> Views on this? >> >> Regards, >> Luc >> >> >> On 04/08/11 16:00, Simon Miles wrote: >> >>> Hi Luc, >>> >>> Reading Graham's comment I'm also unclear what the purpose of this >>> requirement is. >>> >>> I have a suspicion that the lack of clarity could from the conflation >>> of two issues: >>> >>> 1. the desire to express the role played by bobs in executions >>> 2. the desire to have uniquely named parameters for executions, so >>> that bobs used can be uniquely referenced >>> >>> Maybe I'm wrong and this is not the problem at all. But if it is, then >>> I suggest that we untangle the two issues. It is counter-intuitive to >>> me, and I strongly suspect it would be to users of the standard, to >>> disallow us from saying that two bobs played the same role in an >>> execution. If I want to say that process P chose numbers randomly from >>> two lists L1 and L2, then I would want to assert that L1 and L2 played >>> the same role in P. There may well always be a difference in each >>> bob's role if you look in fine detail at P, but I might not know that >>> difference nor want to model it if I did. >>> >>> thanks, >>> Simon >>> >>> On 4 August 2011 09:41, Graham Klyne<GK@ninebynine.org> wrote: >>> >>> >>>> Luc Moreau wrote: >>>> >>>> >>>>> Hi Graham, >>>>> >>>>> On 07/29/2011 10:13 AM, Provenance Working Group Issue Tracker wrote: >>>>> >>>>> >>>>>> [[ >>>>>> A reference to a given BOB may appear in multiple use assertions that >>>>>> refer to a given process execution, but each of those use assertions >>>>>> must have a distinct role. >>>>>> ]] >>>>>> In light of the above, this seems nonsensical to me. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I am trying to understand what the issue is. >>>>> >>>>> We're trying to say: >>>>> >>>>> For any b, bob(b,[...]) >>>>> For any pe, processExecution(pe) >>>>> >>>>> for any two assertions use(pe,b,r1,t1) and use(pe,b,r2,t2), then >>>>> r1<> r2 >>>>> >>>>> Is there a problem with this? >>>>> >>>>> >>>> I now understand what you are trying to express. >>>> >>>> Is there a problem? I don't know, because I don't properly understand what >>>> purpose "role" is serving here. >>>> >>>> Does anything actually break if this requirement is dropped? I.e. if it's OK to >>>> say: >>>> >>>> use(pe,b,r1,t1) >>>> AND >>>> use(pe,b,r1,t2) >>>> >>>> #g >>>> >>>> >>>> >>>> ______________________________________________________________________ >>>> This email has been scanned by the MessageLabs Email Security System. >>>> For more information please visit http://www.messagelabs.com/email >>>> ______________________________________________________________________ >>>> >>>> >>>> >>> >>> >>> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> > > > -- Professor Luc Moreau Electronics and Computer Science tel: +44 23 8059 4487 University of Southampton fax: +44 23 8059 2865 Southampton SO17 1BJ email: l.moreau@ecs.soton.ac.uk United Kingdom http://www.ecs.soton.ac.uk/~lavm
Received on Friday, 5 August 2011 08:41:58 UTC