Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] IdAS changes proposal

Title: Re: [higgins-dev] IdAS changes proposal
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" <slyakhov@xxxxxxxxxxxxxx> 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:ptrevithick@xxxxxxxxx>  
 
To: higgins-dev <mailto:higgins-dev@xxxxxxxxxxx>  
 
Cc: Vadym Synakh <mailto:synakh@xxxxxxxxxxxxxx>  ; Paul Trevithick <mailto:paul@xxxxxxxxxxxxx>   ; Igor  Tsinman <mailto:itsinman@xxxxxxxxxxxxx>  
 
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" <slyakhov@xxxxxxxxxxxxxx>  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
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev


Back to the top