Skip to main content

[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





Back to the top