[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 email." 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 point). - "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