{{{ #!comment NB! Make sure that you follow the guidelines: http://trac.posccaesar.org/wiki/IdsAdiEditing }}} [[TracNav(TracNav/RdsWip)]] [[Image(wiki:IdsAdiBranding:Logo-128x128.gif)]] = POSC-Caesar FIATECH IDS-ADI Projects = == Intelligent Data Sets Accelerating Deployment of ISO15926 == == ''Realizing Open Information Interoperability'' == ---- = RDS/WIP Template Definitions = This page is about the minimum requirements for template definition in the RDS/WIP. At the time of writing, it is too early to cast the RDF/OWL representation in stone, since this will require further work on the base templates first. == Purpose == The main purpose is to collect requirements and propose at least an interim XML format for cooperation and collaboration amongst the IDS-ADI team. This format will have a published transformation to RDF/OWL using XSLT (free of mapping). == Experimental == The format, the transform, and the RDF/OWL representation are manifestly experimental: the intent of this initiative is to discover through use any problems in the model to feed into the development process of the standardized representations. The XML representation is not ever intended to be normative ISO 15926, although it ''may'' evolve into an acceptable general input format for the RDS/WIP, subsequent to an acceptable RDF/OWL transform. == Requirements and Limitations == These requirements outline what we (the IDS-ADI team) need in order to cooperate and collaborate on template definition: these requirements explicitly '''do not''' specify minimum requirements for template definition in ISO 15926: that is a separate issue. IETF [http://www.ietf.org/rfc/rfc2119.txt RFC2119] describes the usage of several key words on this page and in associated discussions: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. === Template Definition === A template definition MUST include: * a unique identifier [wiki:RdsWipTemplateDefinitions#id (see below)]; * a super class; * two or more roles [wiki:RdsWipTemplateDefinitions#unary (or maybe one or more - see below)]; * an RDS/WIP status; and * provenance data. A template definition SHOULD include: * names, not necessarily unique, in one or more languages; and * descriptions, not necessarily unique, in one or more languages. * textual definition, SHOULD be unique, in one or more languages. A template definition MAY include: * other classifications (for grouping); * zero or more other statuses. === Role Definition in a Template Definition === A role definition in a template definition MUST include: * property for role; * range of role value in instantiated template (ie. class); * position in the sequence of roles in the instantiated template; and * identifier that is unique amongst the roles in the template definition. A role definition in a template SHOULD include: * indication if optional or mandatory (see notes 1 & 2). A role definition in a template MAY include: * names, not necessarily unique, in one or more languages; and * descriptions, not necessarily unique, in one or more languages. Notes: 1. The cardinality of a role in an instantiated template must be zero or one. 1. In the case of a mandatory role, that means the cardinality is always one. 1. At the atomic and core template levels, it likely will be better to make a template optional than a role optional. === Property Definitions === Note: the need for property definitions prior to template definitions is contestable. If we can find a way to remove this requirement, we should do so. A property definition MUST include: * an identifier; * a range restriction as an entity type; and * an RDS/WIP status; * provenance data (not yet defined). A property definition SHOULD include: * names, not necessarily unique, in one or more languages; and * descriptions, not necessarily unique, in one or more languages. * textual definition, SHOULD be unique, in one or more languages. A property definition MAY include: * a range restriction as a value class; and * zero or more other statuses. === Statuses for Template and Property Definitions === As above, both template definitions and property definitions MUST have RDS/WIP status information and MAY have additional status information. Status information MUST include: * the organization making the status; * the date/time from when the status applies; * the date/time to when the status applies; * the scheme of the status; and * the status value itself. Note: status in ISO 15926 will not be nearly so "flat", likely being expressed as temporal class membership with many other relationships. === Template Definition Extension === Templates definitions may "extend" (that is, subclass) other template definitions. When a template definition extends another template definition, it "inherits" the roles (but not the provenance, names, descriptions and statuses). @todo consider how extension affects role order, how extension affects OWL/RDF queries (must a template be able to be easily treated as its more generic form?). === Template Definition Obsolescence === @todo consider if obsolescence can/should be completely handled by status. Consider if obsolescence requires abstract super classes that can group a set of succeeding templates as a replacement for the obsolesced template. What about when one template obsolesces a group of templates? Lots to consider - must be supported or ruled out. === Provenance === @todo look into Magne's work in Part 6 referencing other ISO standards. === Designation === To be in conformance with the existing work on Part 4, it would seem that a template would have a designation, which is a textual identifier that is unique within the published ISO 15926 space. Designations are apparently intended to be meaningful in UK English and use UK print media conventional orthography. Designations therefore introduce a couple of chicken-and-egg conundrums: * entries in the RDS/WIP need not necessarily be submissions to ISO 15926 classification; and the RDS/WIP is not the official registry of ISO 15926 designations. * since designations are meaningful (ie. they are information bearing identifiers), it is also necessary that they be vetted by some official body for conformance with the definition. For these two reasons, I do not believe that RDS/WIP submissions should specify a designation. Its possible that they could suggest a designation, but if so, it should be very clear that: 1. A ''suggested designation'' need not be unique in the RDS/WIP, but SHOULD not collide with an official Part 4 designation. 1. A ''suggested designation'' has no use as an identifier of any sort. === Unique Identifier ===#id The need for a unique identifier means different things in different situations. If the identifier is relative to a submission, the identifier MUST be unique only within the submission. On the other hand, if the identifier is an absolute URI, it MUST NOT be re-used for another RDS/WIP submission, by anyone. The rest of this section goes into more detail. There are mechanisms in place for allocating identifiers in the RDS/WIP (on various different endpoints), provided by the RdsWipIdGenerator. In the case of templates, the identifiers would be allocated in the !http://dm.rdlfacade.org/data# namespace. It will not be necessary to allocate an identifier in that space in order to make a submission to the RDS/WIP, but there MUST be an identifier in a namespace owned by the ''submitter'' that can be used to report back to them what identifier their submission has been given (this is particularly important for bulk submissions). The RDS/WIP will use the ID Generator to allocate any identifiers. a. In the case where these ''submission'' identifiers are ''relative'' to the submission itself, they only need to be unique within that document - the relative identifier MUST NOT be used by the RDS/WIP except for reporting its correspondence to the RDS/WIP identifier in reports to the submitter. a. In the case where these identifiers are absolute URIs within the nominated template namespace above, then they MUST have been allocated prior to submission using the ID generator. a. In the case where these identifiers are ''absolute'' URIS outside the nominated template namespace above, the RDS/WIP SHOULD store its correspondence to the RDS/WIP identifier in the publishing endpoint. ==== Unique ID Summary ==== This stuff really falls under "common sense" - basically, if you don't provide a good identifier, one will be allocated for you. If the one you provided is good, but outside the namespace, one will be allocated for you in the namespace and its correspondence to your identifier will also be published. === Unary Relationships ===#unary In the original draft of this page, it was stated that a template definition must have a minimum of two roles. In the discussion below, that was called into question "why not just one"? A relationship that has only a single role, that is, a relationship that connects a thing to nothing else, is called a "unary relationship". One of the candidate relations to classify a "unary relationship" is a reflexive relation, that is a relation that connects a thing only and always to itself. Unary relationships can be validly constructed, for example, any binary relationship f(a,b) can be defined as the relationship g(a) where, the relation g is defined so that g(x) == f(x,b). An example might be p(3) where p indicates set membership in prime numbers and 3 is a prime number. You could equally say 3 is an element of p. In ISO 15926 part 2 terms, p(x) blends several generally distinct concepts together: it includes the concept of class/set membership (classification) and the concept of being a prime number. Similarly entity type and specialization are distinct concepts in part 2. So apart from expressing set membership, that leaves relations that necessarily link a thing only to itself. While many relations can include elements that are reflexive, that is insufficient. The question that needs to be asked is, are there any relations that are necessarily and always reflexive? The goal here is to decide: are we imposing too much by disqualifying unary relationships? == XML Format == @todo flesh out a representation as extension language to QXF maybe (a la QTXF), since this already has an OWL/RDF mapping. Would we need to be able to generate QTXF from the definitional format? @note DNV's IRM unit also have their own internal XML format for defining templates - we should see if that works for these purposes. = Points of Contention = 1. Cardinality of a role - Onno says that in the draft part 7 work, role cardinality could be greater than 1, that is a template instance could have multiple properties of the same name. This of course creates considerable issues for positional role notation and goes against what Julian has proposed above, so we need to find consensus on this - will probably need Ian's input. ---- [[ViewTopic(RdsWipTemplateDefinitions)]]