OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: the simple case and the regrep tech spec

The Simple Case and the OASIS Regrep Tech Spec

At the recent San Jose meeting of the OASIS Regrep TC
Una (and at least in part Nagwa, but I'll cite Una for
concision) described her view of the relations of the parts 
of a submission.  I wrote in the minutes:

"After some explanation from multiple viewpoints, it became
clear [Terry thinks] that Una wants any given submission to have
the same metadata for all the parts, except for the specification
of relationships among related data, and would even like some
parts of a submission not to have to have metadata other than the
note that they're related to the main piece of the submission.  Terry
realized that the Docbook example in the current spec doesn't show
metadata records for all the related data, and that it should.
Lisa made a distinction between related and associated data.  Do we
really want to have records for all this stuff?  To be discussed in

Robin Cover wrote me a fine message comparing this problem to
problems of descriptive cataloguing in libraries (please post
an excerpt to this list if you like, Robin), and what follows
is pretty much just what Robin wrote, only in different words.

First let me define some terms.

 - "Submission" is a package of information, including if applicable
	the items to be registered, sent by the SO to the RA.

 - "Registered item" is what those items become after they're 
	registered (they are no longer part of a "submission" at that 

 - "Distribution" is a package of items suitable for downloading
	for examination, such as a set of DTD modules, their
	documentation, and a FAQ.  Docbook has such a distribution.

 - "Set of all related data" ("related data" being a 11179 term)
	is the set of all the items in the registry that are
	related to a registered item.

I believe Una wants to keep the simple case simple, and so wants
to be able to process an entire submission package as one unit
in the registration process.  That's fine.

We need to keep in mind that the set of items in a submission 
package is not necessarily identical to the set of items in a
distribution package.  The set of items in a submission package
may include a distribution package plus all the items separately
(as my Docbook examples show); similarly, a distribution might
contain unregistered items.

The set of all related data may include items from more than one 
submission, such as various versions of the Docbook DTD, which
had been submitted separately.

And, in cases more complex than I think Una is contemplating for the
prototype, the set of all related data may contain items from
submissions by multiple SOs, for example documentation by a 
third party, or commentary on a DTD's structure.  The Tech Spec
must be able to handle that case (which I suspect will be the
common one for NIST's IMS implementation), but I'd like to be
able to let Una keep the simple case simple.

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) 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.  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.
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.  Robin, is
this what you have in mind?

We might instantiate this notion as the name of an item in
a classification scheme, so that "Docbook DTD" would be such
an item.  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. 

Note that in db7.txt I gave the name of the Docbook distribution
as "Docbook DTD," which was an error; that's the name of what
corresponds to a literary work.

The point on which our views (Una's and mine) diverge is this:

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.

(Lisa, you distinguished between related and associated items.
Could you expand on that?)

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.

That's not to say that my Docbook examples, which really represent
the metadata as cooked by the RA and probably shouldn't have been
given as examples of how to submit something, are the only way to 
provide the metadata for the items in a submission package.  You
could, in a single document, list all the items in a submission 
package (note that there's no requirement that a submission
consist solely of related items) with their relationships (if
any), representations, names, etc., which is, I think, not far
from the approach Una is taking already, if I understood her
description of her prototype interface.

regards, Terry

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC