| [higgins-dev] Re: Re[2]: IdAS questions |
|
I've tried the new methods and like them.
Duane
>>>
No responses, so I checked in some changes to IContext so we can see if we like it. Refer to http://www.eclipse.org/higgins/org.eclipse.higgins.docs/idas/org/eclipse/higgins/idas/IContext.html
There are 4 overloaded createContext methods (all can be implemented by the CP by calling one). These return the created (and optionally added )IDigitalSubject instance which can be later added (if it wasn't already)
If we like this pattern, I'll refactor the other methods (listed below) where it makes sense to match.
Jim
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 11/2/06 6:10 PM >>> So far, we have been putting these types of methods on the "container". For example, one uses an IDigitalSubject to produce IAttributeInstances.
One benefit of doing it this way is that an IDigitalSubject instance can know exactly which types of attributes may be used for it. Similarly, one problem with asking the IContext instance to manufacture an IAttribute instance is where the IContext requires knowledge of the type of DigitalSubject to which the attribute will be applied before it's able to create it.
As things stand today, the "factory" methods are as follows:
IContext produced by IContextFactory.createContext
IDigitalSubject produced by IContext.createSubject (with problems described in this thread)
IAttribute produced by IDigitalSubject.createAttribute
IProperty for complex values produced by IComplexValue.createProperty
IMetadata for context factories produced by IContextFactory.createMetadata (do we need this?) IMetadata for contexts (planning on removing this) produced by IContext.createMetadataIMetadata for relationships produced by IRelationship<T>.createMetadata
IMetadata for DS's produced by IDigitalSubject.createMetadata
IMetadata for attributes produced by IAttribute.createMetadata
IRelationship<T> produced by IContext.createRelationship
IFilter produced by IContext.createFilter
Various filter assertions produced by various IFilter.Create<somekindof>Assertion
There are no methods yet for creating property/attribute/metadata values. >>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 11/2/06 8:25 AM >>> Hi Jim, It seems to me that we have to provide factory methods to create properties, attributes, metadatas and their values on API level (perhaps on context level). -- Thanks, Valery Wednesday, November 1, 2006, 5:35:08 PM, you wrote: > 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 |