Content model strategy for uncertain types

[dsmith]

Alfresco 5.0.c Community

(To avoid confusion, I'm trying to use capital letters to designate Alfresco terminology vs small case for business terminology)

Our content involves legal documents, whose type isn't always clear.  As a consequence, the type of document that is initially entered may need to be changed (not to more specific child types, but siblings).

I am thinking the best way to model this is to have a single content model Type with all possible metadata.  And have a Property with constraints that corresponds to the document types we want, rather than a separate Type for each.  That way users can easily change the type of document without being locked into the change.  It would come at the cost of empty metadata fields, but there are probably less than 10 possible fields anyway (things like name, date, doc #, etc are shared by most document types).  If I wanted to eliminate that, I could set up Rules to add/remove Aspects when the Type is changed.

I'm wondering if that sounds reasonable, or is there some better solution that would allow users to change the Type?

We're moving at the glacial pace of government toward getting our Alfresco install up and running.  Hopefully I can actually get some sample documents here to start testing before summer comes…

[mrogers]

Your document probably does not change type that's probably a hint that your "Type" hierarchy is not correct.   And if your document does appear to change "type" then that's a hint that you should be using Aspects instead.

The type should be used for fundamental unchanging truth.    If its not helping you and obvious then that's another hint that your model is not correct. 

So perhaps your TYPE is "Legal Document" with name, doc#, whatever DEFINES a Legal Document to you.   Consider what is the difference between say a letter from your bank manager and a "Legal Document"  So no optional fields they can be carefully tacked on later once you know what the essential thing in the type is.

If you have subtypes (and you probably do) then model those as subtypes but remember the definition should be obvious and unambiguous.   (And again probably no optional fields.)   If things appear to "change type" then again that's a bad sign.

If you have non defining or cross cutting features then these become ASPECTS.   You can add aspects as seems fit.   So your "change of type" should probably be due to adding a new aspect to an existing type.     You may even make some aspects mandatory following certain state changes for example you could have an "Signed" aspect that records details of when a document is signed and who did the signing and when along with a set of digital signatures.

[dsmith]

Thank you - I think you're confirming something close to the path I was headed toward.

I could have been clearer regarding "changing type" though.  As example, what I mean to say is that the person who initially enters the document might put it in as a "Deed", but when their metadata entry is verified by a proofreader, the proofreader might pick up on the fact that it's actually a "Sherrif's Deed", which would require the filling out of an additional metadata field.  So the "changing type" is human error, which is unavoidable with the types of legal docs we'll be handling.

So I was debating whether it's proper to model "Deed" and "Sherrif's Deed" as Alfresco Content Types, with required Properties/Aspects or put them both under a broad "Legal Document" Content Type and define their metadata by application of Aspects (via rules or user choice).  It sounds like the latter is the right course of action.