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/