Re: Using PROV-O to represent ontology processing, extraction and reasoning operations

Thanks for reminding me about SWO - it has an activity branch that could
serve as an additional root class as well as PROV. The SWO authors happen
to know a few things about my use case as well.

Point taken about there being some flexibility in pushing the semantics
towards the agent/algorithm vs the activity. It seems most natural to place
under activity in this particular case.

On Tue, Nov 28, 2017 at 8:51 AM, Graham Klyne <gk@ninebynine.org> wrote:

> I now realize I misread your original reference to "software agents".
> Sorry for the noise there
>
> I've certainly used modelling patterns that subclass prov:Activity in some
> of my work.  I don't know if that's a "standard" pattern, but it seems
> reasonable to me in some situations.  I'm not aware of any specific
> hierarchies based on prov:Activity of the kind you ask about.
>
> However, there are ontologies out there that incorporate process
> descriptions that could also be considered as instances of prov:Activity -
> e.g. I've done some work that declares instances of CIDOC CRM "E7_Activity"
> (http://www.cidoc-crm.org/Entity/e7-activity/version-6.2) that are also
> instances of prov:Activity (I realize this isn't what you're asking for).
> I imagine there could be some workflow-related vocabularies that might be
> closer - e.g. this relating to Taverna: http://www.essepuntato.it/lode
> /http://ns.taverna.org.uk/2010/scufl2 - though that is maybe too
> low-level for your requirements.  Googling for "scientific workflow
> ontology" turns up a number of options.
>
> But your example seems to focus more on the kind of algorithm that is
> implemented by an activity, which leads me back to thinking about the
> software agent that controls it.  Googling for "scientific software
> ontology" throws up a few options, and this in particular caught my eye:
> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4098953/ ("The Software
> Ontology").  I'd contemplate using a single prov:Activity type, but in each
> case qualifying it via prov:wasAssociatedWith with an agent that includes a
> fuller description of the software algorithms implemented - that way could
> use existing software system categorizations.
>
> HTH.
>
> #g
> --
>
>
>
> On 25/11/2017 18:46, Chris Mungall wrote:
>
>>
>> I had anticipated using prov:wasAssociatedWith, and not creating any new
>> properties. The gap to be filled is on the side of subclasses of
>> prov:Activity,
>> for representing operations specific to ontology processing.
>>
>> Assuming such an ontology, does this rough sketch seem like a standard
>> pattern?
>> Is there a good analogous set of design patterns to follow (e.g. software
>> compilation, scientific workflows)?
>>
>> ```
>> @prefix prov: <http://www.w3.org/ns/prov#> .
>> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
>> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>> @prefix owl: <http://www.w3.org/2002/07/owl#> .
>> @prefix obo: <http://purl.obolibrary.org/obo/> .
>> @prefix opera:
>> <http://example.org/OntologyProcessingExtractionReasoningOntology/> .
>>
>> ## Ontology header
>> obo:foo.owl a owl:Ontology ;
>>     dc:title "..." ;
>>     prov:wasDerivedFrom obo:foo/foo-edit.owl ;
>>     prov:wasGeneratedBy obo:foo/op1 ;    ## see below
>>     prov:wasAttributedTo obo:foo/editors ;
>>     ...
>>
>> ## Ontology provenance
>> obo:foo/op1 a opera:ReasonOperation ;
>>     prov:used obo:foo/foo-edit.owl ;     ## 'source code'
>>     prov:wasInformedBy <configuration??> ## what to use here?
>>     prov:startedAtTime "..." ;
>>     prov:endedAtTime "..." ;
>>     prov:wasAssociatedWith <github/mavenOrGithubIRIforROBOTversion??> ;
>>
>> ## Ontology below
>> obo:FOO_0000001 a owl:Class ;
>>      ...
>> ```
>>
>>
>> On 25 Nov 2017, at 0:29, Graham Klyne wrote:
>>
>> Is there any reason that http://www.w3.org/TR/prov-o/#wasAssociatedWith
>>> doesn't work for you?
>>>
>>> My recollection of PROV discussions is that involvement of human,
>>> software and
>>> other agents in an activity was intended to be captured using this (or
>>> qualifiedAssociation structures - cf.
>>> http://www.w3.org/TR/prov-o/#qualifiedAssociation).
>>>
>>> (IIRC, the "qualifiedAssociation" and similar structures --
>>> http://www.w3.org/TR/prov-o/#description-qualified-terms -- were
>>> introduced to
>>> avoid application-dependent (not a priori defined) sub-properties, which
>>> would
>>> break OWL-QL compatibility of PROV, with attendant reasoning performance
>>> challenges.)
>>>
>>> #g
>>> --
>>>
>>> On 24/11/2017 22:15, Chris Mungall wrote:
>>>
>>>> Many ontologies such as those in the life-sciences have complex
>>>> multi-step
>>>> release pipelines: for example, using an OWL reasoner to assert direct
>>>> inferred
>>>> subClassOf axioms, adding owl annotations, verifying using SPARQL. It
>>>> would be
>>>> useful to capture the full operation graph, so that the provenance of
>>>> the
>>>> released ontology was explicit.
>>>>
>>>> PROV-O would provide the main framework for doing this. PROV-O
>>>> predicates could
>>>> be used directly. Existing standards could be used to represent the
>>>> software
>>>> agents involved. AFAICT there is a gap for an ontology for representing
>>>> the
>>>> ontology processing operations (subclasses of prov:Activity).
>>>>
>>>> Is there an existing effort that could be piggy-backed on here? This
>>>> could be
>>>> subsumed into an effort that seeks to represent for example
>>>> transformations
>>>> between named graphs. Alternatively, the ontology build pipeline could
>>>> be
>>>> conceived either as a software release process or a scientific
>>>> workflow. For the
>>>> latter, there are a number of ontologies but it's not clear we'd get
>>>> any benefit
>>>> using these rather than PROV-O directly.
>>>>
>>>> If there is no existing work being done here, I'll propose a draft of
>>>> activity
>>>> classes and design patterns, and we can do a demo implementation in our
>>>> ontology
>>>> release tool [ROBOT](https://github.com/ontodev/robot). But I'd rather
>>>> not
>>>> duplicate any existing efforts.
>>>>
>>>
>>