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

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

From: Provenance Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Mon, 21 Nov 2011 10:06:03 +0000
To: public-prov-wg@w3.org
Message-Id: <E1RSQlH-0003N1-HL@barney.w3.org>

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


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

-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

- Usage

"The Usage class represents an n-ary property to capture qualifying
information related to the the use, GENERATION, CONTROL, AND

- 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.
Received on Monday, 21 November 2011 10:06:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:10 UTC