Re[4]: [higgins-dev] IdAS update proposals

[Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>]

Hi Jim,

See in-line.

-- 
Thanks,

Valery

Thursday, April 19, 2007, 9:51:54 AM, you wrote:

>  
>  
> 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. 

Yes, this is exact intention.

> 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.

As a consumer I'd prefer to know exactly what am I dialing with (i.e.
can I have multiple values or not).

> 2) Having IPropertyValue.isSimple and IPropertyValue.isComplex is
> redundant.  Only one is needed to determine the nature of the property value.

When we have third possibility (i.e. IPropertyValue.isList) this is
not true. To determine that some property value is complex, for
example, it will be necessary to check twice (!isSimple() && !isList()).

> 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.

In the description for IPropertyValue.getType() I wrote that in the case
when isList() return true the value returned by getType() represents
the type of contained items. All contained items will have the same
type and we could define method like IValueList.addValue() without
parameters to create an add new value.

Although, it is possible on API level to have hierarchical structure
of lists, I do not think that it is possible to model
this using our data model and so, this will never happens.


> 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
>  
> }

When isSingleValued return true does it mean that I can't have more
then one value or this particular instance just contains only one?

> 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.

Ok, I agree that it could be another option but it will affect
attribute's definition and we'll need to define something like
ISingleValuedAttribute as well.
As for me it is not right thing to do.

> 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.