[Ore-acceleration] my comments on the data model doc

[Michael Nelson]

posted in the blog as a comment, but reproduced here for convenience.  3
copy edits, 1 significant issue:

* Section 2:

  -  Representation - A data stream corresponding to the state of a
  resource at the time of a dereference of its protocol-based URI.
  The web architecture allows for multiple representations of a resource
  with access mediated by content negotiation. This specification does not
  employ content negotiation, and rather mandates a single representation
  of the resources described in the data model.

MLN:  I know we're trying to avoid a forward reference here, but its
really only the ReM (and CORes) for which we're mandating a single
representation.  The ORe's are defined in this data model and they could
use CN.

But there is a bigger issue here.  At the risk of being overly pedantic,
the "single representation" requirement appears to be at a much lower
level than I would expect at a data model document.  Looking into the
future, it would preclude:

  1.  multiple serializations
  2.  CN on encoding types (.gz, .Z) and language (.en, .fr).
  3.  redirections of any type (301/302/303) -- technically, they
      return 0 representations

We'd like to enforce #1 for the time being (but probably not forever).
Case #2 is admittedly not a constraint in practice, but from a model
perspective there is no reason to constrain the web architecture from
doing what it is meant to do.  Case #3 prevents SW 303-style redirection,
but it also prevents the use of registries and other http tricks.

What we really want to prevent is http://odu.edu/resource/michael
redirecting to either HTML or ReM/Atom based on who is asking.  As such,
we should really constrain URI-R.  Informally, we want to prevent
overloading / reusing of URIs, so we can unambiguously refer to the ReM.
Formally, we might want to say something like:

"When dereferenced, URI-R MUST never return anything other than a ReMDoc."

That leaves the door open for multiple serializaations in the future,
provides some http utility, but would still prevent the ambiguity we don't
want.  I'd simply take out all the discussion about representations.

(Similarly for CORes...)

* Section 3.2:

  (e.g., in the context of scholarly objects, a communication to the ReM).

MLN: a "communication to the ReM"?  I don't understand -- a "citation"
maybe?

* Section 5.1.2:

  ReM-M MAY include additional properties about the the ReMDoc. or the CO.

MLN:  Residual "CO" terminology.

* Section 5.2:

   A manifest, therefore, MUST list the URI-C of every CoRe of the CO.

MLN:  Residual "CO" terminology.



----
Michael L. Nelson mln at cs.odu.edu http://www.cs.odu.edu/~mln/
Dept of Computer Science, Old Dominion University, Norfolk VA 23529
+1 757 683 6393 +1 757 683 4900 (f)