Related data, etc.

[Terry Allen <tallen@sonic.net>]

Una wrote:
...
| Below is an extract from the FAQs of ISO 11179:
| 
| "C.4  Why does this part of ISO/IEC 11179 not address the registration of
| other objects, such as Object
| Classes and Data Element Concepts?
| 
| Although the above objects may need to be registered for certain purposes,
| the scope of ISO/IEC 11179
| is limited, at this point, to Data Elements."
| 
| As I said in my original email -- I do think that there are good concepts in
| ISO 11179 for registering and identifying "items/data-elements,etc.." but it
| is not FULLY applicable to registering Schemas, etc... 

And Jon and I have responded that we believe it is.

| I do believe that much of the metadata is relevant but I do not think we are
| compliant to ISO 11179 -- as they even state themselves they are only
| concerned with registering data elements. 

That does not make us noncompliant; the extract above indicates
only that the specification committee has not built out its data
model completely.  They are very concerned with all the other
concepts, and in X3.285 have a more unified approach to them.

| We have diverged from ISO 11179 by having registration of
| Data-element-dictionaries, sets.. etc... 

We have extended 11179 a bit, but hardly diverged from it in
this respect.

| What I would like us to do is to have the notion of a "registered-item" ---
| this could be the same as a data-element but for our purposes we have just
| extended the notion of what a data-element is, i.e. could be a DTD, Schema,
| whatever we want to register and then the relationships between
| data-elements - and I think this maps to what Jon is saying.   Lets get rid
| off registering data-element-dictionaries, sets, , and data-elements etc...
| and keep to registering one thing which relates to other things -- I think
| it will make it much easier to comprehend and then just have packages for
| submitting, updating registered-items.  So lets say in the future we have
| everybody doing wonderful analysis and registering individual elements and
| attributes they could then also register the relationship of "containment"
| to represent a given tree-structure.   Looking at the NIST design they also
| have a notion of one registered item.

I don't understand "get rid of registering data-element-dictionaries".
DTDs are certainly not data elements themselves, they are
collections of data elements, to which we must apply
administrative metadata, and we're looking to 11179 for the
administrative metadata concepts, which seem to fit just fine.
Your complaint in the past has not been about registering
d.e.d.'s but rather FAQs and the like.  Jon and I have pointed
out that these other things may not related solely to a single
registered item.

I do not understand the notion of registering a relationship
on its own.  

| We would have to be very careful how we identify types of relationships and
| order within those relationships to properly model a tree structure and this
| is not really specified to any level of detail in ISO 11179 - but I think
| this is probably a future rev of the spec.  ( We would need a relationship
| type of containment and the order number specified). I also think we would
| probably need to extend the metadata to capture fully registered elements
| and attributes.  We would also have to be very careful is specifying rules
| for updating registered-items that are parents of a containement
| relationship as really adding a child data-element modifies the structure of
| a parent data-element.
| 
| I must say one thing that keeps confusing me is the difference between --
| data-element-association and related-data-reference.

from 11179, part 3:

=====
A.3.1     Data element associations

In a data management environment it may be required to control
the relation between 'composite data elements' and the 'component
data elements' which form the 'composite data element'.

Example:
The composite data element: 'address' may be composed of the
component data elements: 'name of addressee', 'street name', 
'street number', 'city name', 'postal code', 'country name'.
=====

That's what I did in the Docbook examples.
 
| data-element-association --- I get is specified as a relationship that
| exists between two data-elements (containment would be an example).
| 
| related-data-reference --- is defined as a reference between the data
| element and any related data  i.e. documentation etc... 

Part 3, Section 6.3.3:
=====
6.3.3     name  :   Related data reference
    definition :    A reference between the data element and any
			related data.
                NOTE The referred data may be registered in
			the same data element dictionary or in other
			dictionaries, repositories.
    obligation :    Optional
    datatype    :   Character string
    comment    :    1. When the related data is controlled by
			another Registration Authority, the
                        reference shall be a unique identifier, e.g.
			comprise the Registration Authority
                        and identifier of the referred data as
			allocated by its Registration Authority.
                        ... 
=====

This clearly envisions related data references as references
to registered items.  It is certainly true that it doesn't
require that the reference be to a registered item.

| The NIST design describes it as I originally interpreted it:
| ASSOCIATION being relationship between data-elements (i.e. strong
| association) -- contained in etc....

The point is that associations are between registered items.

| While related_data_items they define as identification of non-registered
| items related to a registered element.  In most cases such references will
| be URLS or URNS that identify reference manuals, white-papers, example sets,
| style-sheets, etc..
| 
| Now this is what I feel we have been having the debate over --- if these
| examples need to be registered items which came out in our last call ---
| i.e. I cannot not have any relationship except to registered items, so all
| references must be registered in the repository even if they are to external
| references.    Then if this is the case then I am wondering do we need two
| relationship types --- maybe we need one relationship element that defines
| different types of relationships. 

I think what we've disagreed about is how to manage the
administrative metadata for related data:  you have proposed
maintaining the boundaries of submission packages, and others,
including myself, have pointed out the difficulties that
produces, including that it does not allow the related data
to be first-class objects.  It doesn't appear that there's any
difficulty in storing information about the submission package
if you want, but we do need stronger concepts.

If you really don't believe that related data needs
administrative metadata, I would propose instead that XML.org 
not accept for registration such things as documentation, 
only a short list of links to them, supplied by the SO and
registered as a single item.  The Docbook example dbrelated.txt
could be rewritten in HTML to serve that purpose, for example,
and it would then require its own administrative metadata, but
you'd have a lot less to deal with.




regards, Terry