This schema defines the "vo-dml meta model", a modeling language used to define the concepts and structures that describe data models. It is proposed as the common language for defining data models in the IVOA. It aims to represent the UML profile defined ... [TBD ref to magicdraw uml profile]. The approach was inspired by Laurent Bourges' .._FOR_GEN.xml file generated for use by Java code in ...[TBD ref?]. The current version is a successor to the "intermediate representation" embodied in intermediateModel.xsd originally used in VO-URP and especially in the Simulation Data Model effort. There this language was used as the schema for documents generated from the XMI in the first step in the code generation pipeline. This representation of data models is much more explicit than XMI and reduces the number of modeling concepts, which greatly eases the writing of post-processing XSLT scripts. If could relatively easily be written by hand just as an XML schema, or generated any other way [TBD example SimTAP?]. The current version aims to be more formal than its predeccessor, its main goal is to allow a clean data model definition, that allows reuse, mapping, referencing through UTYPEs etc. It adds some new features such as model import, tightens the definition of some others such as TypeRef. Some features that were included in intermediateModel.xsd for ease of processing (such as referrers, an embedded Profile) have been left out, or have been replaced with a better definition (such as container) remain as they may be be explicitly included in natural representations and hence may need to be an explicit target for use in referencing by UTYPEs for example. This version of the schema goes all out in attempting to use utype truly as data model element identifiers. For this to work and put no particular constraints on UTYPE format, we cannot use a utype as an ID. Instead we use them as a key. Advantage of this usage is that referencing remote and local elements can all be done in same way, using a "utyperef", which then may have to be a kkeyref. Note that in that case the remote element MUST be included explicitly in the model, otherwise it can not be referred to. But in that case the ID mechanism may be used again... Look at SVN versions 2129 and earlier for more extensive model. Type representing the way referencable elements are identified uniquely in VO-DML. TBD We could use an xsd:NCName where ElementID is used, but that may have somewhat more sever syntax constraints than desired. A restriction on the valid strings that make this a VO-DML Identifier. Requirements on the format are: 1) use in XML document 2) use as fragment in URI TODO define the restriction. Type used to restrict valid values for prefixes. TBD We could use an xsd:NCName for this. A prefix MUST NOT contain a semicolon. Class representing the way ReferencableElements can be referenced in VO-DML. It must be possible to refer to elements in other, imported data models as well as in the current model. Hence the UTYPE must identify both model and element. The element is identified by the VO-DML ID in the model, the model is identified using a prefix that MUST correspond to the prefix element of the current or an imported model. Note, references to element sin the current model MUST also have a prefix, there is no default model! TBD We could use an xsd:QName where UTYPE is used, but that may have somewhat more sever syntax constraints than desired. A restriction on the valid strings that make this a valid reference to a referencable element. Consists of a prefix that should follow the MOdelPrefix restriction and a identifier that should follow the ElementID restriction, separated from each other by a colon. TODO define the restriction pattern properly. MUST be [Prefix ':' VODMLID]. This is the base type for all types whose elements can be explicitly referenced. To this end it has a 'utype' element of type UTYPE that allows explicit and unique identification of these elements. Generally these are also elements that can be represented explicitly in alternative serialisations of a data model, such as a VOTable or a relational model. These should use the value of the utype element to "point into a data model" and identify a model element. VO-DML itself also has needs of pointing to other elements, sometimes in another model. The UTYPEref type is used for such references, which will always be named .utyperef'. Identifier for the containing element. Extracted as a separate type so that we can easily adapt to a different identifier design. The name of the model element. May be restricted with uniqueness constraints in subclasses. Human readable description of the model element. A referencable element may be given an @id attribute to reflect an identifier defined in some source document form which a VO-DML model may have been derived. This type represents how to reference a ReferencableElement. It can serve as base class to those types that explicitly reference another type, such as relations and roles. It provides for a uniform way to represent the reference to the target element using the 'utyperef' element. An important design choice is that we wish to allow references to elements in remote models. For that reasons we can not use an ID/IDREF or key/keyref pattern. Instead we define various constraints on this type and its usage in various contexts using the Schematron file in vo-dml.sch.xml. The element identifying the referenced target element. See the documentation for the UTYPE type. Represents a complete data model and is the type of the (single) declared root element for VO-DML/XML representation documents. Short name of the model. NOTE this name MUST be used as prefix in any utype reference to elements in this model. The description of the model. The title of the model by which it is officially known. List of authors of the model, only defined by name so far. TBD could be expanded with email, affiliation and so on. Label giving the version of the model. URI identifying a VO-DML model that is the version from which the current version of model is derived. TBD could be an IVO Identifier once models get properly registered? Timestamp when the last change to the current model was made. An 'import' element indicates a dependency on an external, predefined VO-DML data model. Types from that model may be used for referencing, extension and assignment to attributes. Types from the external model MUST NOT be used for composition relationships. 'identification' relations to elements from that model may be used to indicate some kind of equivalence between elements in the current model and the external elements. TBD We might require that every data model MUST include a version of the IVOA data model to gain access to the standard primitive types and some other types. We may require that that standard model should be included *completely*, i.e. including all its type definitions explicitly. This would be similar to treating it as a UML Profile, rather than an import. This would mean that the most common type assignments for attributes can be checked within the model and not require importing the remote model during validation. The collection of packages which can contain further detailed name spacing to the type definitions in the model. Collection of ObjectType definitions directly under the model, i.e. not contained in a Package. Collection of DataType definitions directly under the model, i.e. not contained in a Package. Collection of Enumeration definitions directly under the model, i.e. not contained in a Package. Collection of PrimitiveType definitions directly under the model, i.e. not contained in a Package. A "proxy" for an external model. Represents another model that is used by the current model. Defines the url where the VO-DML representation of that model can be retrieved, and a prefix that MUST be used when making references to elements in that model using a UTYPEref element. Name by which imported model is used in the current model and its documentation. This name MUST be the same as the 'name' of the model definition in that remote document. For all utypes pointing to elements in the imported model MUST use this name as prefix. IVO Identifier of the imported model if that exists, i.e. if that has been registered in an IVOA Registry. URL from which the VO-DML model document can be downloaded. Note, could likely be done through a registry once ivoId is known. TBD SHOULD this be a generic URI, or can we insits on URL? URL where a documentation HTML file for the remote model can be downloaded. This SHOULD be a document that contains anchors for each element thta has as name attribute the vodml-id of that element. I.e. it is assumed that the vodml-id-s of the imported types can be added onto this documentationURL (should end with a #?) so that a direct link to the documentation for a referenced data model element can be found. A Package is a container for type definitions and possible (child-)packages. Names of types only need to be unique within their container (model or package), hence a package provides further name-spacing for type definitions. When deriving physical representations of a model, packages may be mapped to containers in the target meta-model. For example in mapping to XSD they may give rise to separate documents with type definitions and their own targetNamespace. When generating Java classes they may be used to define seprate packages for the classes derived form the types. Name of the package is constrained in that there can only be one package with a given name in the container in which the package is defined, i.e. the model or a parent package. TBD we may wish to extend this rule to all children defined in a container, including types. Collection of ObjectType-s defined in this package. Collection of DataType-s defined in this package. Collection of Enumeration-s defined in this package. Collection of PrimitiveType-s defined in this package. Collection of child Package-s defined in this package. Base class of all type definition elements. All Type-s extend ReferenceableElement, i.e. they are referencable. Adds name, description, inheritance and indication of abstractness to ReferencableElement. Name of the type. Must be unique in the collection of all types in a given container (i.e. model or package) Reference to a type (called the base-type) that is extended by the current type (called the subtype). This implements the typical is-a inheritance relationship, similar to the extends relations in XSD and Java, the generaliation in UML, or the subclassOf relation in RDF. Note, VO-DML does not support multiple inheritance. Instances of a subtype are automatic instances of a base type. Polymorphism is assumed: When a role (see below) defines a base type as its datatype, instances of any subtype can be uased as value of the role. Roles defined on a base type are inherited by the subtypes. Relations inherited from a basetype can be 'subsetted', which is similar to overriding their definition. See the definiton of this property on the Relation type. TBD improve next description; make it less obscure; refer to ... "A type with an identity". This in contrast to value types where the value identifies the instance. Could be called Class to correspond closer to UML counterpart, though ObjectType is somewhat more explicitl. Using Class causes some problems in usage as it is often a reserved keyword. TBD should we include an explicit id attribute. Simplieifes it being referenced with UTYPE-s, but somewhat complex how to define minOccirs rule. Should for each concrete class have exactly one in extension hierarchy. TBD do we need this? NOT if we use vo-dml:ObjectType.CONTAINER as utype. In that case models MUST be able to find "the objecttype containing the current objecttype", iso by direct reference. On the other hand maybe some modelers would like to have a more semantically meaningful name for the container end. Suggestion is to allow this, and to allow also CONTAINER as utype identifying the same relationship. TODO TODO TODO Base class of all valaue types, i.e. those types identified by their value, rather than a separate explicit identifier. These are the types that can be assigned to Attribute-s. Atomic/simple type. Defined by a single value. Generally a built in type from the IVOA profile model, or a subclass of one of those types. TODO TODO A primitive type with a limited, discrete set of values. May explicitly extend a PrimitiveType. Its values must be compatible with that type then. TBD Should define what it might mean for an enumeraiton to extend another enumeration. Should it restrict the possible values further? Or should it add to the values? Or ...? TODO A Role represents the "role a Type plays in the definition of another Type". Generally, instances of structured types contain instances of other types, organised according to some predesigned pattern consisting basically of name-value pairs. The names refer to the particular role to which the values are assigned. These values must have the type corresponding to the role, implemented below using the datatype element. The values may be multiple-valued. Three different types of roles are supported in VO-DML: Attribute, COllection and Reference. Their characteristics are defined below. Role extends ReferencableElement. The 'name' element that is inherited from that type must be unique in the collection of roles defined on the parent type. This uniqueness must extend over the roles available on the type by inheritance. Reference to the type that plays the role represented by this Role. The multiplicity of the role (also called cardinality) indicates whether it must have a value or may be without value, or possibly how many values are allowed. Represents the UML subsetted property. Indicates that a particular relation refines the definition of another relation. ONly a relation inherited form a base class can be subsetted. Typical usage is that the base class has a relation to a class A, and the subclass refines this to indicating that the relation should be to a subclass of A. The value should identify the subsetted property. TBD IF we are going to use utype-s to refer to elements also inside this document, we should use an appropriate keyref TBD this is a somewhat abstract, but very useful modeling concept. It implements a very common modeling design pattern. It exists in UML2. An Attribute is a Role where the target datatype is a ValueType. It represent "simple" properties of its container type, which can be an ObjectType or a DataType. Must refer to a ValueType. Possible constraints on the role. It is possible to assign a SKOSConcept to an attribute definition. This means that the values of the attribute have to comply with the definition of the SKOSConcept. This can be done in two manners. Either the SKOSConcept gives a link to a SKOS vocabulary, in which case the value must be a concept defined in that vocabulary. Or it defines a broadest SKOS concept, in which case the value must be a SKOS concept that is explicitly declared to be (narrower than) that concept, or a concept that is narrower than that concept. The latter definition allows custom SKOS vocabularies to be used. TBD it must be decided HOW the SKOS concept are to be represented as values. By URI? By preferredLabel/en [??] as defined in the vocabulary? Maybe this needs to be part of the SKOSConcept definition. Type used to indicate on attributes that they take values representing a concept defined in an identified SKOS vocabulary, and/or restricted by being narrower than an identified "broadest" concept. A URI identifiying a SKOS concept that corresponds to the concept in the model. Values of a corresponding attributes must be URI-s identifiying objects that are narrower than the identified concept. This attribute may be null as certain vocabularies may not have a If no broadestSKOSConcept is defined, one or more explicit vocabularies can be provided from which the value must be obtained. A relation is a Role where the target datatype is an ObjectType. A Reference is a Relation that indicates a kind of "usage" relationship between the target ObjectType and the owner of the reference, the "referrer". The referrer can be an ObjectType (typically) but also a DataType. The relation is looser than the composition/collection relationship, acting like a semantically meaningful pointer rather than indicating a component of the referrer. Consequently, in general many referrers can point at the same target instance, and ObjectType-s can be the target in different reference definitions. The lifecycle of the target is not bound to that of the referrer. Often the target instance is used to provide a context for the definition of the referrer. For example a coordinate frame may be referenced to provide context to coordinate values. TBD more needed ...? TBD Should have multiplicity 0..1 or 1? A collection implements a composition relation between the parent and child ObjectTypes. It is a rule that an object type can only be the target of a single collection. A subclass can be assigned a target to a collection if a baseclass is already assigned such a target, but only if the collection is explicitly 'subsetted'. A collection is assumed to be a set, i.e. a given object (as identified by its identifier!) cannot occur multiple times in the collection. The collection may be ordered, whichi implies that the order in whichi objects have been added to the collection is to be preserved. As clients can always do an explicit sort on any of the child objects' attributes, it seems not necessary to add functionality for declaring a collection is sorted on one or more attributes. Through the uniqueInCollection constraint that can be assigned to attributes, a collection can impose the constraint that different objects in the collection must have distinct values of the attribute to which that constraint is assigned. It would be better probably to add the capability to assign such constraints to this collection type. This would also give more flexibility in for example creating explicit (named) keys, or defining multi-attribute uniqueness constraints. If true, this collection preserves the ordering of object insertions. Special reference to the parent container element for a child objecttype. Is inverse of a corresponding collection relation from parent to child. This type is explicitly defined so that it can be referenced by serializations that need the inverse reference. Example is a common relational mapping that requires a foreign key from child to parent. Note that the ionverse relationship can also be identified using the ObjectType.container element. Reference to the collection that defines the relation between the container and the child object. The collection can be seen as the inverse of this container relation. Also called "Cardinality". Indicates how many instances of a datatype can/must be associated to a given role. TBD Should we generalize this to allowing M..N cardinalities, rather like minOccurs/maxOccurs in XSD? Or shall we add that to the Constraints? Indicates that the role to which this value is assigned must have exactly 1 value. Indicates that the role to which this value is assigned may have at most 1 value, and may be witohut a value. Indicates that the role to which this value is assigned may have any number of values, including no value. Indicates that the role to which this value is assigned must have at least 1 value, but may have any number. Also called "Cardinality". Indicates how many instances of a datatype can/must be associated to a given role. Unless Follows model in XSD, i.e. with explicit lower bound and upper bound on number of instances. maxOccurs must be gte minOccurs, unless it is negative, in which case it corresponds to unbounded. Lower bound on number of instances/values. When negative, unbounded. It is useful to be able to attach constraints to data model elements beyond the multiplicity. Constraints apply to instances of types or roles. In general these can be complex and might require a language such as OCL (=Object Constraint Language). Here we pre-define some simple constraints, for now only for use on Attribute definitions. TBD generalize to all model elements? For a string attribute, the minimum length the string must have. TBD useful? For a string attribute, the maximum length the string must have. When <= 0, indicates the string has no length limit. For a string attribute, the exact length the string must have. Indicates that the value of the attribute must be "globally" unique. TBD what is the context? A database, the IVOA?... Indicates that the value of the attribute must be unique in the collection of objects that the parent type belongs to. SHould be not-null. An expression constraining the value to which the constraint is applied. May be human readable for now, could become a regular expression, or maybe OCL expression in future. To be implemented by hand in target representations of the model. Sometimes constrants are more complex than some simple limit on ranges or values supported by the various explicit choices in the Constraints type. Designers can define more complex expressions using the current class. The expression defining the constraint. This can be in any language, one of the ones supported by the language element below, or some custom language. Indicates that the expression should be interpreted asan XSD 'pattern' regular expression. Indicates that the expression should be interpreted as a Java 'java.util.regex.Pattern' regular expression. Indicates that the expression should be interpreted as an OCL constraint. Indicates that the expression is in some natural language, to be interpreted and implemented by humans. Every VO-DML/XML document must start with a 'model' element, no other root elements are supported by this spec. This constraint ensures that all vodml-id definitions in a model are unique. Most other constraints related to vodml-id and utype are implemented in the Schematron constraints in vo-dml.sch.xsd