where to go with the 'requirements' note

OK, I prepared the 'requirements' note to try to get feedback on
whether to proceed with it and where to take it.  I've been reflecting
on it.  ( http://www.w3.org/2001/tag/awwsw/ir-axioms/ )

- Most of what I write on the subject seems way too verbose.  I wish I
  could make these documents shorter.

- Maybe having an 'information resource' class is not a requirement.
  It could be simply defined as the domain of the 'has reading'
  relation.

- The main idea is that certain properties (like dc:creator) can be
  applied *both* to things with specific content and metadata
  {representations | simple IRs | fixed resources}, and to
  generalizations over classes of these {non-simple information
  resources | generic resources}, and that you figure out the
  properties of the latter (not directly observable, theoretical)
  based on the properties of the former (directly observable) in the
  way I've suggested.

  How this is expressed is another story.  Originally I though
  dc:creator and friends would apply both to IRs and to
  representations.  That bothered me given TimBL's insistence that
  they're very different species - not only would TimBL resist (and
  I'd like to make something I can persuade him of), but he might be
  right as well.

  So I came up with the 'simple IR' idea, tried it out in this
  document, and now I need feedback on whether it works.

- or, there could be two parallel sets of properties, one for representations
  and one for IRs.  That seems like a horror.

- If we keep the simple IR idea, I'm thinking it might work to say
  "generic resource" and "specific resource" (or "fixed resource"),
  which are closer to TimBL's model.

  These terms have the additional virtue of suggesting the replacement
  of "has reading" by "generalizes" (or in role-noun form "has
  specialization").  This might be better at explaining this
  "information resource" idea to people who continue to have trouble
  accepting it.

- I'm still not sure of the audience; mainly I wanted something for us
  to react against.  One way to limit it would be to construe it as a
  note limited to just explaining the idea of deriving generic
  resource properties from specific resource properties and vice
  versa; and an explanation of how to interpret the idea operationally
  (good practice note?).  That's really the only idea in there, other
  than distinguishing 'bound to' from the inverse of 'refers to' (and
  this is very important too).

Anyhow let me know where you'd like this to go, and I'll do another
round.

Jonathan

Received on Thursday, 3 March 2011 23:54:15 UTC