- Ref: DataReferenceModel_09_2004 (2KBX)
- Comment/ Preface: This report sets out a critical assessment of DRM based on a purpose-driven and scenario-based approach. (2KBY)
- A. What is the DRM for? (2KBZ)
- B. Data Reference Model Requirements (2KCS)
- The requirements that the DRM has to address can be framed by thinking about “what data is and has” in the context of the use cases that were summarized above: (2KCT)
- 1. Data has Structure (2KCU)
- 2. Data has Type (2KCV)
- 3. Data has Representation (2KCW)
- 4. Data Exchange has Policies (2KCX)
- 5. Data has Provenance (2KCY)
- 6. Data needs Proof (2KCZ)
- 7. Data has Rights (2KD0)
- 8. Data has Quality (2KD1)
- 9. Data has Event Life Histories (2KD2)
- 10. Data has meaning in a Context (2KC5)
- 1. Data has Structure (2KC6)
- The DRM supports structural specifications with Data Elements, Data Objects and Data Properties. XSD should be a strong guiding light on primitive and structure data types. This figure, from the W3C site , shows a hierarchy of these data types. The complex types are defined as XML Schema definitions. Footnote 9 (2KC7)
- A complete representation of structural forms would require DRM to have all of the common data structures: record, sequence, list, bag, set, collection, etc. We therefore recommend that consideration should also be given for the data structures possible in RDF (list, bag, set) and OWL (Description Logics). More information on these developments can be found at W3C. Footnote 10 (2KD4)
- Beyond OWL, but certainly not in the scope and time-frame of DRM, we may need to consider functional data structures that provide a complete and consistent algebra of data operations. Footnote 11 (2KC9)
- 2. Data has Type (2KCA)
- This figure titled, Ontological View of the Data Representation in the current DRM, illustrates the support provided by the DRM for Data Types. No explicit details were available in the DRM as to how the ‘leaf’ nodes of this ontology map to specific data types or structures. (2KD5)
- 3. Data has Representation (2KD6)
- DRM’s approach to Data Representation is influenced by ISO 11179, a standard for terminology management, in six parts: (2KD7)
- Part 1: Framework for the Specification and Standardization of Data Elements (2KD8)
- Part 2: Classification for Data Elements (2KD9)
- Part 3: Basic Attributes of Data Elements (2KDA)
- Part 4: Rules and Guidelines for the Formulation of Data Definitions (2KDB)
- Part 5: Naming and Identification Principles for Data Elements (2KDC)
- Part 6: Registration of Data Elements (2KDD)
- It is unclear to the authors, at the time of writing, how DRM intends to map to Standard XSD Data Types and XSD User Defined Data Types with and without restrictions. Some of the questions we are left with are: (2KDE)
- 1. Can data elements have more than one data object? (2KDF)
- a. If yes, what is the relationship between them? (2KDG)
- 2. Can a data property have more than one representation? (2KDH)
- a. If yes, then what situations determine which to use? (2KDI)
- b. If no, then how do mappings between representations get handled? (2KDJ)
- 3. How will data representations be understood if they are not XML data types? (2KDK)
- 4. Will there be provision for registering user-defined data types? (2KDL)
- 5. How does DRM intend to handle multi-media data? (2KDM)
- Considerations should also be made for XSD and higher order data structures as mentioned earlier. (2KCC)
- ADOBE XMP should be explored for its metadata representations. Footnote 12 (2KDN)
- 4. Data Exchange has Policies (2KDO)
- An exchange of data occurs in collaboration between parties. Currently the only notion of a ‘Party’ in DRM is “Business Context”. (2KDP)
- We recommend more support for parties and recommend a modeling approach based on the pattern shown in this figure which uses UML notation. (2KDQ)
- An ‘Information Exchange’ object is involved with two or more parties. The relationship between a party and the ‘Information Exchange’ object depends on the role of that party and the policy in effect. The diagram shows an ‘Originator’, a ‘Recipient’ and an ‘Ancillary Role’, for example ‘Auditor’. (2KDR)
- What can happen in an information exchange is governed by the policy object associated with each role. We have adopted ISO RM-ODP’s notion of policy and show examples of the three types of policy that can occur on operations: Obligation, Permission and Prohibition. (2KDS)
- Our recommendation is for DRM to consider such policy specifications along with further refinement of the information exchange model based on a ‘Role-Collaboration’ approach of modeling interactions between parties. (2KDT)
- 5. Data has Provenance (2KDU)
- 6. Data needs Proof (2KDX)
- A fully implemented model of information exchange with support for parties and event histories would improve DRM’s support for proof. (2KDY)
- 7. Data has Rights (2KDZ)
- 8. Data has Quality (2KE1)
- It is unclear if and how the DRM should provide support for data quality. At minimum, perhaps there should be the ability to specify quality assurance by referencing any verification or validation that has been conducted on the data. (2KE2)
- 9. Data has Entity Life Histories (2KE5)
- An Entity Life History (ELH) is a concept from Jackson’s Structured Programming (JSP) Method. The Life History recognizes that data is created, used in various contexts before being destroyed or archived. (2KE3)
- In this figure, the IPRONTO Digital Rights Ontology events surrounding Intellectual Property provide an example to how some events surrounding data might be of importance to DRM. (2KE4)
- If we consider Data as IPR, then we might ask the following questions about DRM: (2KE6)
- 1. How do we determine the creation date? (2KE7)
- 2. Who is the granter of a transaction involving the data? (2KE8)
- 3. Who is the grantee of a transaction involving the data? (2KE9)
- 4. Does the transfer of data, transfer the rights to the data? (2KEA)
- 10. Data has meaning in a Context (2KEB)
- A fully implemented model of information exchange with support for parties and a clearer connection to the BRM through named (ontological) relationships would improve DRM’s support for conveying data semantics within a business context. (2KEC)
- C. How should DRM be published? (2KED)
- D. Validation of DRM Scope – ISO RM ODP Considerations (2KEF)
- This section sets out to look at the scope of DRM by viewing DRM from other standards, architecture and infrastructure frameworks. In this version of our comments, we consider only two aspects of ISO RM-ODP: Policies and Transparencies. (2KEG)
- 1. Policies (2KEH)
- ISO RM-ODP’s support for policies provides important input to the DRM specification. See treatment above for parties, roles and Information Exchange. (2KEI)
- 2. Transparencies - RM-ODP defines a number of transparencies: (2KEK)
- Access transparency (2KEL)
- A distribution transparency which masks differences in data representation and invocation mechanisms to enable inter-working between objects. ---> Key requirement needed to be addressed by DRM (2KEN)
- Failure transparency (2KEP)
- A distribution transparency which masks, from an object, the failure and possible recovery of other objects (or itself), to enable fault tolerance. ---> Out of Scope for DRM - Requirement on the Data Transfer Mechanism (2KEQ)
- Location transparency (2KER)
- A distribution transparency which masks the use of information about location in space when identifying and binding to interfaces. ---> Out of Scope for DRM - Requirement on the Data Transfer Mechanism (2KES)
- Migration transparency (2KET)
- A distribution transparency which masks, from an object, the ability of a system to change the location of that object. Migration is often used to achieve load balancing and reduce latency. ---> Out of Scope for DRM - Requirement on the Data Transfer Mechanism (2KEU)
- Relocation transparency (2KEV)
- A distribution transparency which masks relocation of an interface from other interfaces bound to it. ---> Out of Scope for DRM - Requirement on the Data Transfer Mechanism (2KEW)
- Replication transparency (2KEX)
- A distribution transparency which masks the use of a group of mutually behaviorally compatible objects to support an interface. Replication is often used to enhance performance and availability. ---> Out of Scope for DRM - Requirement on the Data Transfer Mechanism (2KEY)
- Persistence transparency (2KEZ)
- A distribution transparency which masks, from an object, the deactivation and reactivation of other objects (or itself). Deactivation and reactivation are often used to maintain the persistence of an object when a system is unable to provide it with processing, storage and communication functions continuously. ---> ?Out of Scope for DRM - Requirement on the Data Transfer Mechanism (2KF0)
- Transaction transparency (2KF1)
- A distribution transparency which masks coordination of activities amongst a configuration of objects to achieve consistency. ---> Out of Scope for DRM - Requirement on the Data Transfer Mechanism (2KF2)
- E. Conclusion (2KF3)
- The main points of this review are that the DRM is not specific enough to be adopted – it generates more questions than it answers. Our recommendations are summarized below: (2KF4)
- Specify complete data structuring model; (2KF5)
- Provide specific model of parties, roles and information exchange; (2KF6)
- Consider collaboration as a 1st class construct for information exchange; (2KF7)
- Make the relationships between the DRM and the BRM specific; (2KF8)
- Consider PRISM and related standards for provenance; (2KF9)
- Consider Digital Rights Management; (2KFA)
- Specify explicit relationship between DRM and XSD; (2KFB)
- Consider ISO RM-ODP for policies; (2KFC)
- Investigate impact of Adobe XMP models on DRM adoption; (2KFD)
- Partition DRM into different areas of concern (2KEO)
