Kommentierungszeitraum ist abgelaufen, bitte nicht mehr kommentieren!

Finale Fassung der Kommentierungstabelle (am 31.10.2016 der EU-KOM übermittelt); die darüber hinaus aufgeworfenen Fragen zur Klärung innerhalb der GDI-DE (siehe unten) wurden an den AK Architektur adressiert.

 

Worum geht es?

Eine temporäre Arbeitsgruppe der MIG-T hat einen Entwurf zu technischen Empfehlungen für die Umsetzung von Registern für INSPIRE (insbesondere für die Erweiterung von Codelisten) sowie die Integration von dezentralen Registern in die INSPIRE register federation erarbeitet. Das Dokument enthält darüber hinaus eine Anleitung wie die in der federation registrierten Register durchsucht werden können.

Nach der Konsultation durch die MIG-T wird das Dokument auf Grundlage der eingegangenen Kommentare überarbeitet und anschließend der MIG-P zur Verabschiedung vorgelegt.

Wer sollte sich an der Kommentierung beteiligen?

Die Konsultation richtet sich insbesondere an Experten, die Register oder Registries betreiben und diese an die INSPIRE Registry anbinden möchten (z.B. für die Erweiterung von Codelisten).

In Deutschland werden neben den GDI-Kontaktstellen insbesondere die Arbeitskreise der GDI-DE, die INSPIRE Fachnetzwerke sowie der GDI-DE Betrieb beteiligt.

Relevante Verordnungen und Technical Guidance Dokumente? 

Es sind keine Verordnungen oder Technical Guidance Dokumente unmittelbar relevant.

Kommentierungszeitraum?

Kommentare können bis zum 26.10.2016 über diese Seite abgegeben werden.

Zu prüfende Dokumente?

Kommentierungstabelle

Bitte in der nachfolgenden Tabelle Ihre Kommentare eintragen (möglichst in englischer Sprache). 

Bitte die Kommentare klassifizieren (Type of comment) nach

  • ge = general
  • te = technical
  • ed = editorial

Bei Fragen wenden Sie sich bitte an Dr. Falk Würriehausen oder Daniela Witter. 

Chapter/ Section (e.g. 3.1)Paragraph/ Figure/ Table (e.g. Table 1)Type of commentCommentsProposed changeKommentiert von (nur zur internen Verwendung)
4.2 1 ed  ... through a simple document...GDI-NI, Loddenkemper
4.2.1 1 ed Clearly documented roles...GDI-NI, Loddenkemper

4.2.3

  geI cannot understand, what is "properties" in this context. Please give an example for "properties" in this context.GDI-NI, Loddenkemper
4.2.4 nur Hinweis für GDI-DEStatus der Objekte als URI angeben! Das hatten wir bisher so noch nicht. Was sagt dazu die GDI-DE?? GDI-NI, Loddenkemper
4.2.5 1 ed Once the elements enters a registry/register,...GDI-NI, Loddenkemper
4.2.x  ed/geBest Practice - the term "General principle" might be better in many cases, because the proposed things are far more than just "best practice" to me.principles - e.g. 4.2.5 is quite essential in this caseGDI-NI, Loddenkemper
4.2.8 2 ed ... used language such as English, willGDI-NI, Loddenkemper 
alles nur Hinweis für GDI-DEIm Architekturkonzept "Technik" fehlen die ISOs im Zusammenhang mit den Registries. Es wäre gut, wenn die ISOs an zentraler Stelle bei der GDI-DE vorlägen, so dass Länder-GDIs bei Bedarf Einsicht nehmen könnten.ISO 19106 und ISO19135-1 ins Technikdokument aufnehmen.GDI-NI, Loddenkemper 
4.3 Figure 3  Figur 3 ist doppelt abgebildetnur 1x abbildenGDI-NI, Loddenkemper 
5.3 Table 1, 2, 3 ed/teWenn ich "string" in Bezug auf Datenbank lese, dann habe ich sofort ein ungutes Gefühl, wenn die Feldlänge nicht vorgegeben wird. Also wenn es sich nirgendwo anders findet, dann hier in der Tabelle für sämtliche Strings gleich die Feldlänge mit hinterlegen. GDI-NI, Loddenkemper 
5.3 Table 3 ed/geEs mag an meiner generellen Unkenntnis liegen, aber ich verstehe nicht, was "predicate" ist. Vielleicht kann die Lösung ja auch jemand hier ins Wiki schreiben, falls das sonst jedermann allgemein bekannt sein sollte. Andernfalls gehört die Erläuterung vielleicht doch noch mit in die TG. GDI-NI, Loddenkemper 
 alles  teIn der TG wird nichts darüber ausgesagt, ob die Codelisten, die ja laut VO 1088/2010 vorgeschrieben sind, nach dem Standard OASIS Code List Representation (Genericode) Version 1.0 vom 28.12.2007 abgelegt / aufgebaut sind. Ich bin mir allerdings auch nicht sicher, ob es notwendig ist, hier eine Kompatibilität zu haben. Von daher bitte ich um Prüfung, ob ein Hinweis auf den Standard Genercode mit in die TG gehört oder nicht. Wenn der Standard Genericode für unser Vorhaben, Codelisten in Registries abzulegen, unbrauchbar ist, dann wäre hierzu eine klare Aussage wünschenswert. GDI-NI, Loddenkemper

3.2

  ed

Addition of an abbreviation

API…application   programming interface

GDI-LSA

4

 

4.2.4

6.5

7.2

ANNEX B

Paragraph 4

 

Paragraph 6

Paragraph 2

Paragraph 2

Paragraph 1

 ed

Missing text reference to figure

Add a text reference to:

the figure 1

the figure 2

the figure 7

the figure 14

the figure 15

 

GDI-LSA

4.3

Paragraph 1

ed

Incorrect name of the text reference

Figure 3

GDI-LSA

5.2 until 7.3

Figure 4 until14

ge, ed

After figure 3 the text references do not refer to the correct figures and the names of the text references are incorrect.

Control the names and the links of the text   references

GDI-LSA

6.1.1

6.1.2

TG Requirement 3,4

TG Requirement 9

ed

Generalization of the TG Requirements

Remove „mandatory/optional“ from TG   Requirements

GDI-LSA


 

3 Kommentare

  1. Anja Loddenkemper sagt:

    Nach der ersten Beschäftigung mit dem gut lesbaren Papier kommen mir die folgenden Ideen bzw. Fragen in den Sinn, denen zumindest ich weiter nachgehen werde:

    1. Muss die Registry.de auf die Anforderungen im Papier hin überprüft werden, um die Inbetriebnahme und auch die Zukunftsfähigkeit zu sichern (selbst wenn es sich bisher bei dem Papier nur um ein "draft" handelt)? Wenn ja, wer ist hier in der Pflicht?
    2. Ist es sinnvoll zumindest Bestandteile der Registry.de durch die beiden Softwareprodukte "Are3na Re3gistry" und "Linked Data Registry (UK) " zu ersetzen  oder zu ergänzen, um möglicherweise schneller einen tatsächlich nutzbaren produktiven Stand zu erreichen? Wer kann Aussagen zur z.B. Performance der frei nachnutzbaren Software machen?
    3. Wenn wir den Gedanken der "Federation of Registries" wie er im Papier vorgezeichnet wird, ernst nehmen, dann frage ich mich, ob es langfristig ausreichend sein wird, eine einzige Registry für Deutschland zu haben.
    4. Fehlt der Registry.de womöglich ein RoR (Register of Registers), um ggf. auch lokale Registries "anschließen" zu können? Das Rollenkonzept ist in jedem Falle bisher unzureichend.
    5. Bei uns in der GDI-NI scheint es (Aussage Datenhalter) bei der Umsetzung des INSPIRE Datenmodells einen "Engpass" im Bereich der bisher nirgendwo hinterlegten Codelisten zu geben. Was passiert, wenn ein Datenhalter aus Not plötzlich mit einer Standard-Registry auftaucht, in der er seine benötigten Codes einträgt - egal ob diese von der reinen Logik her besser auf EU oder auf DE-Ebene platziert wären? Damit würde der Gedanke der Registry ad absurdum geführt.

    Als größtes Manko sehe ich für mich persönlich aktuell, dass sich mir bisher immer noch nicht vollends erschließt, was die Registry.de alles leisten soll - nach deutscher Meinung. Im Papier werden die Anforderungen reduziert auf:

    • Hinterlegen von Codelisten
    • Registry muss wissen, welche Unter-Register (RoR-Prinzip) vorhanden sind, um Informationen auffindbar zu machen

    Dieses Beschränken auf das Wesentliche macht die Sache erst einmal deutlich einfacher, als die vielfältigen und für mich größtenteils unscharfen Anforderungen, die immer wieder im Zusammenhang mit der Registry.de - mal hier, mal da - auftauchen. In diesem Zusammenhang wird zumindest mir auch immer klarer, dass es sehr unglücklich ist, Monitoring Client und Registry - inhaltlich etwas vollständig anderes - softwaretechnisch zu vermischen. Aus meiner Sicht sollte man hier eine deutliche Trennung in Betracht ziehen.

    1. Daniela Witter sagt:

      Vielen Dank für die Anregungen und Hinweise. Ich schlage vor, diese im AK Architektur weiter zu diskutieren und habe die Leitung des AKs entsprechend informiert.

  2. Daniela Witter sagt:

    In diesem Zusammenhang möchte ich auf eine Präsentation von Chris Schubert (AT) hinweisen, die er auf der INSPIRE Konferenz in Barcelona gehalten hat. Chris Schubert hat Tests zur Anbindung von externen Registern an die INSPIRE Registry durchgeführt und auf der Konferenz über seine Erfahrungen berichtet.