Sergey, Since you, Valery and perhaps others think that having a model API would be much more convenient to use than directly navigating the entities/attributes, let¹s keep the IModel interface (and related interfaces). But must align them with the underlying entities & attributes as described here [1]. I¹ve updated [1] recently thus creating some mismatches. Please review [1] and let me know if anything is unclear as to what the semantics are supposed to be.
[BTW, I¹m aware that the concept of display order is missing from [1] and it probably needs to be added. I¹m thinking that it should be added as an attribute of a ³class-scoped attribute class²]. --Paul [1] http://wiki.eclipse.org/Higgins_Data_Model_1.1#Representation_of_Entity_and_ Attribute_Classes On 10/21/09 10:17 AM, "Sergey Lyakhov" <[email protected]> wrote: > Paul, > >> > What Jim and all of us talked about several months ago is to remove the >> special IModel interfaces completely, >> > and just use the existing entities and attributes to describe entity >> classes and attribute definitions. In other words, recurse. > > The main Jim's argument to rid IModel interfaces was to reuse alredy existent > IEntity and IAttribute inerfaces. Actually, I already gave arguments a year > ago, why the current model interfaces are more convenient: > > 1. The current model interfaces allow to represent many things obviously. > Suppose, we need to expose the model of a simple value. If we used Jim's > model, we'd represent simple value model via IEntity intrerface (which is > confusing by itself). Than, to represent params of this simple value (there > are many things in OWL1.1 like length, minLength, maxLength, pattern, etc.), > this IEntity should contain an attribute for each of those params. In turn, > the attribute should contain some ISimpleAttrValue with data of its parameter. > From the other hand, the current IModel interface can reflect OWL in a more > convenient way. If we need params of some simple value, we get an instance of > ISimpleValueModel (either from IAttributeModel or from ISimpleAttrValue), and > invoke its methods getLength(), getMinLength(), getMaxLength() etc. > > 2. IdAS interfaces (IEntity, IAttribute) have a lot of methods behind of > getType() and getData() which are not used in Jim's model. I suppose these > methods will confuse people which need to use a model. > > 3. Jim's model is flexible and could represent anything, but we do not need > this, because we limited by OWL and need to describe things which OWL > provides. IModel, in turn, could be disigned to reflect OWL constructs handy. > > Thanks, > Sergey Lyakhov >> >> ----- Original Message ----- >> >> From: Paul Trevithick <mailto:[email protected]> >> >> To: higgins-dev <mailto:[email protected]> >> >> Cc: Vadym Synakh <mailto:[email protected]> ; Paul Trevithick >> <mailto:[email protected]> ; Igor Tsinman <mailto:[email protected]> >> >> Sent: Monday, October 19, 2009 10:55 PM >> >> Subject: Re: [higgins-dev] IdAS changes proposal >> >> >> What Jim and all of us talked about several months ago is to remove the >> special IModel interfaces completely, and just use the existing entities and >> attributes to describe entity classes and attribute definitions. In other >> words, recurse. >> >> On 10/16/09 11:49 AM, "Sergey Lyakhov" <[email protected]> wrote: >> >>> >>>> > 1. We define a new .api2 that replaces the IFilter stuff with SPARQL. >>> <snip>... replaces IModel interfaces with something you were going to >>> propose. >>> >>> >>> >> >> >> >> >> >> >> _______________________________________________ >> higgins-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/higgins-dev >>
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
