Comments on Dspace History System: Descriptive Note (1 May 2003)

* Apologies to me HP mates for the dupe
* Apologies for the TWiki markup

John

---++++ Comments on Dspace History System: Descriptive Note (1 May 2003)
_Revised 7 May 2003 (JSE)_

   * These notes are organized by section numbers of the original document;
not
all sections are represented...

---++++ 1.3 Introduction.Motivation

   * Please change the "negatives" in this section (re: the current system)
into "positives" about the planned system. i.e.:
      * There *will* be an explicit schema...
      * The output *will* be consistent with public schemas...
      * The use of RDF to model static/dynamic properties *will* be consistent
with best practices...
      * The RDF models *will* facilitate validation against metadata
schemas...
      * etc...

---++++ 2.1 Namespaces

   * The Dspace practice of "adopting" external schema without explicit
reference to their external "homes" (and explicit relationships via the
Harmony ontology) provides a stand-alone capability but seems like it would
present long-term maintenance issues
   * Generally, everything implicit should be made explicit

---++++ 2.2 Resources

   * This whole section (and elsewhere whenever Harmony is referenced) could
use a more formal/explicit expression of the relationship of Dspace-created or
adopted properties to the Harmony ontology
   * I'm particularly concerned with the use of manifestation, item and
bitstream
   * The references to Harmony need to be more *precise*; for example, nowhere
in the ABC Model pubs can I find a definition of "bitstream"

(Note: I think AndyS had similar issues)

---++++ 3.1.1 Use of External Schemas

   * No distinction should be made between semantically identical properties
that are syntactically identical (same property name, same meaning) and those
that are different (different property name, same meaning)
   * In other words, property relationships should be *explicitly* related
across schemas by declaring (perhaps via subproperties) their shared ontology
class
   * My concern that they are being treated differently is implied by the
statement, _...properties in the local namespace that do not exist
in...broader-purpose metadata sets but are related to them by meaning..._

---++++ 3.1.2 Duplicate Properties

   * Same comment as above: there should be no duplicate properties, where
relationships haven't been explicitly declared
      * Maintenance nightmare...
   * Is it possible to have a sameAs sub-property?
      * Meaning, to an application there appears to be two distinct properties
      * but they are in fact the *same* stored field (changing one changes the
other)

---++++ 3.1.3 Resource Typing

   * Interpreting the syntax of a URL is a really bad idea over the long term
   * URLs should be treated as dumb numbers
   * resource types should be explicitly declared in metadata, period
   * This allows the use of other possible locator schemes over time, and
facilitates migration, provisioning, etc.
   * Jason's suggestion (using the RDF-Schema type facility) should addresses
this, but I don't see this from his example (using "rdf:Collection," whose
type presumably has been defined, instead of "rdf:Description"

---++++ 3.2.1 Expression of Qualified Properties

   * Very good point about unqualified-DC clients

---++++ 3.2.3 Usage of Local URIs

   * I agree with Jason's point and recommendation

---++++ 3.2.4 Formatted text

   * Use of HTML would seem to present long-term and immediate
alternative-usage
issues
why not use XML with appropriate XSL?

---++++ 3.3.2 Non-existent States et.al.

   * How are additions, deletions and migrations of properties (including
adoption/application of namespace upgrades) encoded in history?

Hope this is helpful...JSE

| John S. Erickson, Ph.D.
| Hewlett-Packard Labs
| Norwich, Vermont USA
| john.erickson@hp.com

Received on Wednesday, 7 May 2003 11:45:56 UTC