| Re: Re[2]: [higgins-dev] IdAS update proposals |
|
On #1 again:
I like where this proposal is going, but I have some questions:
1) It looks like IPropertyValue.isList will return true based on the cardinality in the model. It may be the case for some contexts that the model allows many attributes to hold multiple values, but in practice, they often hold a single value. For example, it may be that a context allows "surname" to be multi-valued, but in 90+% of the cases, "surname" has a single value, and applications don't want to deal with the extra effort involved with enumerating a list. Also, it may be application-specific. Some application might be the only process which updates some attribute, and while it's allowed to add multiple values, it never does. Since that application knows there's never more than one value, it might want an easy way to ask for a value to be returned. This isn't a big worry to me, just pointing it out.
2) Having IPropertyValue.isSimple and IPropertyValue.isComplex is redundant. Only one is needed to determine the nature of the property value.
3) IValueList extends IPropertyValue, thus has a type. Furthermore, it appears to hold a set of IPropertyValues, each of which can have its own type? Not only that, each contained IPropertyValue could return true from isList(). Is this the intent? Plus, each contained IPropertyValue could itself be either simple or complex. It seems like we've added something we didn't mean to here.
What if instead of putting the notion of a property value list at the value level, we left it at the property level, yet added something similar to what you guys have suggested like this (I left out the update op's for now):
Interface IProperty {
URI getType();
Iterator getValues(); // returns an Iterator of one or more IPropertyValue instances. boolean isSingleValued(); // true if can cast to ISingleValueProperty}
Interface ISingleValueProperty extends IProperty {
IPropertyValue getValue();
}
This lets us leave IPropertyValue unchanged. Note that IProperty.getValues() still works when there is only a single value -- but in that case it only has a single element. Anyway, I think this addresses the original problem statement which is that IProperty.getValue() is ambiguous in its meaning.
Jim
>>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 4/18/07 9:23 AM >>> Hi Jim, On #1, a) I agree that it is a little bit different topic but it may affect a way of updates on attribute. b) Don't you think that it is a bit strange to have methods like add/remove on objects which can/must have single value only? c) Actually "isSingle" was a mistype, must be "isSimple". I've updated http://wiki.eclipse.org/index.php/IdAS_Update_Proposals_2 in order to fix c) above and provide some descriptions. On #2, That little box <range> have no relation to multiple value. In RDF <range> defines type(s) of property's value. Every property *definition* could define multiple ranges (i.e. types of value) but each particular property *instance* can only have one range (i.e. instance of value). To understand the problem it is better to take a look at attached diagram if OWL instances (please don't be confused with two first names - I didn't want to change definitions). As you can see in case of single simple attribute firstname has two values Mary and Elisabet. In case of complex attribute postalAddress we rather have two attributes (urn:provo and urn:boston) with single value each then single attribute with two values. Thus, with the current model when we want to add value to complex attribute we will actually create another attribute instead. -- Valery Wednesday, April 18, 2007, 1:26:05 AM, you wrote: > > > Sergey, > > > > I added comments inside the contents of the first issue on that > page. They look like <!-- Jimse: <some comment/question> -->...<!-- > Jimse -->. I'm pretty sure I understand what you're proposing, I just need to make sure. > > > > Paul, On issue #2, is this what we should do to the OWL to fix > things? Also, why does the picture show a little box with the word > <range> in it inbetween the pwa:postalAddress and > pwa:PostalAddress? Isn't that used to allow multiples? > > > > On Issue #3, I agree that we need transactions at some point, but I > disagree with surfacing rollback. I'm going to try and simplify > things again on the other proposal page. > > > > Jim >>>> "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> 4/17/07 9:42 AM >>> > > 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: > > http://wiki.eclipse.org/index.php/IdAS_Update_Proposals_2 > > > > Thanks, > > Sergey Lyakhov > > > ----- Original Message ----- > > From: Jim Sermersheim > > To: higgins-dev@xxxxxxxxxxx > > 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 > |