| Re: [higgins-dev] IdAS update proposals |
|
>>> Jim Sermersheim 4/16/07 10:14 AM >>> I didn't realize the OWL created this restriction. I'll look at that this afternoon too. >>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 4/16/07 7:46 AM >>> There is one problem which related rather to higgins data model (higgins.owl) then to IdAS API but any solution of this problem may affect the design of update operation. The problem is related to the fact that in the current data model we can have multiple values in simple attributes but it is impossible for complex attributes. For our implementation of jena based context provider this is really important problem because we store context data in owl format. On the other hand even simple attribute could be defined in data model as single valued (we can put cardinality restriction on attribute definition to achieve this) and generally speaking most of attributes I can imagine *must* be defined as single valued. As for me it is confusing that we're trying to represent two different things (single and multi) as a single interface (IAttribute aka IPropetry). So, regardless of how to solve our problem with multiple values in complex attributes it would be much more clear to IdAS consumers if we mutually disjoin multi and single valued things on API level. To disjoin single and multi valued attributes I'd propose make changes to IdAS API like follows: interface IPropertyValue { boolean isSingle(); boolean isComplex(); boolean isList(); URI getType(); } interface ISimpleValue extends IPripertyValue { Object getValue(); void setValue(Object value); } interface IComplexValue extends IPropertyValue, IHasProperties { } interface IValueList extends IPropertyValue { Iterator getValues(); void setValues(Iterator newValues); void addValue(IPropertyValue value); void removeValue(IPropertyValue value); } interface IProperty { IPropertyValue getValue(); void setValue(IPropertyValue value); } Valery Saturday, April 14, 2007, 2:51:10 AM, you wrote: > > > I've added more text to Option 3.a. Where do y'all want me to go > from here? I can start fleshing out the use cases (please tell me > which ones are of interest to you, and/or add your own). Or I could > start mocking up the APIs and generate javadoc. > > > > I'd like to get this moving since I'll be gone next Wed-Fri > > > > Jim >>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/12/07 4:45 PM >>> > > It's definitely not too early to comment on Option 3.a now. The > intent should be clear, I could use some help in exploring what kinds of problems might arise. > > > > jim >>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/12/07 2:53 PM >>> > > So far, I prefer Option 3.a (I should call it the Daniel options > since he planted that particular seed) > > > > I'll flesh out the APIs a bit on the wiki > _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |