Talk:Ifd:IfdContext

From dev.ifd-library.org

I am not happy with IfdContext as a subtype of IfdConcept. The context should be used as a filter in queries on the contents of the libraries, therefore an enumaration is more appropriate. The advantage is that defined types can be used as selectors in queries. Kees.Woestenenk

I believe we should keep context as we agreed about on the meeting. Creating an enumeration will require a new schema, new query schema and new WSDL every time a new context is added. Treating it as a IfdConcept has many befits; it can belong to a user or organisation, it can be renamed (e.g. BARBi will most likely not be named BARBi for much longer) It can have descriptions, etc. I also don't think that implementers will have problems using a "class instance" to limit a query rather than a item in a enumeration. I suggest we keep it unchanged. Lars.Bjørkhaug

I am still struggling with this type, because it does not provide the functionality that was intended. Two types of functionality are needed: 1) a means to distinct between defining properties and specifying properties; the proper way to do this is by having an attribute in Relationships which tell whether it is defining or specifying; this attribute should be implemented as an enumaration. 2) a means to select content from the library that originates from one of the participating organizations (e.g. BARBi or LexiCon); the way to do this is through an attribute of Concept telling which organization 'owns' the concept (for common concepts ownership is 'all'). We have talked about an 'owner' attribute, but it is not there yet. If it is there, queries could have an owner-parameter to select on this. I don't see how to have this functionality using Context. Kees Woestenenk