Clifford Heath wrote:
> 
> Ok Hal, I've had a read of your API. I created an ORM model of it
> in fact, using VisioModeler. That's ORM as in Object Role Model.
> The reason I've taken an interest in this is because I believe that
> such a tool can benefit strongly from an aspect-oriented data model,
> more on that later.

Wow, I'm speechless. I didn't expect anyone to pay such close attention.

> Good move not starting on the GUI, but you need to start even further
> back, with a conceptual data model. The API is then a simple consequence
> of the data model.

That may be true, but if the API is a "simple consequence," I would guess
that the data model is pretty heavily specified.

> 
> You have a few bits of mixed terminology or terms used only once.
> For example:
> * I assume that "name" and "title" are the same thing?

Yes.

> * You also use the word "key" - again, is this "title" or
>   is it a path in the data store?

The key is a unique string assigned to each item. It serves as a
literal key into each database table. See the bottom of the file.

> * What's the significance of the "current" topic - is that just a
>   presentation thing or does it affect searching? No other function
>   seems to indicate that the current topic is relevant.

I'm undecided on that issue. It certainly affects presentation, but
it's not obvious to me whether the notion of a "current" topic makes
certain operations easier. I *think* it does.

> * What's the effect of "load"ing a topic of note?

Did you mean "topic OR note"? A "load" simply references all the tables
needed to get the "pieces" of an object, then assembles them into a
"real" Ruby object (of class Note or Topic) and returns it.

> Functionality questions:
> * When you change the root topic of an app, what happens to all the
>   now unreachable topics and notes? Is the change persistent? Perhaps
>   you could replace this problematic operation with a simple "flip
>   parent and child" operation?

That's also unclear to me at this time. I was thinking along the lines
of a Unix "chroot" operation -- "pretend" that this subset of the tree
is the whole tree for now. Not sure this concept is useful.

> * It isn't clear whether find_topic searches content or just titles.

In the "simple" form it searches only titles. In the block form, you can
access any or all content or metadata for purposes of searching, but you
do it explicitly (by analogy with Enumerable#find).

> * It seems that topics and notes differ only in that notes have content,
>   which requires a different presentation, and in whether the metadata
>   inherits 

That may be true, but it hurts my head to think of the terminal and non-
terminal nodes as being the same thing. It's a very CS approach, of course,
but it doesn't fit my mental model.

 > (BTW, this isn't inheritance I believe, but propagation down
>   the tree - is that right?).

I'm not sure what you mean. There are probably good reasons not to call it
inheritance. But it's not simple cascading, i.e. doesn't affect siblings.

>   Why bother with the two things - instead you could simply load all
>   items having no content as your tree.

Probably is doable, but again, doesn't fit the way I think.

> Aspect orientation suggestion:
> Your model has a number of different kinds of data value associated
> with each note or topic. For example, you have info on date/time and
> number of times accessed, modified, etc. You have GUI variables. You
> have sorting and searching (keywords).
> 
> If you regard each item (topic/note) as having values for variables,
> you can model the variables as pertaining to a relevant (meta-)topic.
> So for example, you could have a Presentation topic, which contains a
> Note sub-topic. The variables whose values define the presentation of
> a note "belong" to the Note class, but "pertain" to the
> Presentation/Note subtopic. I also allow Items to pertain to other
> items.

It sounds like you're talking about multiple "views" of the data, is
that correct?

> In this way you provide for an arbitrary number of kinds of metadata,
> while the model actually has very little actual *meta*data. The only
> metadata you need is the "Item" class(es) and the Variable class(es).
> 
> Item has a title string, a parent Item, a superclass Item (e.g. Topic,
> Note), an Item to which it "pertains" (which will often be its parent),
> subitems, optional Variables, and optional values (for its variables
> and for inherited ones).
> 
> Variable is also an item (each has the same), but its subclasses define
> sub-Variables, for example "max-length" for a string, etc.

I'm halfway following this, though it's confusing. How would you
propose to store all this?

> The API should allow fetching all values (including inherited and
> propagated) of an item which *pertain to* the aspect of interest. So
> for example the GUI will fetch values of all variables of items which
> pertain to the Presentation topic. The searcher will fetch values of
> different variables, and the object manager will access and update
> values pertaining to access and modification times and counts. You can
> also store user information (values for an item, and subitems) into
> multiple aspects in the same way. It creates some interesting search
> algorithms, but is a very powerful way to separate different kinds of
> data and metadata.

It does sound powerful, but I wonder 1) would it require a full-fledged
database? and 2) wouldn't it require an awful lot of disk access to
store things in a "scattered" format?


Thanks much,

Hal