Re: [higgins-dev] IdAS: Model as Metadata

[Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>]

Hi Jim,

I see one problem with intention to represent interfaces in .model
package using metadata.

As you mentioned, metadata is a data that describes another data but I
have to notice that actually they describes data instances while
interfaces in the .model package describes data structures
(definitions).

-- 
Thanks,

Valery

Saturday, June 2, 2007, 3:21:26 AM, you wrote:

>  
>  
> Thinking out loud here -- I mentioned this on the last dev call.
>  
>  
>  
> I believe IdAS consumers need the ability to make updates to
> aspects of a context's model (i.e. add a new subject type, or add a new attribute type).
>  
>  
>  
> So to do that, we would naturally start introducing a bunch of add*
> methods to the model interfaces like we did for context and its
> sub-elements.  This starts feeling like a duplication of similar
> methods, so I started wondering if there's a simpler way.
>  
>  
>  
> What if we decided to remove the interfaces in
> org.eclipse.higgins.idas.api.model, and instead define some metadata
> types that can be used to represent model elements?  If we could
> make this work, I would prefer it for a few reasons:
>  
> 1) It reduces the number of interfaces we have,
>  
> 2) I think the model of an element is a good example of metadata
> (it truly is data that describes the data),
>  
> 3) It makes us start using metadata -- helping to prove out the design.
>  
>  
>  
> The problems I see with doing it:
>  
> P1) Metadata is too simple: Today, metadata is always single-valued
> and a simple type. So if we wanted an IContext to have metadata for
> the digital subject models it supports, we would have to basically
> have one huge string value.  This makes updates very unfriendly.  We
> would want to allow metadata to be multi-valued such that we could
> have a metadata element with a type of
> "http://...#DigitalSubjectModel"; and multiple values where each
> value represents a supported digital subject model.  Furthermore, it
> would be good if each digital subject model were complex such that a
> specific sub-element could be updated (i.e. so one could add to the
> list of attributes valid for that subject).  I know... we just got
> done making metadata simple and single-valued, and now I'm proposing to change it back.
>  
> P2) Lack of functional methods in metadata: like
> IAttributeSimpleValueModel::toLexicalForm(Object).  I'm not sure if
> this is a real problem or if these methods were just for convenience.
>  
>  
>  
> As much as I hate re-visiting P1 so soon after refactoring
> metadata, I wonder if we were too hasty is assuming metadata will
> always be simple and single valued -- and if so, now would be a good
> time to change since not to many (if any) people are using it yet.
>  
>  
>  
> Duane is gone for a couple weeks, but in talking to him yesterday
> about this, he agreed in switching from the I*Model interfaces to using metadata.
>  
>  
>  
> Let me know what you all think.
>  
>  
>  
> Jim

>