Canonical Form for Content Hierarchies

I am still pondering the question how exactly a content hierarchy should be modeled.

In a previous post I mention the possibility to declare authorization facts in a hierarchy. Something is still bugging me. Similar to programming, I think that some informations should be considered as cross-cutting concerns (or aspects). David's Model also has an example where authorization decisions have an impact on the model. This bugs me.

Somewhere there lurks the definition of a canonical representation of a content hierarchy:

"
basic, canonic, canonical: reduced to the simplest and most significant form possible without loss of generality, e.g. "a basic story line"; "a canonical syllable pattern"
..."

This does sound right, doesn't it? A basic form of a content hierarchy should

1. have the ideal relation of breadth vs. depth (ideal for the content model)
   
2. only have the necessary node hierarchies/attributes
   
3. still make sense

Those are non-mathematical requirements. The definition of a "Canonical Form" is interesting: while defining a canonical form via equivalency of a range of objects, it remains unspecific about how and when to define a canonical form:

"...
A canonical form may simply be a convention, or a deep theorem.
..."

The most important part is that other content hierarchies which are equivalent to this normal form are all connectible via an equivalence relation.

So the task at hand is to define a model which can act as a natural representation of the solution domain. As soon as this model is found, enhancements can be defined, while still being equivalent to the canonical form.

Well, still lots of questions open:

• is it possible to define a canonical form for a specific use case (e.g. a blog)? Or would it be on an ad-hoc base?
• what would the added benefit of such a canonical form be? The answer might be that extensions would be made vs. the canonical form. If the canonical form itself changes, it should trigger the changes to the other forms. Or at least depict the consequences the change in the canonical form has to equivalent representations
  

There might be another alternative to attack the problem of "hierarchy purpose overloading": as in programming, cross-cutting concerns might best be attacked by Orthogonalization. But this is another story ...

Builder and DSLs

Naive Question:

If builders allow to define DSLs, and DSL are languages, what is best practise for defining the grammar of this languages?

Or even more naively: when to use verbs, when to use nouns?

E.g.:

goToComputer(){
 startUp() {
   login(username:'user', passwort:'password')
 }
 startProgram(name:'thunderbird') {
   readMails()
 }
}

vs.

computer(action: 'goto'){
 computer(action: 'startup') {
   loginscreen(action: 'enter username', username: 'user')
   loginscreen(action: 'enter password', username: 'password')
   loginscreen(action: 'enter')
 }
 computer(action: 'startProgram') {
 }
}

and so on. Of course, it is obvious that the later one is more verbose and needs a convention for the attributes (like "action attribute describes function to execute").

Maybe the best compromise is to use a way to differentiate between verbs and nouns, e.g. write nouns in uppercase.

A related question:

How should the syntax of a DSL be described?

For XML we have schemas, is there need for something like that for DSL? And if yes, how to describe it? BNF seems to be a choice, but when exactly is it needed? Is it overkill? Does it scale?

The reason for such unreflected questions: on the one hand the description of SwingBuilder, on the other hand the longish BNF description of JCR node types. With both I get the feeling that not much more is possible...

From OR to CR modeling - Hierarchies

So in the previous post, I started to think about data models in a Content Repository and the differences between relational models and, well, what?

But first a disclaimer: I am no big content repository expert. So expect me to do some classic mistakes, and ask some rather naive questions.

Here be one:

Is a hierarchy imperative to content modeling with JCR?

My thought is that hierarchical modeling feels natural in JCR. The hierarchical structure is instrinsic to structures with nodes, parents and children. So the next question would be

How do you map the hierarchies of an existing relational model to a hierarchical one?

We have the classical example once again

class Author {
 static hasMany = [ books : Book ]
 String name
}
class Book {
 static belongsTo = [author:Author]
 String title
}

which maps naturally to

/authors
/stephen king
     /books
         /Misery

But what if there is another hierarchy, e.g.

class Author {
 static hasMany = [ books : Book ]
 String name
}
class Book {
 static belongsTo = [author:Author, category: Category]
 String title
}

class Category {
 static hasMany = [ books : Book ]
}

Now the books suddenly are part of 2 hierarchies. How to model this? I currently see 2 possibilities

1. Have one leading hierarchy
2. Flat it out

/authors
 /stephen king
      /books
          /Misery
/categories
 /Thriller
      /Misery*

vs

/authors
 /stephen king
      /books
          /Misery*
/categories
 /Thriller
      /books
          /Misery*
/books
 /Misery

(the * depicts a relation to a Node elsewhere)

Another solution would be to allow multiple dimensions, in which the objects can be stored (this is more or less the same as the "flat out" version, except that looking at the object always gives you the "real" one, and not the relation.

As I said, I am not an expert of data modeling.

Feel free to comment on it...

Ok, next post will be about Groovy/Grails again :) (yeah, with a dash of JCR in it)

Transition from ORM to JCR modeling

I am currently thinking about using JCR as a Backend for Grails (or more generally Groovy). Graeme Rocher has made some great steps in creating a Grails plugin.

GORM is imho one of the best possibilities to define an ORM model, since it hides all technical aspects of the implementation and lets the developer describe the domain model in a clear an consistent way.

Therefore this clearness should still be around when using JCR as backend.

Take an Grails/GORM example:

class Author {
   static hasMany = [ books : Book ]
   String name
}
class Book {
   static belongsTo = [author:Author]
   String title
}

The dynamical nature of Grails adds the necessary properties, you could also write it as

class Author {
   static hasMany = [ books : Book ]
   String name
   Set books
}
class Book {
   static belongsTo = [author:Author]
   Author author
   String title
}

There are 2 aspects to this domain model

1. object relations: an author has a set of books
   
2. constraints: you have to make sure that a book really has an author (except when you define this property as nullable, which is also a contraint in this sense)

This simple domain model has got an interessting implication when mapping it to a repository:

1. the one-to-many relation author vs. books would typically be mapped by a hierarchical manner, e.g.
   

   
   /authors
       /stephen king
            /books
                /Misery
   

   
   etc.
   
2. the constraints, on the other hand would mean to add a structure to the repository by, e.g., defining node types. I think, that's what David means. Might be nice to have (I personally don't mind structure), but is not mandatory
   

Conclusion? I think what can be said is that thinking "data first" might lead to an ever more relaxed approach of defining domain models than Grails/GORM already has today ....