Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] IdAS: Changes and more changes to the getType/getID methods

To fix https://bugs.eclipse.org/bugs/show_bug.cgi?id=190593, I somewhat settled on renaming methods to look like get<Something>Type().  For IAttribute, I renamed getAttrID() to getAttrType().  For attribute values, I renamed from getType() to getDataType(), IMetadata now has getMetadataType().


It has come to my attention that this is now more confusing than it originally was, so I plan to take another stab at it.  Many IdAS elements have both an identifier as well as a type.  Here's what I'm thinking (see summary at the bottom):


Starting with IContext. It has an identifier and maybe a type.  The identifier distinguishes this context from other contexts, and the type helps describe what this context is capable of.  The identifier is a URI which is currently accessed by calling IContext.getContextRef().  I propose we rename this to IContext.getContextID() (Note that this may be confusing as we already have an IContextID which contains other things).  An IContext's type has not been formally discussed in the context of the IdAS api's yet.  One can call IContext.getContextModel.getType(), but I don't know what the behavior is supposed to be.  I suppose it should be like one of the URI's which will someday be placed here http://wiki.eclipse.org/ContextTypes.  I'm not sure if we need a shortcut like IContext.getType().


IDigitalSubject has an identifier and a type.  The identifier sets the subject apart from other subjects in the context.  The type helps describe the possible characteristics of the subject.  The identifier is a String.  There are two ways of getting this value: IDigitalSubject.getSubjectID() or IDigitalSubject.getAttribute("http://www.eclipse.org/higgins/ontologies/2006/higgins#uniqueIdentifier").getValues().next().  I think the value of retaining this shortcut outweighs the value of reducing superfluous methods.  The type is a URI which can be accessed by either: IDigitalSubject.getSubjectType() or IDigitalSubject.getModel().getType().  I don't think the value of the shortcut (IDigitalSubject.getSubjectType()) outweighs the value of reducing superfluous methods, so I propose we remove it.


IContextRelationship only has a type presently.  The type can be accessed by IContextRelationship.getType().  There is no accessor for an IContextRelationship's model.  This might warrant another discussion thread.  I'm not sure anyone has practical experience with these yet.


IAttribute is where confusion begins.  There is definitely something that distinguishes an attribute from other attributes in a set of attributes (a set of attributes might be a digital subject, or even a complex attribute). This distinguishing identifier is a URI and might look like this:http://www.example.org/ontologies/2007/examplenamespace#hatsize.  At the same time, this identifier is also used to help describe the capabilities of the attribute.  In other words, it is the same URI returned from IAttribute.getModel.getType().  Thus it's seen at some times like an identifier, and at other times like a type.  I don't want to propose fabricating the notion of an attribute identifier which is different from the type simply for the sake of symmetry.  One proposal would be to allow two methods: IAttribute.getAttrID() and IAttribute.getModel().getType() to both return the same value.   The more I think about it, the more I like this proposal.


IAttributeValue has no identifier per-se.  One could think of the data that makes up each IAttributeValue as being its identifier, because each value's data sets it apart from other values within the containing IAttribute.  It does have type associated with it which is used to constrain its data.  This is gotten by calling IAttributeValue.getDataType() or IAttributeValue.getModel().getType().  I don't think the shortcut (IAttributeValue.getDataType()) is all that helpful here and propose we remove it.


IMetadata* is going to be refactored to basically look just like IAttribute*, so those can follow whatever we do for IAttribute*


Summary of proposals:

* Rename IContext.getContextRef() to IContext.getContextID()

* Remove IDigitalSubject.getSubjectType() as it is superfluous (use IDigitalSubject.getModel().getType() instead)

* Rename IAttribute.getAttrType() to IAttribute.getAttrID().  Document the dual nature of the URI returned from this and why it's useful to present it as both the attribute's identifier as well as its type.

* Remove IAttributeValue.getType() as it is superfluous (use IAttributeValue.getModel().getType() instead)


Further, I propose that we only deprecate the methods to be removed with a statement as to when they will actually be deleted from the interfaces.


Jim


Back to the top