| Re[2]: [higgins-dev] IdAS update proposals |
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 >
Attachment:
person-with-address.png
Description: PNG image
