${taskforce.name} Avatar
  1. OMG Task Force

Multiple Vocabulary Facility (MVF) 1.1 RTF — All Issues

  • Key: MVF11
  • Issues Count: 14
Open Closed All
All Issues

Issues Descriptions

Definitions for a number of core properties are missing from the metamodel section of the MVF specification

  • Key: MVF11-16
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Currently the specification has definitions for classes, but not for all of the properties used in the metamodel. Some definitions are available in the ontology for these properties, but the metamodel section should be clarified to include them.

  • Reported: MVF 1.0 — Fri, 11 Oct 2024 18:23 GMT
  • Updated: Fri, 11 Oct 2024 18:23 GMT

The constraint on vocabulary entry stating that it denotes exactly 1 MVF entry is incorrect

  • Key: MVF11-15
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    While typically one would associate a vocabulary entry with only one MVF entry, this does not allow for cases when a vocabulary includes more entries than are mapped to MVF entries. Thus, one could have terms that either are not needed or have yet to be mapped, and the restriction would result in wrong results (or a rule that exercises the restriction could do so).

    The restriction in the MVF ontology should be modified to 'max 1' from exactly 1, and the redundant restriction in the ISO 1087 ontology that says 'min 0' should be eliminated.

  • Reported: MVF 1.0b2 — Wed, 19 Jun 2024 18:45 GMT
  • Updated: Wed, 19 Jun 2024 18:45 GMT

The restriction on MVF Element stating that it can only have one textual name is overly constrained

  • Key: MVF11-13
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    MVF element is the parent class of both MVF entry and vocabulary entry. A given term, which is a vocabulary entry may be used in various ways, and in some cases may have multiple textual names. This isn't common, but does happen in practice, especially in cases involving legacy data.

    One case we have found on the IDMP-O project is that there are two sources for the same term. The European Medicines Agency publishes controlled vocabularies are specified in the EMA SPOR reference ontology (RMS). That ontology includes not only EMA SPOR controlled vocabularies but duplicates a subset of the controlled vocabularies from MEDdra (Medical Dictionary For Regulatory Activities). In the IDMP representation of various pharmaceutical products, both controlled vocabularies are required for use in the EU. Thus we have the EMA SPOR version of the MEDdra term and the actual MEDdra term, which we map to one another using owl:sameAs. That results in a logical inconsistency because we have more than one term name for the same term. We have similar issues with certain FDA controlled vocabularies, where they have identifiers specified in the GSRS and UNII repositories, that are actually the same identifier, thus resulting in two textual names for the same thing.

    There may be a requirement for some implementations to use a SHACL shape for this, but for information content, such as the specifications for certain substance names, simply relaxing the restriction from exactly one to some values from would provide the semantics we need.

  • Reported: MVF 1.0 — Tue, 23 Apr 2024 16:49 GMT
  • Updated: Wed, 24 Apr 2024 18:25 GMT

Need an extension in the terminology science ontology for numeric ordering

  • Key: MVF11-11
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    A numeric ordering is a kind of systematic ordering, with a couple of important attributes: (1) what the origin is – zero or one, typically, and (2) whether it is from low to high or high to low. Typically numeric orderings of collections use positive integers, but there could be other kinds of ordering that use, for example, alphabetical with numerals and/or distinctions by rank, such as A.1.1.

    There may also be utility in having the notion of 'position', such as a position in an ordered list, or position of a term in a text.

    We have not captured this clearly in the ontology and should.

  • Reported: MVF 1.0b2 — Thu, 7 Mar 2024 20:09 GMT
  • Updated: Fri, 12 Apr 2024 18:20 GMT

Incorrect label on mvf-tsc;TermFormation

  • Key: MVF11-10
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    The label in the terminology science ontology reads 'term harmonization' and should be 'term formation'.

    This issue affects only that ontology, not the documentation for it.

  • Reported: MVF 1.0 — Wed, 28 Feb 2024 19:11 GMT
  • Updated: Fri, 12 Apr 2024 18:20 GMT

In the mapping ontology between SKOS-XL and MVF, the mappings need adjustment

  • Key: MVF11-9
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Currently we've mapped MVFEntry to SKOS Concept, and it should be Vocabulary Entry to SKOS Concept. Likewise, the mapping between MVF Concept System to ConceptSystem should be to Vocabulary in MVF.

  • Reported: MVF 1.0b2 — Fri, 19 Jan 2024 19:44 GMT
  • Updated: Fri, 12 Apr 2024 18:20 GMT

Consider adding more contextual properties to vocabulary entry

  • Key: MVF11-8
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Investigate whether this should be on vocabulary, vocabulary entry, both, and/or possibly on a more general element as well.

    There may also be an impact on the ontology, depending on the resolution.

  • Reported: MVF 1.0b2 — Fri, 19 Jan 2024 19:36 GMT
  • Updated: Fri, 12 Apr 2024 18:19 GMT

Include a note to explain the use of generalization and context between MVFEntries

  • Key: MVF11-6
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This represents a generalization as in UML or OWL, at the metamodel level rather than at the UML model level. This may be confusing to users and so an explanatory note is needed to help. Note that the ramifications of this are at the instance level - one instance of an MVF entry may be a generalization of another instance of an MVF entry.

    The same is true of the additional relationship, which is context, where notes and examples would also be helpful.

  • Reported: MVF 1.0b2 — Fri, 19 Jan 2024 19:15 GMT
  • Updated: Fri, 12 Apr 2024 18:19 GMT

The mapping from SKOS Concept to MVF Entry may need further review

  • Key: MVF11-12
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    While the definition of MVF entry and that of SKOS concept appear to be the same, there are differences in how SKOS is used. That may, in fact mean we should consider mapping to MVF Vocabulary Entry instead.

    Regardless, it would be useful to provide a discussion in the specification about the possibility, depending on the application.

  • Reported: MVF 1.0b2 — Fri, 8 Mar 2024 19:18 GMT
  • Updated: Fri, 8 Mar 2024 19:18 GMT

Property 'currentMVFEntry' changes the multiplicity, so it should be redefines not subsets

  • Key: MVF11-3
  • Status: open  
  • Source: Coventry University ( Mr. Stephen Powley)
  • Summary:

    The property 'currentMVFEntry' on the association ElementCurrentEntry changes the multiplicity from 0..* to 0..1, so it should be redefines not subsets (or the parent multiplicity needs to be changed)

  • Reported: MVF 1.0b1 — Wed, 7 Jun 2023 22:54 GMT
  • Updated: Sat, 2 Mar 2024 23:58 GMT

Additional mapping capabilities between MVF entries would be useful

  • Key: MVF11-7
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This might be a new area of exploration, and could apply beyond MVF entries in the context of MVF.

    Currently the metamodel reflects SKOS-like relations such as broader and narrower, but more is needed for certain applications.

    It would be useful to have a non-normative annex demonstrating how one could do this as a starting point for MVF users.

  • Reported: MVF 1.0b2 — Fri, 19 Jan 2024 19:21 GMT
  • Updated: Fri, 9 Feb 2024 19:26 GMT

The MVF ontology does not reflect the addition of a descriptive reference property

  • Key: MVF11-4
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Just prior to publication of the FTF report, a new property was added to the metamodel called descriptiveReference. This property, which is quite useful, was not added to the ontology, however, and may eliminate the need for restrictions using the Commons is defined by (cmns-dsg;isDefinedBy) property on VocabularyEntry.

  • Reported: MVF 1.0 — Fri, 28 Jul 2023 18:51 GMT
  • Updated: Fri, 28 Jul 2023 18:51 GMT

The published XMI should be generated as Canonical XMI

  • Key: MVF11-2
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    MVF users have requested that the form of the XMI that is provided as a part of the MVF specification be canonical XMI.

  • Reported: MVF 1.0a1 — Fri, 14 Apr 2023 18:18 GMT
  • Updated: Thu, 13 Jul 2023 14:15 GMT

More examples are needed to demonstrate how to use MVF

  • Key: MVF11-1
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    There is an example in Annex B that is quite useful, but is not multilingual. Since we have said that MVF can be used to support multiple natural languages, we need at least one additional example to cover that use case. We might also include a broader example showing how to represent a general vocabulary in MVF, such as the AI PTF emerging vocabulary for artificial intelligence, to show how this can be done.

  • Reported: MVF 1.0a1 — Fri, 13 Jan 2023 19:35 GMT
  • Updated: Thu, 13 Jul 2023 14:15 GMT