[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [higgins-dev] Re: IdAS questions
|
+1 to all of Jim's comments and suggestions
> -----Original Message-----
> From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
> Sent: Wednesday, November 01, 2006 10:35 AM
> To: Sergey Lyakhov; higgins-dev@xxxxxxxxxxx
> Cc: 'Igor Tsinman'; 'Vadym Synakh'; 'Evgeniy Vyborov'; 'Maxim Kopeyka';
> 'Sergey Lyakhov'; 'Andrey Slusarenko'; Paul Trevithick
> Subject: [higgins-dev] Re: IdAS questions
>
> Good points Sergey. IMO, the update methods have not yet been very well
> thought out because we haven't had implementation experience yet.
>
> Responses inline
>
> >>> "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> 11/1/06 6:22 AM >>>
> >Hello Jim,
> >
> >There are some questions about IdAS:
> >
> >1. The method Context.createSubject(URI subjectType, Iterable<IAttribute>
> >attributes)
> >requires a list of attributes. Is there any sense to pass a list of
> >attributes to this method? In other words do we always have a set of
> >attributes when we create new DigitalSubject and where we could get
> >them if there is only one method to create an attribute in the IDAS API
> >DigitalSubject.createAttribute()?
>
> I can imagine there being two modes in which DigitalSubjects are created:
> 1) where the IdAS consumer is able to build the attributes itself (perhaps
> using BasicAttribute), and 2) where it needs to use methods from the CP to
> assist in building them.
>
> You're right, we need to both a) allow the attributes parameter to be
> null, and b) provide a method by which the consumer can get an attribute
> for the subject being built.
>
> It seems like what the IdAS user really needs is a way to first get an
> IDigitalSubject instance (which has not yet been added to the context),
> then from that the user can get IAttribute instances which are valid for
> that Digital Subject. Finally, once the Digital Subject has been populated
> with the desired and required attributes, it could be committed/added to
> the context.
>
> The current IContext.createSubject is documented to also add the created
> Digital Subject to the context. I propose we change the doc such that
> this does not happen, and that the user has to call a new addSubject
> method after populating the DigitalSubject. When this was first proposed
> (at a F2F), there was some argument against it. Some felt that this would
> allow any DigitalSubject (possibly from another Context) to be added, and
> that this was undesirable. I don't see there being a way to protect
> against that, and I think the problems that might arise are something the
> CP can deal with.
>
> >2. What is be presumed behavior of
> >IHasAttributes.addAttribute(IAttribute attribute)? Should it create a
> >new Atribute ontology instance and just copy value(s) of passed
> >attribute to the newly created attribute, or it should set passed
> >Attribute as a value? In other words can two DigitalSubjects refers to
> >the same Attribute instance(as an ontology instance)? The same
> >question is for method IHasMetadata.addMetadata(IMetadata metadata)
> >and IHasProperties.addProperty(IProperty property).
>
> I think this question has to be answered by each CP. I don't think
> there's anything in the data model which would prevent two Digital
> Subjects from referring to the same attribute instance (in the ontology),
> so for providers which can benefit from this kind of modeling, it may make
> sense to implement it that way. One note of caution: When two
> DigitalSubjects point at the same attribute instance, modifying that
> attribute for one should probably not modify it for the other. So there
> may be cases where the CP needs to create a new Attribute in order to
> cause a modification to work properly.
>
> I'll try to think of some documentation to add to the IdAS interfaces to
> talk about this issue.
>
> >3. IComplexValue extends IPropertyValue, however
> >IPropertyValue.getData() has no any sense in case of IComplexValue.
> >What should be returned by this method? Should it return
> >Iterable<IProperty>?
>
> I plan to remove this method as soon as we resolve the issue brought up in
> http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg00694.html. For now, I
> suggest returning null.
>
> >4. There are no interfaces ISimpleMetadata and IComplexMetadata in
> >IdAS model looking at higgins ontology model such interfaces should be
> >there.
>
> Well, IMetadata is really just a marker -- it's really just an IProperty
> which produces IPropertyValues which are either ISimpleValue or
> IComplexValue. Do you think this is an adequate analog to the ontology?
> The other solution I see is to make IMetadata exactly like IProperty (and
> add IMetadataValue, IComplexMetadataValue and ISimpleMetadataValue), but
> this would all just be a replica of IProperty and make maintenance harder.
>
>
> Jim
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev