Re: The Simple Case

[Jon Bosak <Jon.Bosak@eng.sun.com>]

There's a question for Una and Nagwa toward the end of this.

[Terry Allen, back in his posting of last Saturday:]

| Actually, I don't think anything in the current spec prevents
| the simple case from being simple (if we omit the material about
| submissions, which I have suggested in a separate message).  There
| is something that needs to be added, and on one point we have a 
| divergence of views.
| 
| The thing that needs to be added is a notion corresponding not
| quite to "a principal registered item" (it's pretty hard to figure
| out what that would be for, e.g., the Docbook DTD; suggestions
| welcome)

I would have guessed driver.dtd to be the principal registered
item.  Am I missing something?

| and not quite to "submission": it's the key by which the thing to
| which related data are related is identified for purpose of
| display in the list of related data.

Is this what data-element-concept is for?  Sounds like it from
your documentation:

   data-element-concept 

      Part 1, definition 3.3.15: "concept that can be represented
      in the form of a data element, described independently of
      any particular representation." It contains an optional
      binding of object class to property (optional, as these
      concepts have not yet been clarified as being relevant to
      data element dictionaries), a definition-text element (in
      ISO/IEC 11179 the description of a data element concept is
      primary; the names of that data element are secondary, and
      the concept may exist independently of any name), and any
      number of classification elements, permitting the data
      element concept to be rooted in any number of classification
      schemes.

      Part 1, definition 3.3.45: "set of objects. A set of ideas,
      abstractions, or things in the real world that can be
      identified with explicit boundaries and meaning and whose
      properties and behavior follow the same rules." Its value is
      a string (provisionally).

| For the purpose of the dbrelated.txt example I made this the
| entire Docbook distribution, but as noted above, that's a
| simplification, as the set of related data may not be the same as
| the distribution.

I don't see dbrelated.txt on the public page, and I don't seem to
have a working password at the moment, so I don't actually have an
example of this in front of me at the moment; my apologies.

| It's more like a node in a taxonomy (or other classification) of
| DTDs.  We can make this something abstract (that is, not any of
| the registered items).  It would correspond to the notion of a
| literary work: the Bible is a literary work with many versions and
| physical instantiations, none of which is primary in the way a
| book's first edition can be.

Yes.

| We might instantiate this notion as the name of an item in
| a classification scheme, so that "Docbook DTD" would be such
| an item.

Due to my unfamiliarity with the spec, I'm not quite sure what you
mean by this.

| Note that this classification scheme would not be
| the same as the subject matter classification scheme we know
| we need.  That node could then be pointed to, if appropriate,
| in the metadata for registered items relating to Docbook. 

[...]

| I understand Una to want it to be possible to have registered
| items that don't have registry entries or metadata, except that
| which is inherited from the submission in which it arrived.  This
| simplification won't do in an implementation of 11179, and I think
| it's not right anyway.  In the 11179 model everything has
| metadata: its SO, its representation, its name, and its name
| context, for starters.  Representation, name, and name context
| cannot be inherited from another registered item, nor from the
| submission.  Una mentioned language during the ACXO meeting; that
| too cannot be inherited.

This seems to be the nut of the problem.

Question for Una and Nagwa: Can we build something into the UI
that makes a submission appear to the user as a structured object
with a common set of metadata and then, behind the curtain, make a
bunch of registered objects whose metadata is populated with
information from the metadata on the original submission?

As the user, I think that I can handle the idea that metadata on a
"subsidiary item" in the intial submission become independently
changeable metadata once all the component pieces have been
checked in.  Let me put it this way: once I check out an item for
maintenance, I've already made the leap to thinking of it as a
first-class object that has become magically changeable
independent of the initial configuration of the submitted package,
so I'm unlikely to be shocked when I discover that this now
independent object has acquired independent metatdata.

| The 11179 model allows everything registered in the registry to 
| be dealt with on the same basis and permits assembly of large-scale 
| constructs through the concept of related data.  We don't want
| to give that up, and as a group dedicated to Structured Information
| Standards, we sure want to implement ISO/IEC 11179 correctly.  It's
| going to be the foundation of a lot of other work.

I agree.  Once in place, the same mechanism can be used for any
kind of conceptual relationship.  This is good.  And it doesn't
look on the face of it to be all that terribly hard to implement
given the facilities of a good document database system.  Is it?

Jon