Re: PROV-ISSUE-155 (prov-o-pre-fpwd): general comments on prov-o document [Formal Semantics]

Hi,

Sorry, I pressed the submit button without typing an introduction.

Find some comments about the prov-o document (which  I downloaded today 
21/11/11).
I didn't feel any single comment was really worth an issue on its own, 
except one, but it
has already been assigned an issue (ISSUE-117).

Two key recommendations, made by Paul are I, appear at the bottom of 
this message.
If those recommendations are implemented (they require a simple edit), I 
believe
that the document can be released as FPWD. The comments I raised here 
can be worked
on after the fpwd release.

Cheers,
Luc


On 11/21/2011 10:06 AM, Provenance Working Group Issue Tracker wrote:
> PROV-ISSUE-155 (prov-o-pre-fpwd): general comments on prov-o document [Formal Semantics]
>
> http://www.w3.org/2011/prov/track/issues/155
>
> Raised by: Luc Moreau
> On product: Formal Semantics
>
>
> - Abstract:
> " The PROV ontology is specialized to create domain-specific
>    provenance ontologies that model the provenance information specific
>    to different applications"
> Well, the charter says that the focus is on inter-changing provenance
> information, and we will be application agnostic. It's therefore surprising
> that this statement and associated section is part of the normative specification.
>
> Note that similar comments were already raised in ISSUE-117
>
> - Abstract:
> "The PROV ontology supports a set of entailments based on OWL2 formal
> semantics and provenance specific inference rules. "
> There was a request to be precise about the lightweight nature of this
> ontology.
>
> -Needs a status of this document (SOTD)
>
> - 1.Introduction
> "This ontology specification provides the foundation for implementation of provenance applications in different domains using the PROV ontology for representing, exchanging, and integrating provenance information."
> I believe we should only focus on exchanging provenance information. Our message is not about
> how application should implement provenance.
>
> "this document forms a framework for provenance information interchange AND MANAGEMENT " ->  drop management
>
> "Thus, the PROV ontology is expected to be both directly usable in applications as WELL AS SERVE AS A REFERENCE MODEL FOR CREATION OF DOMAIN-SPECIFIC PROVENANCE ONTOLOGY"
> ->  this seems to go against the spirit of the charter
>
> - 1.1
> "This document is intended for provide an understanding of the PROV ontology and how IT CAN BE USED BY DIFFERENT APPLICATIONS TO REPRESENT THEIR PROVENANCE INFORMATION."  ->  again, against the charter spirit.
> We should just restrict ourselves to exchange.
>
> - "... to facilitate standardization. " What do you mean?
>
> - 2.1
> "he PROV Data Model [PROV-DM] uses an Abstract Syntax Notation (ASN) to describe the set of provenance terms that are used to construct the PROV ontology. There are a number of differences between the PROV-DM ASN and th"
> The prov-o document should not refer to prov-asn, but only prov-dm.
>
> - " the notion of "EXPRESSIONS" used in the  "
> replace expression by record
>
> - " PROV-DM discusses the use of "Qualifier" to as  "
>   it no longer does!, just attributes.
>
> - What is the purpose of the note: "In addition, RDF is strictly monotonic and "...it cannot express closed-world assumptions, local default preferences, and several other commonly used non-monotonic constructs."[RDF-MT], but the PROV-DM seems to introduce the notion of non-monotonic assertions through "Account" construct [PROV-DM]. For example, Account description in PROV-DM states that it "It provides a scoping mechanism for expression identifiers and for some contraints (such as generation-unicity and derivation-use)."
> If accounts are to be mapped to named graphs, is prov-dm taking different assumptions than rdf?
>
> - 3.1.1: "An Entity REPRESENTS AN identifiable characterized thing"
>   ->  An Entity IS an identifiable characterized thing
>
> - The text still contains variables/names "pe" to denote activities
>
> - 3.1.5:  ProvenanceContainer has become RecordContainer
>
> - "According to the definitions of ProvenanceContainer and Account, both contain a set of provenance assertions and have an identifier. Hence, ProvenanceContainer class can also be used to create instances of accounts."
>    I was not necessarily expecting a RecordContainer/ProvenanceContainer to be modelled as a class.
>    The record container contains prefix-namespace mapping, which in
>       - rdf  is typically contained in the RDF element
>       - xml could be declared in the root document
>
>    Accounts do not have prefix/namespace declarations. So it's strange to see that the same class is used.
>
> - issue-81 is closed pending review, why is it mentioned?
>
> - 3.1.6: the crime file example does not have location. It was
>    incorrect of prov-dm to use the attribute location, it is instead
>    path.
>
> - 3.1.7.1 Usage
>
> "The Usage class represents an n-ary property to capture qualifying
> information related to the the use, GENERATION, CONTROL, AND
> PARTICIPATION" ?????.
>
>
> - 3.2.1: "The wasGeneratedBy property links the Entity class with the Activity class."
> What does it express? That there exists at least one instance of a qualified generation between
>    an entity and an activity, though this instance may not have been asserted.
>    If is permitted for multiple of these instances (for an entity-activity pair) to exist.
>
> - 3.2.3: issue 42 is closed
>
> - 3.2.3 why cite issue 43?
>     The only reason to cite it, is that you may want to say that a qualified derivation may need
>     to be introduced if time is to be introduced.  Otherwise, don't cite.
>
> - 3.2.4
> why cite issue-122, 125 and 126? they are closed pending review
>
> - 3.2.4:
>    prov-dm is in the process of changing the names
>
>
> - 3.2.7: "The hadPariticipant property links Entity class to Activity class, where Entity used or wasGeneratedBy Activity." this does not correspond to the definition.
> Note, term to be deprecated.
>
>
> - 3.2.8: what's the purpose of the note? this does not make sense according to prov-dm.
>
> - 3.2.9 wasControlledBy: whole terminology to be changed according to Yolanda's proposal.
>
> - 3.2.15: wasQuoteOf
>      range should be entity (really, it's entity and optionally agent)
>
> -3.2.xxx  hasQualifiedXXX
>      do we really need to make the term qualified explicit
>
> -3.3: Note, how can you say that an agent can be a PE, when entity and activity are supposed to be disjoint.
>
> - Section 4, should only be informative. It should not be normative.
>    Paul and I recommends that this section is moved into a separate document: best practice.
>
> - Lots of comments with section 5.
>    Fundamentally, it is not clear what it is trying to achieve, since most constraints don't really seem
>     to be addressed, or are no longer part of prov-dm.
>    Paul and I recommends that this section is moved into a separate document too.
>
>
>
>
>    

-- 
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

Received on Monday, 21 November 2011 10:18:11 UTC