Eigenschaften "organization" und "hasMembership" in oparl:Person

[sterni24]

Diese Eigenschaften sind m. E. teilredundant und nicht hilfreich, weil sie nur komplett ausgegeben werden. Siehe auch #167 und

In diesen Listen sind ggf. Sammlungen von Gremien-, Partei- und Fraktionsmitgliedschaften enthalten, die zudem auch noch aktiv bzw. historisch sein können.

[akuckartz]

organization ist auch aus meiner Sicht redundant, nicht mehr erforderlich und kann deshalb entfernt werden.

[marians]

Wohl ein Überbleibsel. Habe es entfernt.

[sterni24]

@marians @akuckartz Die Ausführungen zu "hasMembership" sind noch nicht behandelt worden. Siehe oben.

[akuckartz]

Wegen hasMembership wieder geöffnet.

[marians]

Das verstehe ich nicht. Welche Ausführungen zu "hasMembership" stehen in diesem Issue (175), die noch nicht behandelt wurden?

[akuckartz]

@sterni24 Verstehe ich das richtig, es geht darum, dass hasMembership für Personen redundant ist, weil auch die Organisationen diese Eigenschaft haben?

[sterni24]

@akuckartz "organization" war teilredundant zu "hasMembership" (wurde ja auch entfernt). "hasMembership" ist ähnlich zu betrachten wie die von @marians vorgeschlagene Eigenschaft "meeting" in oparl:organization #167

Ich weiß nicht, was ein Client mit der "hasMembership"-Liste anfangen soll, weil In dieser Liste ggf. Sammlungen von Gremien-, Partei- und Fraktionsmitgliedschaften enthalten sind, die zudem auch noch aktiv bzw. historisch sein können. Da sie eh optional ist, wird sie wohl in unserer Schnittstelle nicht bereitgestellt werden.

Noch ein Hinweis, falls die Eigenschaft doch von jemandem benötigt wird:
Die Bezeichnung "hasMembership" ist unglücklich gewählt. Dies suggeriert eine Wertezuordnung von true / false. Sollte dann vielleicht heißen: "membership" für eine IRI bzw. "membershiplist" für eine Objektiste.

[akuckartz]

Ich bin bei dieser Redundanz neutral.

Nur kurz zur Bezeichnung: Diese entstammt org:Organization und hat zudem durchaus ihren Sinn bei der Betrachtung der Daten als Tripel.

Für Objektlisten wird es nach aktuellem Stand voraussichtlich eine Lösung mittels einer allgemeinen Indirektionseigenschaft geben, die keine Verdopplung der Eigenschaften erfordert.

[sterni24]

OK, org.Organization führt diese Eigenschaften auf, wobei in der Grafik ein Schreibfehler von Agent zu Membership enthalten ist.

Falls diese Beziehungen in oparl:Organization und oparl:Person erhalten bleiben, sollten diese nochmals wie folgt angepasst

• oparl:Organization "hasMember" (bisher "member"),
• oparl:Person "memberOf" (bisher "organization", die schon gestrichen wurde)
• oparl:Person "hasMembership")
  und als ZWINGEND (mit möglichen Leerwerten) deklariert werden.

Allerdings bleiben meine Einwände, siehe oben und die nachteilige Performance bestehen.

[akuckartz]

@SternI Auf hasMember und memberOf können wir eventuell ganz verzichten und alles über die oparl:Membership-Objekte abbilden.

[akuckartz]

Ich bin aufgrund der Aussicht auf eine kurz nach OParl 1.0 erfolgende Ergänzung um Linked Data Fragments als Abfragesprache (#165) nun ebenfalls der Auffassung, dass auf inverse und damit redundante Eigenschaften verzichtet werden kann.

[marians]

Ich kann aus der DIskussion nicht den letzten Stand lesen. Mir ist folgendes wichtig:

• als Client möchte ich von einer Gruppierung auf ihre Mitglieder "browsen" können.
• als Client möchte ich von einer Person auf die Gruppierungen, in der diese Person Mitglied ist, "browsen" können.

Aktuell gehe ich davon aus, dass in beiden Fällen eine Liste von Membership-Objekten ausgegeben wird. Richtig?

In beiden Fällen stellt es für mich kein Problem dar, wenn auch vergangene Mitgliedschaften ausgegeben werden. Die Ausgabe vergangener Mitgliedschaften würde ich jedoch nicht als MUSS deklarieren (KANN oder EMPFOHLEN ist mir ehrlich gesagt egal).

Ist das aktuell gewährleistet?

[sterni24]

Diese issue kann seiner ursprünglichen Fragestellung nach geschlossen werden.