Diskussion:ISO TC 215 - ISO TS 13582

Excerpt from Email discussions

20100510

“	Use of Wikipedia: I have edited Wikipedia pages in the past, but I admit that the german instructions threw me! Is there any chance - OK OK, I should not be asking that - that the menu items could go to English (or even French!!!). -- John Larmouth	”
Please log in and go to "Einstellungen" (preferences) where you find "Sprache der Benutzeroberfläche:" Switch to English (or French or whatever) et voila. Hope this helps a bit. --K. Heitmann 16:24, 10. Mai 2010 (UTC)

“	Title: I would like to see this agreed and inserted in the Wikipedia page. I would suggest (give or take any preambles for ISO): a) "XML interchange formats between OID Repositories (including e-health requirements)" or just b) "XML interchange formats between OID Repositories" (which will include a normative annex on e-health stuff). or: c) "Registration of Object Identifiers, use and structure of OID Repositories, and XML export/import between them" My feeling is that I prefer b), but that c) might more correctly reflect the intended Scope?????? We need discussion on that. (But anyway, that title is too long!) But this leads into the Scope ... see below. -- John Larmouth	”

“	Introduction and Scope: The Wiki Introduction is good, but it rambles a lot, and talks about NWIs. Only the last para seems to be the Scope. I think that we need to agree the Scope of the collaborative work. That is important. I suggest the following for the Scope: This Recommendation / International Standard specifies the mandatory and optional information to be recorded in any Repository of OIDs, using an information model. NOTE - All Repositories shall support the recording of mandatory information, but the recording of an actual object identifier in one or more repositories is always optional. But see Annex B for e-health requirements, which are more stringent. It specifies what parts of that information shall be regarded as public, and what parts shall be subject to security protection. (In some cases, the security requirements are more stringent for e-health applications.) It references the Object Identifier Resolution System (ORS) which provides DNS look-up for information related to an object identifier, with guidance on the use of that facility. It also provides two Annexes concerned with the registration of Object Identifiers. Annex A is a general description of the registration procedures for various parts of the object identifier tree, by reference to other specifications and lnks to other documents. Annex B is a specific description for the registration procedures for e-health related OIDs, and includes a specification of those parts of the OID tree that are known to be used for national and for international e-health applications. This Recommendation / International Standard specifies an XML format for the export of the contents of an OID Repository, suitable for import to a different OID Repository. It specifies security procedures related to that export/import. I guess that will do for now!!!! Can we agree on this Scope, then we can proceed further? Or do we need more discussion? I am open to suggestions and discussion, but I think we need to get the Scope agreed. -- John Larmouth	”

Telco discussions

20100428: Ted Klein, Sylvia Thun, Kai Heitmann

• Discussed OID categories, reflected now in the correspondig sections of the document.

20100430: Ted Klein, Kai Heitmann

• Will set up wiki access for Ted Klein, John Larmouth, Olivier Dubuisson. Sylvia and Kai already have access. This allows collaborate editing.
• Kai apologizes for having this in a German environment. But he makes use of several Wiki-Templates. Can move later to another place, but for now it remains here.
• Discussed: classes of the communication model
  • ThisOIDregistry
    • gets a desc
    • card 1..* for organization
    • card 1..* for OID
  • OID
    • card 1..1 for registrationAuthority
  • RegistrationAuthority
    • delete validTime
    • card 0..1 for person
  • ResponsibleAuthority
    • make clear def, it is resp for the object identified, not for the OID itself
  • SubmittingAuthority
    • card 1..1 for person
  • Person
    • gets a coded roleCode
  • Description
    • constraint: at least one Description with lanuguage code EN (english)
    • discussed required subsections like "versioning" or "intellectual properties" as part of the desc. TBD more
  • Link
    • merged with Reference class - rationale: Link links to objects with different semantics, Reference links to things with same semantics (see description)
  • HistoryAnnotation
    • kind of log book, records the changes (of anything associated with this OID) over time
  • Reference
    • merged with Link class
    • get's type of "link" coded as linkType

20100503: Ted Klein, Kai Heitmann

• OID class
  • symbolicName: use next symbolicName also Secondary Arc Identifier
  • add title, i.e. the unrestricted name / title / very short description of the OID
  • add a sort key as ST 0..1 O or 1..1 M to provide a sorting mechanism. In HL7 reg it is mandatory, and we should seek for defaulting the sort key. Decision: make mandatory (with default suggestions).
  • creationDate has to be 1..1 M, it is now: the date of entry of the OID in the registry
  • applicationDate can be dropped, any information around application goes to HistoryAnnotation
  • association submittingAuthority should be 1..*, it should be possible to indicate primary, secondary, on behalf of submitters. This is reflected in RoleStatus (in several classes) which should be RoleType.
  • lastModifiedDate: drop, goed to HistoryAnnotation
  • realm: drop, should be an AdditionalProperty instance
• RoleStatus = RoleType
  • should cover primary, secondary, on behalf of, contact person
• V2 AssigingAuthority (HL7 v2 HD data type), is missing or not. TDB how to support this if at all.
• Permissions discussed:
  • authoritative vs non-authoritative answers (source of truth); for OIDs for which the reporting registry is the registring authority, it may answer authoritative
  • HL7: see vs updating vs creating an entry
    • meta control information: OID property dependent of classes of the OID
  • actually this is part of the maintanance NWIP and a business need of a registry, but it is not communicated
• Discussed: OIDcategory
• Discussed: ObjectType

Ideas

• It would be nice to have a reference installation based on publicly available SQL server with web interface. --K. Heitmann 13:07, 3. Mai 2010 (UTC)

Comments

Gathered through the first (internal = DE, AT, and CH) ballot rounds. Sorry for the German. Additional comments from ISO NWIP proces.

Kommentar Stefan Sabutsch (AT)

“	OID asn1 und iri: So wie ich es verstanden habe, können sowohl ASN-1 und IRI mit oder ohne Indentifier geschrieben werden. (Beispiel: oid:/2/16/840/1/113883/2/16 == oid:/Country/840/1/113883/2/16). Dann müsste es eine klare Bildungsregel geben. Andererseits sind diese Notationen optional anzugeben. --Stefan Sabutsch (AT)	”
ASN1 and IRI notation are in deed optional --K. Heitmann 21:52, 1. Mai 2010 (UTC)

“	OID.SymbolicName --> Deckt sich der Begriff mit dem "Identifier" aus ISO/IEC 9834-1 (Zu einem "Arc" werden Value und Identifier angegeben)? Oder ist das etwas Neues? --Stefan Sabutsch (AT)	”

“	OID.Category, OID.Status, Reference.type --> Welche Kataloge liegen dahinter? --Stefan Sabutsch (AT)	”
see codes --K. Heitmann 15:46, 28. Apr. 2010 (UTC)

“	CountryCode und LanguageCode --> entsprechen den ISO-Katalogen ISO 3166-1-alpha-2 oder 3166-1-alpha-3 und ISO 639-2-alpha-3? --Stefan Sabutsch (AT)	”
in essence this is true, see codes --K. Heitmann 21:55, 1. Mai 2010 (UTC)

“	Allgemein: Werden maximale Längen für String-Attribute festgelegt? --Stefan Sabutsch (AT)	”
It is planned to give recommendations about lengths --K. Heitmann 15:16, 29. Apr. 2010 (UTC)

“	ValidTime == Gültig ab oder Gültig bis? --Stefan Sabutsch (AT)	”
Both, validTime has a high and a low value element, see data types --K. Heitmann 15:17, 29. Apr. 2010 (UTC)

“	Zur Legende: "boldface attributes and relationships are mandatory". OID.category hat die Kardinalität [1...1], ist aber nicht fett gedruckt. --Stefan Sabutsch (AT)	”
non-bold attributes with cardinality 1..1 (or so) are meant to be required --K. Heitmann 15:18, 29. Apr. 2010 (UTC)

“	Was ist der "additional secondary Identifier"? Eine zusätzliche Beschreibung für einen Knoten oder ein Unterknoten für einen Top-Level-Arc? --Stefan Sabutsch (AT)	”
cannot find the term additional secondary identifier. Where is it from? --K. Heitmann 21:56, 1. Mai 2010 (UTC)

“	Ist es so gedacht, dass die registrationAuthority stellvertretend für die ResponsibleAuthority den Registrierungsprozess im OID-Knoten durchführt? Sonst hätte die Unterscheidung wenig Sinn, denn einen Wechsel der Verantwortlichkeit kann ich auch durch die Gültigkeitsdauer innerhalb der ResponsibleAuthority oder registrationAuthority abbilden. --Stefan Sabutsch (AT)	”
No, the RegistrationAuthority is responsible for the registration of the OID, the ResponsibleAuthority is responsible for the object identified by that OID (for example a codes system maintainer). --K. Heitmann 17:46, 2. Mai 2010 (UTC)

“	Was bedeutet eigentlich "Non-licensed Personnel" und "Non-licensed Organizations" im ISO/NWIP/TR Health Informatics – Guidance for maintenance of Object Identifiers OID ? --Stefan Sabutsch (AT)	”
question moved to Diskussion:ISO_TC_215-NWIP_679 --K. Heitmann 17:47, 2. Mai 2010 (UTC)

Kommentar Tony Schaller (CH)

“	Einige Vorschläge bzgl. der Länge der Strings: Anrede Text (50) 0..1 z.B. Herr/Frau Titel Text (50) 0..1 z.B. Dr. med. Name Text (255) 1..1 Nachname bei Personen oder Firmenname bei Firmen/Organisationen Vorname Text (255) 0..1 Vorname bei Personen Beschreibung Text (4000) 0..* Eine Beschreibung der Person/Organisation soll in beliebig vielen Sprachen erfasst werden können. Die Beschreibung darf auch URLs enthalten. Kommunikationsmittel Text (255) 0..* Beliebig viele Kommunikationsmittel (Tel/Fax/Mobile/eMail/Webseite/…) sollen erfasst werden können. --Tony Schaller (CH)	”

“	Adressen *Adr 0..* Beliebig viele Adressen (Domizil, Postadresse, Zweigstelle/Niederlassung/Agentur, …) sollen erfasst werden können. --Tony Schaller (CH)	”
Addresses are 0..* --K. Heitmann 21:57, 1. Mai 2010 (UTC)

“	Aktiv Ja/Nein 1..1 Grundsätzlich sollen aufgrund der Relationen im Datenbanksystem keine Daten gelöscht werden. Mit diesem Feld kann ein Eintrag als inaktiv markiert werden. --Tony Schaller (CH)	”
This is addressed by OIDStatus --K. Heitmann 14:05, 28. Apr. 2010 (UTC)

“	Adressen: Adresszeile 1 Text (255) 0..1 Erste Zeile der Adresse Adresszeile 2 Text (255) 0..1 Zweite Adresszeile Adresszeile 3 Text (255) 0..1 Dritte Adresszeile PLZ Text (10) 0..1 Postleitzahl (nicht numerisch, damit auch solche aus dem Ausland erfasst werden können) Ort Text (10) 0..1 Ort --Tony Schaller (CH)	”
This is covered by the AD data type --K. Heitmann 15:19, 29. Apr. 2010 (UTC)

“	ISO Ländercode Text (3) 0..1 Für alle ausländischen Adressen ist zwingend der 3-stellige ISO Ländercode anzugeben (für die Schweiz: CHE) --Tony Schaller (CH)	”
Country and Language Codes will follow ISO 3166, 2 characters --K. Heitmann 15:24, 29. Apr. 2010 (UTC)

“	Parent ID 1..1 Verknüpfung auf übergeordnete OID: Damit wird die Baumdarstellung ermöglicht. --Tony Schaller (CH)	”
This is not necessary or inappropriate respectively. If a parent OID is part of the same registry, parent OIDs can be derived algorithmically. If it is not part of the registry, why keep track of this? --K. Heitmann 21:59, 1. Mai 2010 (UTC)

“	OIDC unsigned integer 1..1 Eigentliche OID Komponente für den aktuellen Knoten. Beispiel 756 für den Länderknoten Schweiz Die ganze OID zu diesem Knoten ergibt sich aus der Zusammensetzung dieser und aller übergeordneten OIDC. --Tony Schaller (CH)	”
This is not necessary IMO. Any subbranch can be derived algorithically. --K. Heitmann 22:00, 1. Mai 2010 (UTC)

“	Symbolischer Name Text (15) 0..1 Symbolischer, mnemonischer Bezeichner der OID. Erlaubt sind nur Zahlen und Buchstaben, sowie der Bindestrich. --Tony Schaller (CH)	”
This corresponds to symbolicName. The rule for the name (pattern) is much more complicated according to the underlying standard. --K. Heitmann 22:01, 1. Mai 2010 (UTC)

“	Publikationsstatus Auswahl 1..1 unbekannt, erfasst, in Bearbeitung, freigegeben --Tony Schaller (CH)	”
This either maps to OID status or has to be covered by the AdditionalProperty class. --K. Heitmann 22:02, 1. Mai 2010 (UTC)

“	Publikationsstatus gültig ab Datum 1..1 Datum, an welchem die Metadaten den obenstehenden Publikationsstatus erlangt haben. --Tony Schaller (CH)	”
This corresponds to OID creationDate. --K. Heitmann 22:03, 1. Mai 2010 (UTC)

“	Beschreibung Text (4000) 2..* Eine Beschreibung der OID soll in beliebig vielen Sprachen erfasst werden können (zwingend sind englisch und mindestens eine Landessprache). Die Beschreibung darf auch URLs enthalten. --Tony Schaller (CH)	”
This corresponds to the Description class. At least one description instance in language "en" is mandatory. --K. Heitmann 22:04, 1. Mai 2010 (UTC)

“	Version Text (50) 0..1 Version des Objekts, das mit dieser OID identifiziert wird Beispiel: V1.2 --Tony Schaller (CH)	”
Versioning is a "tricky" issue, also because versions are polymorphous. It is recommended to make any versioning information part of the Description class --K. Heitmann 22:26, 1. Mai 2010 (UTC)

“	Sprache Text (10) 0..1 ISO Sprachcode, des Objekts, das mit dieser OID identifiziert wird. Beispiel: de-ch --Tony Schaller (CH)	”
This is covered by languageCode --K. Heitmann 22:28, 1. Mai 2010 (UTC)

“	URL auf externe Metadaten Text (255) 0..1 Verweis auf zusätzliche, extern gehostete Metadaten zu dieser OID (siehe Kapitel „3.1.3 Erweiterte Metadaten zu jeder OID“ auf Seite 5) --Tony Schaller (CH)	”
This can be done using the Reference class --K. Heitmann 22:27, 1. Mai 2010 (UTC)

“	Relation auf andere OID *Rel 0..* Verlinkung auf andere OIDs --Tony Schaller (CH)	”
This is covered by the Reference class --K. Heitmann 22:29, 1. Mai 2010 (UTC)

“	Source ID 1..1 ID der Ursprungs OID, Destination ID 1..1 ID der Ziel OID --Tony Schaller (CH)	”
I have no clue what that is --K. Heitmann 22:32, 1. Mai 2010 (UTC)

“	Relationsart Auswahl 1..1 Alias, Ersatz --Tony Schaller (CH)	”
Probably this is covered by the type code ReferenceType attribute of the Reference class --K. Heitmann 22:32, 1. Mai 2010 (UTC)

“	Beschreibung Text (4000) 0..* Eine Beschreibung der OID Relation soll in beliebig vielen Sprachen erfasst werden können Die Beschreibung darf auch URLs enthalten. --Tony Schaller (CH)	”
Why have a description for a referenced OID. The description should be part of the referenced OID and not a property of the de-referenced OID. --K. Heitmann 22:32, 1. Mai 2010 (UTC)

“	Attachments Attachment *Att 0..* Verlinkung auf andere OIDs OID ID 1..1 ID der OID, zu welcher das Attachment gehört Attachment BLOB 1..1 Eigentliches Attachment als BLOB (Binary Large Object) Filename Text (255) 0..1 Original Name der Original Datei z.B. CDA-CH_de_V1.2.pdf MIME Type Text (50) 0..1 MIME Datentyp des Attachments z.B. application/pdf Beschreibung Text (4000) 0..1 Eine Beschreibung zum Attachment (in der selben Sprache wie das Attachment selbst) Sprache Text (10) 0..1 ISO Sprachcode, in welcher das Attachment geschrieben ist --Tony Schaller (CH)	”
Attachments are not supported yet, as this is a communication model. What is the use case for having attachments? There aren't easy to implement. Do they have any added value to the user? Why not using links/references to external sources? --K. Heitmann 18:04, 2. Mai 2010 (UTC)

“	Weshalb ist die ASN1 Notation optional? Ich würde das zwingend machen. --Tony Schaller (CH)	”
too many OID registries do not have an ASN1 representation of their OIDs. If needed use it, but the ASN1 is optional. --K. Heitmann 18:04, 2. Mai 2010 (UTC)

“	oid-info.com führt neu eine IRI Notation, welche ich eigentlich ganz gut finde. Ich schlage vor, diese ebenfalls zwingend zu machen. --Tony Schaller (CH)	”
IRI notation is introduced, but optional --K. Heitmann 22:36, 1. Mai 2010 (UTC)

“	OID description: Hier gibt es einen Konflikt zwischen Kommentar und Deklaration im Bezug auf die Kardinalität. Aus meiner Sicht ist der Kommentar nicht zwingend, kann aber aufgrund der Anwendung mehrerer Sprachen 0..* sein. Allerdings sehe ich keinen Anwendungsfall für mehrere Kommentare in der selben Sprache. Es wäre deshalb sinnvoll, eine Schematron Regel zu definieren, die sicherstellt, dass jede Sprache nur einmal vorkommt. --Tony Schaller (CH)	”
comment dropped, Description can be in many languages --K. Heitmann 18:04, 2. Mai 2010 (UTC)

“	symbolicName: Ich weiss, dass dies eine schwierige Diskussion ist, aber ich würde die symbolischen Namen nicht zwingend machen. Gerade die untersten Einträge (Blätter des OID Trees) können aufgrund der teilweise grossen Menge aus meiner Sicht durchaus ohne symbolischen Namen existieren. Ich habe es selbst schon erlebt wie schwierig es ist einen eineindeutigen symbolischen Namen zu definieren, der dann nach Möglichkeit nur 15 Zeichen lang ist und noch eine gewisse Aussagekraft hat. Wenn wir das zwingend machen, werden uns bald einmal die Ideen ausgehen und der symbolicName verkommt zu einer nichtssagenden Abkürzung aller darüber liegenden Knoten. Als Regel könnte ich mir vorstellen, dass alle Elternknoten einer OID mit symbolischem Namen auch einen symbolischen Namen haben müssen und alle Kindknoten einer OID ohne symbolischem Namen auch keinen symbolischen Namen haben dürfen. Damit gibt es eine transparent verständliche Grenze. --Tony Schaller (CH)	”
symbolicName is optional now --K. Heitmann 18:04, 2. Mai 2010 (UTC)

“	OIDCategory: Die Idee für die Kategorien ist gut, die Tabelle ist aber unvollständig. Aus meiner Sicht kann gar keine abschliessende Tabelle definiert werden. Ich empfehle deshalb die OIDCategory nicht zwingend zu machen (0..1). Wo eine treffende Kategorie zugeordnet werden kann, soll das gemacht werden, wo aber keine passt lieber weglassen als alles unter „other“ zu registrieren. --Tony Schaller (CH)	”
There will be one STANDARD Oid category table (with only four leafs); other business requirements can be handled by using the "additional properties" class --K. Heitmann 14:00, 28. Apr. 2010 (UTC)

“	OID comment: Das würde ich weglassen. Ich kenne keinen Usecase, bei welchem die Kommentare nicht auch in der description abgelegt werden können. Bei description ist dann auch die Sprachzuordnung geregelt, bei comment würde das noch fehlen (nur string) --Tony Schaller (CH)	”
dropped --K. Heitmann 22:38, 1. Mai 2010 (UTC)

“	link: Das würde ich 0..* machen. Es kann durchaus sein, dass mehrere URLs zur Beschreibung einer OID existieren. --Tony Schaller (CH)	”
see Reference class --K. Heitmann 18:04, 2. Mai 2010 (UTC)

“	countryCodes: Wird diese Tabelle noch vervollständigt mit allen ISO Ländercodes? --Tony Schaller (CH)	”
yes see country codes --K. Heitmann 18:04, 2. Mai 2010 (UTC)

“	languageCodes: Wir benötigen zwingend noch ‚it‘. Wird diese Tabelle noch vervollständigt mit allen ISO Ländercodes? --Tony Schaller (CH)	”
yes, see language codes --K. Heitmann 15:24, 29. Apr. 2010 (UTC)

“	applicationDate: unklar. Was ist der Zweck davon? --Tony Schaller (CH)	”
That is the date when the request was made to register the OID (application) --K. Heitmann 18:04, 2. Mai 2010 (UTC)

“	Authorities: Die Definition von registration, responsible und submitting Authority ist mir nicht klar. Die Interpretation im OID Schema widerspricht meiner bisherigen Vorstellung. Da ich aber nicht weiss, was wirklich korrekt ist nenne ich hier mal meine Definition: Generell: Ein Kontakt besteht grundsätzlich immer aus einer Organisation und einer Kontaktperson, wobei mindestens eine der beiden Komponenten ausgefüllt sein muss. --Tony Schaller (CH)	”
yes and no, it's a bit more complicated. From our use case collection and experience different cardinalities for person and organization have to be handled. See the respective definitions of RegistrationAuthority, ResponsibleAuthority and SubmittingAuthority --K. Heitmann 18:04, 2. Mai 2010 (UTC)

“	Registration Authority: Ist die verwaltende OID Registration Authority (eigene oder externe). Dies wird eigentlich nur verwendet um die importierten OIDs einer fremden Registrierungsstelle von den eigenen OIDs unterscheiden zu können. --Tony Schaller (CH)	”
yes, in case of queries, only the "owned" OIDs by this RegistrationAuthority can be returned authoritative, all copies of other OID registries are non-authoritative. --K. Heitmann 18:04, 2. Mai 2010 (UTC)

“	Submitter: Diejenige Person (inkl. Arbeitgeber), die den Antrag eingereicht hat. --Tony Schaller (CH)	”
yes --K. Heitmann 18:04, 2. Mai 2010 (UTC)

“	Responsible Party: Diejenige Organisation, welche die eigentliche Verantwortung über das, mit der OID identifizierte Objekt trägt. Beispiel: Juerg Bleuer, healthevidence GmbH hat bei uns im Mandat/Auftrag der Suva eine OID registriert. Juerg Bleuer, healthevidence GmbH ist demzufolge Submitter und Eva Wetter, Suva ist die responsible Party. --Tony Schaller (CH)	”
correct --K. Heitmann 18:04, 2. Mai 2010 (UTC)

“	validTime: from: minoccurs==“0“. Oft ist kein Startdatum des Gültigkeitszeitraums bekannt. Mit dem Feld validTime kann die Historisierung abgedeckt werden. Das finde ich genial. Wenn also die Kontaktperson ändert oder ein Mutationsantrag auf eine bestehende OID kommt. Wird beim früheren Eintrag das validTime.to Datum auf den Tag vor dem neuen Antrag gesetzt und je ein neuer Eintrag gemacht mit dem validTime.from Datum des neuen Antrags. Habe ich das richtig verstanden? --Tony Schaller (CH)	”
validTime is an interval of time stamps. The reflect start and end of validity of a role or an object. --K. Heitmann 18:04, 2. Mai 2010 (UTC)

“	countryCode: Wofür wird das gebraucht? Mir fällt gerade kein UseCase ein. --Tony Schaller (CH)	”

“	person.addr muss 0..* sein (z.B. Standort-, Korrespondenz-, Rechnungsadresse) --Tony Schaller (CH)	”
addr is 0..* now --K. Heitmann 18:04, 2. Mai 2010 (UTC)

“	organization.addr fehlt noch und es muss 0..* sein (z.B. Standort-, Postfachadresse) hier noch das validTime Element ergänzen, damit können Adressmutationen historisiert werden. --Tony Schaller (CH)	”
addr is 0..* is now part of Organization. The validity aspect is part of the ISO 21090 data type --K. Heitmann 18:04, 2. Mai 2010 (UTC)

“	telecom: hier noch das validTime Element ergänzen, damit können Mutationen historisiert werden. --Tony Schaller (CH)	”
The validity aspect is part of the ISO 21090 data type --K. Heitmann 18:04, 2. Mai 2010 (UTC)

“	name: Bestehender Datentyp umbenennen in personName; Neuer Datentyp organizationName mit name und shortName (Abkürzung) erfassen bei beiden key (oid und id) hinzufügen --Tony Schaller (CH)	”
...not sure what is meant here. Data Types cannot be renamed, but probably you meant attributes. Can't see why name should be renamed as the context is clear (bound to class) --K. Heitmann 12:23, 5. Dez. 2010 (UTC)

“	organization.oid: die Idee finde ich gut, nur müsste es aus meiner Sicht nicht lediglich eine OID sein, sondern ein kombinierter Datentyp wie II (Instance Identifier) in HL7. Nur damit kann das Feld auch sinnvoll eingesetzt werden. Deshalb würde ich einen neuen Datentyp ‚key‘ machen, der aus ‚oid‘ und ‚id‘ besteht und die Kardinalität 0..* hat. Die oid ist dabei zwingend und die id optional. --Tony Schaller (CH)	”
This is maybe a database solution and has no implications regarding data types --K. Heitmann 12:23, 5. Dez. 2010 (UTC)

“	Relation zwischen Personen und Organisationen fehlt: Aus meiner Sicht muss es möglich sein, eine Organisation und eine Person miteinander zu verlinken. Z.B. Arbeitnehmer-Arbeitgeber Verhältnis. --Tony Schaller (CH)	”
Personal relationships and person-organization relationships are not part of the OID registry --K. Heitmann 22:25, 1. Mai 2010 (UTC)

“	Relation zwischen OIDs fehlt: * Aus meiner Sicht fehlt bei der OID noch ein Element oder Attribut parentOID. Nur damit kann ich eine baumförmige Darstellung generieren – denn das parsen der OIDs ist ja bekanntlich verboten… * Zudem muss eine Relation für das Abbilden der Aliase (siehe ISO Norm) existieren. Die Aliase werden zunehmend wichtig, weil es vermehrt zur Situation kommt, dass ein und das selbe Objekt mehrere OIDs erhält. Mit dem Alias Mechanismus kann dieses Problem wieder entschärft werden, weil damit ein OID als Original und die andern als Alias deklariert werden können. * Ebenfalls muss es eine Relation geben für veraltete OIDs, damit mit der Relation von der veralteten auf die aktuelle OID verwiesen werden kann. --Tony Schaller (CH)	”
all "relations" between OIDs in terms of parent/child can be derived at run-time algorithmically. Other relationships can be documented using the Reference class. --K. Heitmann 12:26, 5. Dez. 2010 (UTC)

“	Attachments: Wir sehen bei unser Datenbank vor, dass Dokumente wie Spezifikationen oder andere Attachments zu einer OID ins OID Register hochgeladen werden können. Wenn das andere Register auch machen, wäre es sinnvoll, wenn die Attachments auch ins Schema einfliessen. Wenn wir die einzigen sind, ist das aber nicht notwendig. --Tony Schaller (CH)	”
This seesm to be a useful feature for a maintenance database. There is - at this point in time - no use case to hold this information as part of an exchange of OID metadata. --K. Heitmann 12:26, 5. Dez. 2010 (UTC)

“	Version: Ich würde noch ein rein informatives und optionales Attribut „version“ zu einer OID machen. Es hilft oft, wenn diese Information strukturiert abgefragt werden kann und nicht irgendwo in der secription oder gar in den Tiefen der angegebenen URLS gesucht werden muss. --Tony Schaller (CH)	”
All versioning aspects can be derived from HistoryAnnotation. Again this maybe a useful feature in a maintenance database. --K. Heitmann 12:26, 5. Dez. 2010 (UTC)

Kommentar Frank Oemig (DE)

“	Ein Tag Attribut fehlt mit dem man beliebige Worte mit der OID assoziieren kann --Frank Oemig (DE)	”
now part of the model --K. Heitmann 13:58, 9. Apr. 2010 (UTC) The "Tags" are now one kind of "additional properties" that can be associated with any OID. --K. Heitmann 13:58, 28. Apr. 2010 (UTC)

Comments (on the data model) received from Canada 20100929

“	While I like the dashed and solid lines for playing vs. scoping, not sure most of the world will be familiar with that convention, so suggest using solid lines and changing association label to "scoping organization" --ISO Member (CA)	”
We made the lines solid and changed the association names accordingly --K. Heitmann 13:05, 5. Dez. 2010 (UTC)

“	Some of the associations need better names. For example, what is meant by the 1..* person and 1..* organization off ThisOIDRegistry? --ISO Member (CA)	”
Yes, hostingOrganization is now used instead --K. Heitmann

“	On Organization, suggest just using ST for name rather than EN.ON. Can't think of why the components or uses would be relevant in this case --ISO Member (CA)	”
Using ST now --K. Heitmann 13:05, 5. Dez. 2010 (UTC)

“	For OIDs, given that the various notations can be algorithmically derived, why allow more than one representation? Multiples just provides an opportunity for inconsistency. --ISO Member (CA)	”
It is not meant that this information is entered by a human, it maybe populated algorithmically and is simply provided for convenience. We will add a specific text to the description of the attributes. --K. Heitmann 13:05, 5. Dez. 2010 (UTC)

“	Presume the cardinalities represent "what must exist" rather than "what must be shared"? Some data might not be appropriate for sharing --ISO Member (CA)	”
Examples? --K. Heitmann 13:05, 5. Dez. 2010 (UTC)

“	The presence of statuses on the roles suggests we will care about and maintain those statuses. I don't understand the use-case or how or why they would change. Also, if you track status, would you not care about past statuses? --ISO Member (CA)	”
Role Status reflects primary, secondary, on-behalf-of roles and contact persons. The status of the roles are determined at the time "entering" an OID into a registry and thus can be documented. --K. Heitmann

“	For Description, ED already contains languageCode, so no reason to have a separate attribute. And in fact, no reason for a separate class. Same for HistoryAnnotation, though you'd need to make it HIST<ED> to get the creation date. --ISO Member (CA)	”
good suggestion / comment for Description. Creation date left in HistoryAnnotation because HIST<ED> would add another data type construction (that need a restriction) and the intention is to keep it "simple"... --K. Heitmann

“	The structure doesn't seem to allow for the possibility that different registries might store different metadata. For example, HL7's registry will store category information about submitters (provider vs. govn't, etc.) as well as the OIDs themselves (code system, value set, organization) whether they're registered by us or someone else --ISO Member (CA)	”
Information is associated always with a ThisOIDRegistry, i.e. that the data reflects the situation in a specific registry. This is not a database model. If a registry needs to store "other" metadata it can do so, with or without the need to exchange this information as well... --K. Heitmann 13:14, 5. Dez. 2010 (UTC)

“	Don't like the name "registration authority". Would prefer "issuing authority". Many authorities may register an OID, but only one may issue it. --ISO Member (CA)	”
Needs further discussion as the term is taken over from other defintions. Added language to the description of "registration authority" --K. Heitmann 13:14, 5. Dez. 2010 (UTC)

“	What does it mean for an OID to have multiple responsible authorities? --ISO Member (CA)	”
An OID may have multiple responsible authorities for example by changes of responsibilty over time. --K. Heitmann 13:14, 5. Dez. 2010 (UTC)

Comments received from Olivier Dubuisson 20101006

“	The title needs more discussion: What does communication model mean?; XMLInterface (in one word) looks weird; Do we talk about registries? repositories? both? What does ComoXOID mean? A shortest title would probably be better. --Olivier Dubuisson (FR)	”
This is now the approved project 13581. Agree with Olivier that the title is not so clear - but I think this is the title on the ISO NWIP documents. If a Form 4 is to be put together, or certainly for the ballot item - the title should probably be improved. Perhaps Communications Interface Specification for OID Registry Content? Note also that this is a Technical Report (ISO type of ballot document), not a TS (technical specification). At least that is what the paperwork with the ISO and WG3 offices state. --Ted 15:17, 20. Okt. 2010 (UTC) Hmm, I learned that the title is: ISO 13582 - Health informatics - Communication and metadata model and XML-interface specification for OID registries in healthcare - Technical Specification and that it is a Technical Specification rather than a Technical Report. That was probably subject of confusion... --K. Heitmann 12:06, 2. Dez. 2010 (UTC)

“	This is a very long introduction. It would be better to separate the introduction from the scope. --Olivier Dubuisson (FR)	”
Scope and Introduction are separate anyway!? Maybe it helps if the Introduction is split into sub-sections? --K. Heitmann 14:42, 5. Dez. 2010 (UTC)

“	"There is a minimal set of such bibliographic information" - What is meant here? --Olivier Dubuisson (FR)	”
"bibliographic" deleted from the sentence --K. Heitmann 15:25, 5. Dez. 2010 (UTC)

“	"...metadata" Note that this concept is not used in Rec. ITU-T X.660 | ISO/IEC 9834-1 --Olivier Dubuisson (FR)	”
Metadata is everything except the OID itself. --K. Heitmann 15:25, 5. Dez. 2010 (UTC)

“	"OID Registry" - I make a difference between a registry which is an official register for allocations under a given OID arc, and a repository which is a database of information about OIDs and can then copy information from registries. I think both concepts should be defined at the beginning --Olivier Dubuisson (FR)	”
Good point. The definitions are added now. --K. Heitmann 15:25, 5. Dez. 2010 (UTC)

“	"Today, due to lack of standardization of the set of metadata (both content and structure), existing OID registries are not compatible. Contents, attributes and rules of the assignment of OIDs are incompatible and often dissimilar" - It is usual than rules of assignments are different, the only constraint is that they conform to Rec. ITU-T X.660 | ISO/IEC 9834-1 --Olivier Dubuisson (FR)	”

“	"Data exchange can be facilitated by a standardised representation of a required minimum set of metadata as an XML structure together with the associated checks of underlying constraints and business rules" - What is meant by business rules? --Olivier Dubuisson (FR)	”

“	What about access rights to the data? --Olivier Dubuisson (FR)	”
To discuss anyway: will this specification cover security aspects? --K. Heitmann 15:25, 5. Dez. 2010 (UTC)

“	"eHealth information containing references to objects identified by OIDs" - This document should be general for any application domain; if needed, an Annex can be dedicated to what is specific to eHealth) --Olivier Dubuisson (FR)	”
Agree. This is intended to be in Annex A. The "Introduction" needs to be cleaned from e-health specific language and moved to Annex A or these parts need a subsection within the Introduction. --K. Heitmann 15:25, 5. Dez. 2010 (UTC)

“	"There are currently at least hundreds of OID registries in active use throughout the world" - Is this true? --Olivier Dubuisson (FR)	”
Unfortunately, yes - one of the reasons to create this specification --K. Heitmann 15:25, 5. Dez. 2010 (UTC)

“	"In many cases, more than one of these registries address the same industry segment, and have overlapping content" - This is not a problem in case of a repository, but there should be a unique authoritative registry for a given OID: The data necessarily comes from the authoritative register if the OID resolution system specified in Rec. ITU-T X.672 | ISO/IEC 29168-1 is used --Olivier Dubuisson (FR)	”
This is subject of discussion: A Registration Authority issues/allocates an OID. With that a (first) Responsible Authority is then in charge of managing the OID. Which associated OID repository is able to give authoritative answers if queried? The Registration Authority? The Responsible Authority (that may change over time)? --K. Heitmann 15:25, 5. Dez. 2010 (UTC)

“	"...specific OIDs exist in both, or worse, different OIDs identifying the same object exist in both" - This is not forbidden by Rec. ITU-T X.660 | ISO/IEC 9834-1. We could only say that it is not recommended. --Olivier Dubuisson (FR)	”
Agree that this should be recommended only --K. Heitmann 15:25, 5. Dez. 2010 (UTC)

“	"In order to standardize the activities to synchronise all existing OID registries and to ensure further interoperability it is essential to have a defined exchange format and business rules" - What is meant by business rules? A process? --Olivier Dubuisson (FR)	”
It implies what can be expected when getting an export from another registry. --K. Heitmann 15:25, 5. Dez. 2010 (UTC)

“	"Search for a list of kinds of OIDs" - What does this cover? --Olivier Dubuisson (FR)	”
For example to ask for OIDs for code systems or organizations only. --K. Heitmann 15:25, 5. Dez. 2010 (UTC)

“	There is now an XML Schema for such information in Rec. ITU-T X.672 | ISO/IEC 29168-1 which should be reused (and extended if necessary). --Olivier Dubuisson (FR)	”
This schema was already "father" of what is created here. --K. Heitmann 15:25, 5. Dez. 2010 (UTC)

“	"realm" - What is this? --Olivier Dubuisson (FR)	”
Could be "country" but the concept of country is too narrow and reflects a political viewpoint only. "Realm" means: a set of concepts valid for or real implementations found in a specific region, county, country, areas with the same human language or dialect and so on. --K. Heitmann 15:25, 5. Dez. 2010 (UTC)

“	"category" - Is this concept needed? An OID with child OIDs is a node. Of course, not all OIDs without child OIDs are leafs, but does this matter? --Olivier Dubuisson (FR)	”
Essentially this helps to build a "good practice" OID tree. I had a longer discussion with Benutzer:Ted about this and we came up with the decision that this should be part of this specification as well. Maybe further discussion is needed... --K. Heitmann 15:38, 5. Dez. 2010 (UTC)

“	ObjectType - Would this be a limited list? Is this useful compared to an free-text description? --Olivier Dubuisson (FR)	”
It is common in healthcare and people from this area would be happy to have this list. Maybe this is a recommendation only? Maybe it is part of the Annex A only? --K. Heitmann 15:38, 5. Dez. 2010 (UTC)

“	applicationDate - Is this useful compared to the creationDate? Note that it is not available for many OIDs. --Olivier Dubuisson (FR)	”
It is the time when the application of an OID (request to allocation) has been received by the Registration Authority. The actual creation date is reflected in creationDate. We need to discuss whether this optional item should be part of this specification. --K. Heitmann 15:38, 5. Dez. 2010 (UTC)

“	"Code of country or UV" - What does this acronym mean?) for universal, enumeration, values. This whole line is not clear at all. --Olivier Dubuisson (FR)	”
UV stands for Universal, yes. Sentence made clearer. --K. Heitmann 15:38, 5. Dez. 2010 (UTC)

“	lastVisited: TS [0..1] - What does this refer to? What about repositories which are publicly available, hence constantly indexed by search robots? For them, the lastVisited attribute will very probably store the date of the current day. --Olivier Dubuisson (FR)	”
In Reference this is the date the OID registry/repository last visited the referenced URI. This makes sense for example to give an indication up to what time a URI was valid and for maintance purposes. --K. Heitmann 15:38, 5. Dez. 2010 (UTC)

“	List of code systems - What does this mean? --Olivier Dubuisson (FR)	”
This is a chapter where all code systems are listed with the coded concepts that are specified or referenced in this specification. --K. Heitmann 15:38, 5. Dez. 2010 (UTC)

Comments received from Kai Heitmann 20101001

“	What is the correct word; "withdraw" or "retire" an OID? --Kai Heitmann (DE)	”