Jim,
> I didn't realize the OWL created this
restriction. I'll look at that this afternoon too.
I've expounded our proposals/thoughts (including why
we can not add a few complex values into the same attribute) here:
Thanks,
Sergey Lyakhov
----- Original Message -----
Sent: Monday, April 16, 2007 7:15
PM
Subject: 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
_______________________________________________ higgins-dev mailing
list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev
|