oasis-library-review — archive

[Robin Cover]

Staff conversation about the OASIS Library recently drifted from the Staff Document Management list (staff-doc-man) to the 'oasis-library-review' list. If non-Staff members of this list are interested in design discussions, I'm willing to make occasional cross-posts to this list, or to make other arrangements for wider participation in design meetings. I think Staff would benefit from additional inputs. In any case, I append below the initial portion of a memo sent to the staff-doc-man list about the requirement to store and otherwise manage specification-level information, as (IMO) considerably more relevant than "file" information per se. Nothing said is rocket science, but I do introduce Staff to the key features of FRBR, which is being used widely in digital library projects (along with the ER-OO mapping representation that's more applicable in the digLib space). If anyone may be interested in this topic, let me know, and I'll arrange for forwarding. Cheers, Robin Cover OASIS, Chief Information Architect ====== Initial portion of memo: Specification (document) management vs. file management This memo may be considered optional reading, at least for the time being, though it might be considered timely in connection with the evaluation of KnowledgeTree by IT. I'll let the readers decide on their preferred timing. The immediate backdrop is a set of high-level requirements I've been formulating for external reviewers, but Greg's memo about "OASIS Standards" [1], together with responses from Jamie and Mary, provides a thematic parallel as segue to this topic, per my earlier memo to staff-doc-man. The high-level requirement might be articulated thus: "the OASIS Library document management system must provide facilities for defining models and behaviors appropriate to 'specifications' and relationships between entities/objects that are created in the specification production process. The system must be able to manage complex specification element relationships, only some of which are related to 'files'." Of course, the system must handle several document types and corresponding life cycles other than specifications. Greg's tabulation, for which I am very grateful [2], illustrates quite well why users of Kavi might feel frustrated by an attempt to identify/locate specifications, or to understand spec development from the Kavi document repository. The same can be said, mutatis mutandis, for use of the existing OASIS Library, because the two repository models share the same deficiency: * the folder/file metaphor cannot be trusted to convey any predictable fixed or variable (typed) semantics; in Kavi, any inference is especially weak because folders are mutable, and TCs regularly move files from folder to folder * there is an implicit assumption -- often incorrect -- that a "document" can be mapped to a single "file". In fact, files and documents are often very different things * most pointedly: the raw folder/file metaphor fails to capture essential semantic relations among resources which are part of specification development, especially: -- part/whole relations -- set (member in [unbounded] collection) relations -- principal (core) vs. ancillary/secondary profile or other commentary genre -- prose component vs machine-readable component -- sequence (serial/order) relations -- etc [...] snip/ Robin Cover OASIS, Chief Information Architect Editor, Cover Pages and XML Daily Newslink http://xml.coverpages.org/