Modelling team sandbox
Ideas that the modelling are thinking about and discussing
Standard Properties (to be reused in a consistent way):
- Label
- Description
- Definition
- Language (for non-textual objects)
- Comments (internal)
- Notes (public)
LS-41 - Getting issue details... STATUS
Need to ensure that objects are not just empty shells, and actually have properties.
Also when adding a property which holds the main "value" of an object, particularly if the datatype of that property is xs:string the property should be called "content".
For example, Text.content of type xs:string.
Identification issues:
- Identifiable objects are identifiable by agency, id, and version. This identifier is universally unique. Sometimes, the id alone is universally unique – there is an extra field in AnnotatedIdentifiable to document this.
- AnnotatedIdentifiable: Within a given context you can define a localId and a localVersion. Example: in the context of a dataset, a variable name is unique and is therefore a localId.
Modelling nested collections (added by Flavio)
The new collection structure has a container (Collection) and members (Member). In order to allow for nested collections without resorting to multiple inheritance, we have to make Member a subclass of Collection. That has implications in cases like Node and NodeSet, since it will make Node a Collection too. To address the issue, there is a constraint defined on the subclass relationship between Member and Collection: If isCollection = true then Member is a subclass of Collection, otherwise it is not. The default is false. The following diagram illustrates the model:
Modelling correspondences/maps (added by Flavio)
We have two different ways of modelling correspondences at the member level. A correspondence between members is a set containing all members that map to each other, i.e. they are equivalent of similar. In such a generic representation there is no order between members. However, order might be needed in some cases, e.g. GSIM Map has a source and a target. There are two ways to introduce order in this scenario. The first one is by making the MemberCorrespondence object a subtype of Collection, in which case we could define precedence as an order relation, as shown in the following diagram:
The second option is to create a subtype of MemberCorrespondence to deal with order, as shown in the following diagram:
We need to decide which one to use.
