Broadly OGD 2.0 connects the dataset to its publisher and to one ore more contact points.Obviously there are plenty of ways in which people or organizations can be connected to a dataset. There are publishers, maintainers, subject matter experts, technical experts, authors and more. OGD 2.0 tries to accommodate these manifold relationship by capturing them in an property of the contact point (sonstigeKontakt). However one can question the benefits of this approach. It seems only useful if multiple different contacts are given. If roles are filled with the same agent t is likely that metadata editors will not enter the same information twice, but simply opt for one (the most appealing) role. But here practices will vary and metadata won’t be semantically interoperable. It is also unlikely that harvested systems will provide ideally matching differentiation. Here two the mapping will vary leading to metadataset that are not semantically interoperable. Both DCAT-AP and the US Project Open Data Metadata Schema 1.1 simply differentiate between the publisher and the contact point. It seems advisable to leave it at that. If at all one could make the e-mail address mandatory as in the US-Standard, thereby concentrating on the main benefit from the users point of view. If there really are good reasons to capture the role one could that by capturing them in enumeration / list of roles (or a number of associations with a class “role”). It also seems wise to stick with the adoption of the vCard format as both DCAT-AP and US Project Open Data Metadata Schema 1.1 do.
OGD 2.0 additionally captures the “provenance” of the Datensatz (via a centrally administered list of registered data providers). While this is mapped to DCAT-AP roperty “provenance”, DCAT-AP seems to have intended something completely different .
Generell verbindet OGD 2.0 den Datensatz mit seiner veröffentlichenden Stelle und einem oder mehreren Kontakten. Es gibt offensichtlich vielfältige Weisen, in denen Personen und Organisationen in Bezug zu einem Datensatz stehen können. Es gibt veröffentlichende Stellen, zentrale Ansprechpartner, pflegende Stellen, fachliche Ansprechpartner, Autoren und mehr. OGD 2.0 versucht diesen vielfältigen Beziehungen gerecht zu werden, indem sie in einer Eigenschaft (Rolle) des Kontaktes (sonstigerKontakt) erfasst werden. Es ist jedoch fraglich, welchen Nutzen diese Herangehensweise hat. Sie ist nur von Nutzen, wenn mehrere unterschiedliche Kontakte vorliegen. Wenn die Rollen vom selben Akteur ausgefüllt werden, so ist es unwahrscheinlich, dass die Metadaten Redakteure, dieselbe Information mehrmals erfassen. Stattdessen werden sie einfach die eine (die ansprechendste) Rolle auswählen. Hier werden sich die Praktiken jedoch unterscheiden und die Metadaten nicht semantisch interoperabel sein. Es ist auch unwahrscheinlich, dass geharvestete Systeme ideal abbildbare Informationen bereitstellen. Hier werden sich die Abbildungen unterscheiden und zu semantisch nicht interoperablen Metadaten führen. Sowohl DCAT-AP wie das US Project Open Data Metadaten Schema 1.1 unterscheiden lediglich den Herausgeber (Publisher) und den Kontakt. Es scheint ratsam, es dabei zu belassen. Wenn überhaupt könnte man die E-Mailadresse des Kontaktes obligatorisch machen und sich so auf den aus der Nutzerperspektive wichtigsten Aspekt konzentrieren. Wenn es wirklich gute Gründe dafür gibt, die Rolle zu erfassen, so könnte man diese in einer Aufzählung / Liste aller Rolle eine Kontaktes bzw. als eine Anzahl von Assoziation mit eine Class „Rolle“ erfassen. Es erscheint auch richtig, die Übernahme des vCard formats beizubehalten wie es sowohl DCAT-AP und das US Project Open Data Metadaten Schema 1.1 tun.
OGD 2.0 erfasst außerdem noch die „provenance“ eines Datensatzes – über eine zentral administrierte Liste registrierter Datenbereitsteller. Dies wird auf die property „provenance“ in DCAT-AP gemappt, DCAT-AP scheint darunter jedoch etwas gänzlich anderes zu verstehen.
Comments
See also https://joinup.ec.europa.eu/asset/ogd2_0/issue/kontakt-rollecode-and-dc… regarding contact data and roles.
Die Angabe verschiedener Rollen entspricht der Wirklichkeit und wird in manchen Portalen auch bereits tatsächlich ausgiebig benutzt. Wieso sollte ich das alles auf eine Rolle reduzieren? Nur weil ein mich harvestendes System das nicht abbilden könnte?
Die Entscheidung, wer diese Rollen-Informationen reduzieren muss (wenn es denn notwendig wird), sollte beim Harvester liegen und nicht am Metadatenbereitsteller. Ich möchte so viele Informationen und Daten bekommen, wie es möglich ist.
Kurzes Beispiel aus Berlin? Im Geoportal von Berlin sind häufig 4 Personen angegeben. 2 für die fachlichen Fragen und 2 für die technischen Fragen. Das sind dann auch wirklich 4 verschiedene Leute (ist halt ne große Verwaltung). Hier sind die Rollen wichtig und würde nur zum Rauschen innerhalb der Verwaltung führen, wenn das nicht in den Metadaten sinnvoll abgebildet werden könnte.
Anderes Beispiel? Im Datenportal der Deutschen Bahn ist bei den meisten Datensätzen immer der gleiche Mitarbeiter eingetragen worden. Obwohl die Daten aus verschiedenen Konzernteilen kommen. Das geht natürlich gar nicht - und gab gleich böse Mails, warum er das machte. Seine Rolle hier ist die eines Kontakt-Proxis. Die echten Datenherausgeber haben sich noch nicht getraut ihren eigenen Namen ins Datenportal schreiben zu lassen. Also steht ein "fremder" Name dort, der die Anfragen weiterleitet. Hätte diese Kontakt-Rolle am Datensatz gestanden wäre das viel erklärbarer und ruhiger verlaufen. Aber das kann in Deutschland immer mal wieder passieren, nicht jeder Mitarbeiter möchte öffentlich mit seinem Namen in Erscheinung treten. Daher sind Rollen wichtig.
In my opinion, the main problem with the current draft is that I don't see the benefit of specifying multiple contacts using a fixed set of roles (RolleCode): For example, assume I get OGD 2.0 metadata for an element that specifies a veroeffentlichendeStelle, a pflegendeStelle and a fachlicherAnsprechpartner. Who do I contact if I have questions regarding the metadata? The veroeffentlichendeStelle, because it's assumably in charge of the published version? The pflegendeStelle, because it's assumably in charge of maintaining things? Or the fachlicherAnsprechpartner, because they probably now what I'm talking about (in contrast to those who just publish and maintain things)?
The problem is that reducing the complex responsibilities in an organization to mere role names will make that information useless for an outsider. I have no chance of knowing how an institution in another part of the world (or Germany, if you insist on keeping things national) separates a fachlicherAnsprechpartner from a technischerAnsprechpartner.
The only solution that makes sense from a user's point of view is, in my opinion, a single point of contact who will dispatch incoming messages internally. In addition, that single point of contact should not be a person (e.g. Ms. Foo in department Bar) but a role (e.g. open-data@bar.organization.de). Otherwise your metadata will be outdated very fast.