Suggestions for Broad And Specific Improvements To 11179 Edition 3

1. Suggestions for Broad And Specific Improvements To11179 Edition 3 Frank Farance, Farance Inc.frank@farance.com, +1 212 486 4700 Dan Gillman, BLSgillman.daniel@bls.gov, +1 202 691 7593 Improvements to 11179 Edition 3, F. Farance, D. Gillman

2. Main Issues • Much current work on data does not work well with 11179-3 edition 2 or current proposed edition 3 • Typical “struct”s (aggregate, nested, or structured data) don’t have any natural mapping • Most applications (programs, database structures, XML data) don’t have any natural mapping Improvements to 11179 Edition 3, F. Farance, D. Gillman

3. Main Issues • Terminology theory is powerful • We (WG2) want terminology theory applied and harmonized with edition 3 • Yet, terminology theory and its structures (e.g., concept systems) have little obvious place • We (Frank and Dan) are concerned about the computational aspects of 11179-3 • What computations and results does it afford? Improvements to 11179 Edition 3, F. Farance, D. Gillman

4. Main Issues • Aesthetically, we (Frank and Dan) have concerns about current proposals: • Metamodel is too large and complex, not an elegant solution • Metamodel appears to be designed for limited user communities • Metamodel, itself, imposes certain structures that are not helpful for describing data in a general way Improvements to 11179 Edition 3, F. Farance, D. Gillman

5. Solution Approach • Let’s take a step backwards and remind ourselves of what we need • Let’s remind ourselves of the underlying theory that applies • Let’s try to recreate a solution that ... Improvements to 11179 Edition 3, F. Farance, D. Gillman

6. Solution Approach:Is Scalable • We need a solution that scales: • to a large number of entries • to a large heterogeneous network of metadata instances and repositories • to support common computation (navigation, queries, inferences, etc.) • to support varying kinds/degrees of administration (none, registration, self-describe, limited description) • to support varying qualities/degrees of description Improvements to 11179 Edition 3, F. Farance, D. Gillman

7. Solution Approach:Has Broad Applicability • We need a solution that supports common use cases: • “plain old data structures” common to virtually all programming language and databases • commonplace re-usability technology, e.g., “includes”, libraries of incomplete types and objects/classes • terminological systems • object-oriented systems • ontology systems Improvements to 11179 Edition 3, F. Farance, D. Gillman

8. Solution Approach:Is Distributable • We need a solution that supports distributed development, maintenance, and administration of data/metadata: • cross-linking/referencing of data/metadata • linking administrative data to virtually any item or collection of items • data/metadata/registry interoperability is NOT an afterthought Improvements to 11179 Edition 3, F. Farance, D. Gillman

9. A Walking Tour of Data(Discovering Metadata) • What is data? What is a datum? • What is metadata? • Where do datums come from? • Abstracting datums • Relationship to other datums? • Computational aspects of datums • Structural aspects of datums Improvements to 11179 Edition 3, F. Farance, D. Gillman

10. What is Data? What is a Datum? • A designation is a relationship between a sign and a concept • the sign designates the concept • A datum is a kind of designation whose concept is a value • the sign designates the value • A value is a kind of concept that includes the notion of equality to itself • The term data is the plural of datum, so is datums Improvements to 11179 Edition 3, F. Farance, D. Gillman

11. What is Metadata? • The term metadata means: descriptive data about an object • Note: metadata might describe more than one object • 11179 should use such a broad definition of metadata so that 11179 concepts can be used/re-used/adapted elsewhere • Caring about metadata implies caring about shared/common concepts Improvements to 11179 Edition 3, F. Farance, D. Gillman

12. Where Do Datums Come From? • A datum is created in one of two ways: • A data generator, such as an instrument, creates a datum by associating a sign (e.g., symbol) with a value (a concept) • A data processor, such as a computer, creates a datum from other datums Improvements to 11179 Edition 3, F. Farance, D. Gillman

13. Where Do Datums Come From? • The range of possible values (concepts) forms a concept system • In 11179, we call this concept system a conceptual domain • Note: 11179 imposes a flattened conceptual domain and this is a significant limitation in the current 11179 approach. Improvements to 11179 Edition 3, F. Farance, D. Gillman

14. Where Do Datums Come From? • An object class is the shared characteristics of all the possible datums of interest, i.e., the object class forms in intensional definition of the common characteristics (itself, a concept) Improvements to 11179 Edition 3, F. Farance, D. Gillman

15. Where Do Datums Come From? • A datum can represent a property that is extracted, along the lines of a characteristic, from an object in an object class • An instrument might extract the property (a value) from an object corresponds to the characteristic of the object class (the object is in the extension of the concept of the object class) — complete harmonization with ISO 704 Improvements to 11179 Edition 3, F. Farance, D. Gillman

16. Where Do Datums Come From? • Within the concept system known as a conceptual domain, some of the concepts may have designations, i.e., signs associated with these values (concepts) • A value domain is the terminology of this concept system • the signs (what 11179 currently calls “values”) are associated with the concepts (what 11179 currently calls “value meanings”) • 11179 should harmonize terminology with 704 Improvements to 11179 Edition 3, F. Farance, D. Gillman

17. Abstracting Datums • When we think of a data element, we think of a “bucket” that might hold one or more datums • Just like in terminology where a characteristic is an abstraction of properties, a data element is an abstraction of datums • a terminology definition of a data element • This is a bottom-up approach towards defining the essential features of 11179 Improvements to 11179 Edition 3, F. Farance, D. Gillman

18. Relationships to Other Datums • Currently, 11179 does not support arbitrary relationships among items • Reified relationships are necessary Improvements to 11179 Edition 3, F. Farance, D. Gillman

19. Structural Aspects of Datums • Currently, 11179 does not support common relationships that are pervasive in data processing • 11179 should support a dictionary of pre-defined relationships that match common data structuring, such as aggregates, records, arrays, tables, sets, etc. Improvements to 11179 Edition 3, F. Farance, D. Gillman

20. Characteristics vs. Reusability • Current metamodel imposes significant structural aspects of metadata, yet structuring is not necessary for semantics • Largely, the characteristics and properties (11179 attributes) could be flattened almost completely • We (Frank and Dan) believe current metamodel structures are an artifact of reusability concerns for limited use cases, i.e., re-use of shared characteristics Improvements to 11179 Edition 3, F. Farance, D. Gillman

21. Characteristics vs. Reusability • 11179 should let users determine which kinds of reusability packages are most appropriate for their applications (e.g., typical issues that arise in current discussions of UML metamodel) • The reusability structuring are independent of data/metadata semantics, i.e., one can get the same semantics by probing registries that have different reusability structure • In fact, via 20944 serialization, it proves that the structure is independent of the semantics Improvements to 11179 Edition 3, F. Farance, D. Gillman

22. Packaging of 11179 • No attribute appears in more than one part • Part 1: overview describing how the standard is be used, describing the idea of conformity to each part, multiple part conformity, and how to indicate that; “common backplane”; describe other parts • Part 2: concept system, ontology, and classification - the attributes necessary to describe these and the relations among them Improvements to 11179 Edition 3, F. Farance, D. Gillman

23. Packaging of 11179 • Part 3: data semantics - the attributes for what is similar to the ed 2 metamodel, minus classification, registration, and all the UML • Part 4: ISO 704 written for data, obviously includes ed 2, and includes all the terminology model attributes Improvements to 11179 Edition 3, F. Farance, D. Gillman

24. Packaging of 11179 • Part 5: naming conventions, name spaces, and identifiers - basically all about designations and references • Part 6: registration, and includes all registration attributes - needs to include the ideas of registration developed under ebXML registry Improvements to 11179 Edition 3, F. Farance, D. Gillman

25. Packaging of 11179 • Other parts may become necessary as we expand, but trying to put all the attributes into one part will fail — it is too large a set to adequately manage the entire thing. Improvements to 11179 Edition 3, F. Farance, D. Gillman

26. Conclusions • We believe edition 3 should be compatible with edition 2 • We believe a simpler approach will afford more applicability, more coherent semantics, and (thus) better computability • We will present a more detailed approach on the specific normative wording at the next meeting Improvements to 11179 Edition 3, F. Farance, D. Gillman