Ifd:Third LexiCon-BARBi Unification workshop

API
Look at all comments attached to each method. These are valid issues we need to consider going forward.

Specification vs Definition
We need somehow to tag the relationship between, for example, a concept and its property, and say whether it i specifies or defines. One possible, but not optimal solution, is to use Context and have for example two contexts: "LexiCon Specialization" and "LexiCon Definition", however, it is desirable to have an enumeration type of style, to avoid a source of errors. It is also desirable to have it independent of library (which context in a sense is).

IfdConceptTypeEnum
See Kees comment of 2007-01-25 (need for abstract types).

IfdOrganization and IfdUser
Why not use what is in the IFC model for this?

IfdValue
This causes problems for LexiCon as it stands today. We need to resolve this. Suggest to document the LexiCon idea and BARBi idea and see if there is a difference.

IfdValueRoleEnum
Really necessary?

IfdValueTypeEnum
Minor issue: Could we have "NUMBER" as well?

IfdConceptInRelationship
Would like to have relationship itself as an object in the API data model, with one to one connection (not one to many). Should consider if we should change the IfdConceptInRelationship to a real relationship, and how to solve this properly. Do not give users more flexibility, but add power. Avoid ambiguity.

IfdContext
There is a need for a mechanism, similar to IfdContext, but where the user do not choose what to filter on. In that way, enumeration is safer and better. Perhaps we can have a few enumerated contexts and one "userdefined" that can be expanded dynamically?

IfdName
How do we know which concept the name is preferred for? The is_Preferred is attached to the xtdLanguageRepresentation...

Enumerations
Enumeration types depend on the user of the API entering the correct strings. This should be a true enumerationtype, to avoid the use of a client side wrapper. However, the problem seems to be with the WSDL (SOAP) standard itself.