W3C home > Mailing lists > Public > public-prov-wg@w3.org > March 2012

Re: PROV-ISSUE-117 (general-comments-on-formal-model-document): General Comments On Ontology Document [Formal Model]

From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
Date: Mon, 05 Mar 2012 16:43:04 +0000
Message-ID: <EMEW3|d010f98360a72b17b72cb06e7483e019o24Gh608l.moreau|ecs.soton.ac.uk|4F54ED18.80001@ecs.soton.ac.uk>
To: Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>
CC: Provenance Working Group WG <public-prov-wg@w3.org>
Hi Daniel,

I am aware the html document is being designed.
The spirit of this issue still holds, though.  I think we shouldn't close
it just now, but only after we have seen the next provo html draft.


On 05/03/2012 16:33, Daniel Garijo wrote:
> Hi Luc,
> the ontology document is being reestructured (Khalid just sent an 
> email with the proposed
> structure of the html), and the possible extensions have been 
> separated in a best practices document.
> Can we close this issue?
> Thanks,
> Daniel
> 2011/10/6 Provenance Working Group Issue Tracker 
> <sysbot+tracker@w3.org <mailto:sysbot%2Btracker@w3.org>>
>     PROV-ISSUE-117 (general-comments-on-formal-model-document):
>     General Comments On Ontology Document [Formal Model]
>     http://www.w3.org/2011/prov/track/issues/117
>     Raised by: Luc Moreau
>     On product: Formal Model
>     Comments about the document
>     ---------------------------
>     Assuming the ontology issues described above are solved, then
>     there is the question
>     of how the specification document should present the ontology.
>     My *key* concern is that the document's motivation is *not aligned*
>     with the charter.
>     The ontology document says:
>     - This ontology specification provides the foundation for
>      implementation of provenance applications
>     - The PROV ontology classes and properties are defined such that they
>      can be specialized for modeling application-specific provenance
>      information
>     - The PROV ontology is specialized to create domain-specific
>      provenance ontologies that model the provenance information specific
>      to different applications.
>     - The PROV ontology consists of a set of classes, properties, and
>      restrictions that can be used to represent provenance information.
>     - The PROV Ontology is conceived as a reference ontology that can be
>      extended by various domain-specific applications to model the
>      required set of provenance terms
>     But the charter says:
>     - The idea that a single way of representing and collecting provenance
>      could be adopted internally by all systems does not seem to be
>      realistic today.
>     - A pragmatic approach is to consider a core provenance language with
>      an extension mechanisms that allow any provenance model to be
>      translated into such a lingua franca and exchanged between systems.
>     - Heterogeneous systems can then export their provenance into such a
>      core language, and applications that need to make sense of
>      provenance in heterogeneous systems can then import it and reason
>      over it.
>     So, it seems that there is a mismatch in motivation.  The
>     standardization effort is about *exchanging provenance information*
>     and not on how to represent it internally into systems.
>     Section "4. Specializing Provenance Ontology for Domain-specific
>     Provenance Applications" provides examples of how to specializa the
>     ontology for specific applications. Are we saying this is normative?
>     Is it the only way do it? My view is that this is purely illustrative
>     and non normative.  The document should make this clear.
>     I would even suggest that it needs to be presented differently. The
>     focus should not be on how to specialize the ontology. Instead, it
>     should demonstrate how applications, with specialized ontologies, can
>     still interoperate.
>     I thought that coming up with a series of normative MUST/SHOULD
>     requirements would have been useful to establish interoperability
>     criteria.  What should we see in the RDF serialization to ensure
>     serializability?
>     e.g. prov:Agent/Entity/ProcessExecution must be explicitly visible ...
Received on Monday, 5 March 2012 16:50:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:10 UTC