PROV-ISSUE-197: Section 5.4.1 and Section 5.4.2 (PROV-DM as on Dec 5)

PROV-ISSUE-197: Section 5.4.1 and Section 5.4.2 (PROV-DM as on Dec 5)

http://www.w3.org/2011/prov/track/issues/197

Raised by: Satya Sahoo
On product: 

Hi,
The following are my comments for Section Section 5.4.1 and Section 5.4.2 of the PROV-DM (as on Dec 05):

Section 5.4.1:
1. "Given an entity record identifier e, two sets of attribute-values denoted by av1 and av2, two entity records entity(e,av1) and entity(e,av2) occurring in an account are equivalent to the entity record entity(e,av) where av is the set of attribute-value pairs formed by the union of av1 and av2."

Comment: Since entity record identifier and entity identifier are stated to be the same in DM (Section 5.2.1), this constraint should be applicable to entities also. In that case, this constraint should hold across accounts also? 

2. "Application of identified-entity-in-account results in an entity record containing the attribute-value pairs age=20 and age=30. This results in an inconsistent characterization of a person."

Comment: This is incorrect. The above characterization may be valid at different points in time or events (when the Berlin Wall fell, East and West Germany unified) etc. I don't think this example is needed in DM.

3. "Account records constitute a scope for record identifiers. Since accounts can be nested, scopes can also be nested; thus, the scope of record identifiers should be understood in the context of such nested scopes. When a record with an identifier occurs directly within an account, then its identifier denotes this record in the scope of this account, except in sub-accounts where records with the same identifier occur."

Comment: This issue has been previously raised multiple number of times. The current version of the DM considers identifiers for entity and entity records to be same - hence the above applies to entity identifiers, which violates the Web architecture for globally unique identifiers and strictly monotonic notion of RDF semantics. 

--------------
Section 5.4.2 
1. Given the account construct that already has all the functionalities of a record container (with additional information about asserter), why is a separate construct of "record container" needed?


Thanks.

Best,
Satya

Received on Wednesday, 7 December 2011 02:17:40 UTC