W3C home > Mailing lists > Public > public-prov-wg@w3.org > September 2011

Re: Roles (was: Testing the ontology for expressing workflow provenance)

From: Simon Miles <simon.miles@kcl.ac.uk>
Date: Thu, 15 Sep 2011 11:02:13 +0100
Message-ID: <CAKc1nHfYUdLcHjw=vVxFhYmMTSV9vqO4Juq=miKyyPszwnpRBg@mail.gmail.com>
To: Provenance Working Group WG <public-prov-wg@w3.org>
Hello all,

Just to clarify, I understand that specialising used/generated to
assert roles makes it hard for roles to have structured information,
and that if the implied prov:used/prov:generated relation is not
(also) included in a serialisation, non-reasoners will not be able to
traverse the provenance graph.

I was not advocating that this *should* be done, but that I expect
people *will* do to this, especially when they are using their own
ontology for describing domain-specific information. Specialisation of
properties is surely the normal way to provide more specific
information about how things are related, i.e. their roles with regard
to each other. I agree it may not be so normal for a generic workflow
engine, such as Taverna, where their is no pre-defined domain.

The consequence of this may be just to recognise the need for guidance
where what we are proposing does not follow the normal way of doing
things.

Thanks,
Simon

On 10 September 2011 09:45, Graham Klyne <GK@ninebynine.org> wrote:
> I haven't been following this as closely as I should, but I think the
> alternative to specializing "used" may be similar to the CRM event-mediated
> approach whereby provenance information can be incorporated with data about
> things - extra metadata can easily be attached to an "observation" or
> "annotation" (or similar) event.
>
> I think it's a good approach.
>
> #g
> --
>
> On 09/09/2011 19:51, Daniel Garijo wrote:
>> Hi Stian.
>> In first place, thanks for your example. It is very helpful to get things to
>> start moving.
>> In second place, you are right: the ontology has not been updated yet with
>> Satya's proposal
>> for modeling roles. I think it is better than specializing the "used"
>> property, since it allows
>> adding additional information withouth transforming the "Used" property in a
>> class (which is the
>> way to model n-ary relationchips). If we just specialize the "used"
>> property, then we won't be able to
>> link the time of usage, the location of usage, or anything additional
>> metadata.
>>
>> However, we are still discussing this approach, because it is true that when
>> you don't know
>> the role of the used entity, everything might get a bit confusing.
>>
>> You are welcome to join us on monday's telecons :)
>>
>> Best,
>> Daniel
>>
>> 2011/9/9 Stian Soiland-Reyes<soiland-reyes@cs.manchester.ac.uk>
>>
>>> On Fri, Sep 9, 2011 at 12:35, Stian Soiland-Reyes
>>> <soiland-reyes@cs.manchester.ac.uk>  wrote:
>>>
>>>
>>>>   <
>>> http://ns.taverna.org.uk/2011/run/2613aab1-dfe9-4a17-a4be-7589f5d388d6/>
>>>>     a  prov:ProcessExecution;
>>>>          prov:used [
>>>>              rdf:type
>>>> <
>>> http://ns.taverna.org.uk/2010/workflow/ea4168eb-67ea-440f-ab73-818da5efc998/processor/String_constant/out/value
>>>>
>>>>              prov:assumedBy
>>>> <
>>> http://ns.taverna.org.uk/2011/data/2613aab1-dfe9-4a17-a4be-7589f5d388d6/ref/153277f1-5e4f-43fc-968d-ab3a8b038676
>>>>
>>>> ;
>>>
>>> Note that I messed up the direction here - if something was 'used'
>>> then the role should of course be an *input* port.  Just imagine
>>> s/Output/Input/g for the whole thing as it is not possible to edit an
>>> email once it's sent. :-)
>>>
>>>
>>> (I wanted to do the discussion on 'used' rather than 'generated' - as
>>> use can naturally occur in several roles in several process execution
>>> - and indeed in several roles for the same execution)
>>>
>>> --
>>> Stian Soiland-Reyes, myGrid team
>>> School of Computer Science
>>> The University of Manchester
>>>
>>>
>>
>
>



-- 
Dr Simon Miles
Lecturer, Department of Informatics
Kings College London, WC2R 2LS, UK
+44 (0)20 7848 1166
Received on Thursday, 15 September 2011 10:02:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:06:41 GMT