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

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

From: Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>
Date: Thu, 6 Oct 2011 11:31:10 +0200
Message-ID: <CAExK0De3xhxLiDxjmWHrrJnFWT15rEm9MbfrZnPE6kBc3g8W=A@mail.gmail.com>
To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Cc: public-prov-wg@w3.org
2011/10/6 Luc Moreau <L.Moreau@ecs.soton.ac.uk>

>
> Thanks Paul for pointing this sentence out.
>
> I would like to see it rephrased along the lines:
>
> While the PROV Ontology is designed to be reused and specialized for
> representing domain-specific provenance information,
> its classes and properties are expected to be used directly while
> exchanging provenance information.
>

+1 to this change.

>
> Luc
>
>
>
>
> On 10/06/2011 09:45 AM, Paul Groth wrote:
>
>> Hi,
>>
>> I would like to emphasize Luc's comments:
>>
>> In particular, I'm also worried about this phrase:
>>
>> "The PROV Ontology is not designed to be used directly in a domain
>> application and its Classes and Properties represent "higher-level" or
>> abstract level concepts that can be specialized further for representing
>> domain-specific provenance information."
>>
>> This seems to imply that one would not see any PROVONT concepts in
>> documents on the web. If you look at what we want, is the ease of
>> interoperability and that means the reuse of terms between applications on
>> the web. (See the success of dublin core or schema.org).
>>
>> Maybe this can be rephrased?
>>
>> Thanks,
>> Paul
>>
>>
>>
>> On Thursday, October 6, 2011 at 10:39 AM, Provenance Working Group Issue
>> Tracker wrote:
>>
>>
>>
>>> 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<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 ...
>>>
>>>
>>
>>
>>
>>
>
> --
> 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<http://www.ecs.soton.ac.uk/%7Elavm>
>
>
>
Received on Thursday, 6 October 2011 09:31:39 GMT

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