- From: Simon Miles <simon.miles@kcl.ac.uk>
- Date: Fri, 5 Aug 2011 08:49:52 +0100
- To: Provenance Working Group WG <public-prov-wg@w3.org>
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. 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. 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. 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. 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. [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 > ______________________________________________________________________ > -- Dr Simon Miles Lecturer, Department of Informatics Kings College London, WC2R 2LS, UK +44 (0)20 7848 1166
Received on Friday, 5 August 2011 07:50:23 UTC