Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Ideas that the modeling 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)

Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.

 

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.

 

 

  File Modified
No files shared here yet.

  • No labels