1. Die Bundle Ontologie
Zur Orientierung hier ein Exzerpt (eine Transklusion) von dieser Seite:
Die Bundle-Ontologie wurde von Ben 'O Steen in expliziter Anknüpfung an die coref-Ontologie entwickelt. Sie ist umfangreicher und berücksichtigt
- die Begründung zur Bündelung der URIs sowie
- umfangreichere Provenienzangaben (Akteur, Zeitpunkt) unter Rückgriff auf das Open Provenance Model Vocabulary.
In der Ontologiebeschreibung heißt es:
The Bundle ontology provides classes and properties which model the assertions made when a person, software agent or some other process asserts that one URI is likely to be the same another URI. The property 'owl:sameas' is of no use for this purpose, as it is a logical assertion and not a realistic one. The loss of context as to why, how and who made the decision to equate two or more URIs makes it very hard to use at all.
Klassen:
- bundle:Bundle: This class is used to represent a 'bundling' of URIs together, to make the assertion that the Agent who owns or has created this bundle believes that these URIs are the same. It is expected to be linked via the 'bundle:encapsulates' property to two or more URIs, and to be linked via 'bundle:justifiedby' to an bundle:Reason node, holding an OPMV graph detailing the how, where, what and why this link was made amongst other details.
- bundle:NotABundle: This class has the same form as a bundle:Bundle, but has the crucial distinction that it is used to represent a set of URIs that have been assert to not be the same by a given Agent.
- bundle:Reason: This class is used to represent the evidence and process by which a bundle:Bundle was made. As a Bundle is typically created by a probabalistic, NLP or human-driven methods, it is hard to qualify exactly what is necessary here without further usage of this technique. An OPMV graph is expected however to have this node as one of the 'Artifact's generated by the bundling process, hence it subclasses from opmv:Artifact.
- bundle:AlgorithmicReason: This class is used to represent the evidence, algorithm and any other metric that serves to provide a basis for the Bundle. Use of the bundle:algorithmicvector property may be helpful if a Felligi-Sunter or other approach with a vector/numeric confidence value had been taken.
- bundle:AgentReason: This class is used to represent the evidence, and as far as possible, the reason why an Agent (foaf:Person, etc) bundled these URIs together.
- bundle:CrowdsourcedReason: This class is used to represent the evidence as far as possible, for a crowd-sourced bundling of URIs. Typically, this will hope to reflect a mass attitude at a given time rather than anything concrete.
Properties:
- bundle:encapsulates: This property links together URIs to a given Bundle to form something like a congruent closure, but without any of the strengh, mathmatical or authoritative, that a logical closure would bring. It may be treated as one, if the process by which the Bundle is created is infalible, but as the author of this schema, I cannot think of any situation where that might happen. (Domain: bundle:Bundle)
- bundle:justifiedby: This property links a Bundle to the bundle:Reason artifact that provides it with context as to why and who created it and for what purpose. (Domain: bundle:Bundle, Range: bundle:Reason)
- bundle:algorithmicvector: This property holds a value for the result of the algorithmic matching process that created the bundle.
- bundle:comment: A human readable description for a given bundle:Reason. (Domain: union of bundle:Bundle & bundle:Reason)
2. Beispielumsetzung mit der Bundle-Ontology
Wir haben vier Datensätze aus der dem GBV, dem hbz, dem BVB und dem SWB, die als identisch erkannt wurden auf Basis der EKI-Gleichheit. Deren lokale Identifier lauten:
- GBV: 086051288
- hbz: TT050005321
- BVB: BV035413315
- SWB: 800003780
Die URLs zu den Repräsentationen der Titeldatensätze in den Verbund-OPACs lauten:
- http://gso.gbv.de/DB=2.1/PPNSET?PPN=086051288
- http://193.30.112.134/F/?func=find-c&ccl_term=IDN%3DTT050005321
- http://opac.bib-bvb.de:8080/InfoGuideClient.fasttestsis/start.do?Query=-1="BV035413315"
- http://pollux.bsz-bw.de/DB=2.1/PPNSET?PPN=800003780
http://culturegraph.org/bundle/1 sei die EKI des bundles, das diese vier Titeldatensätze als äquivalent zusammenfasst.
urn:nbn:de:eki/GBVNLM003525147 sei die neu geprägte URI der FRBR-Manifestation, die durch die gebündelten Titelsätze beschrieben wird.
Wie sollen diese Aussagen in RDF dargestellt werden?
Hier das Beispiel in Turtle:
http://culturegraph.org/bundle/1 rdf:type bundle:Bundle bundle:encapsulates http://gso.gbv.de/DB=2.1/PPNSET?PPN=086051288 ; bundle:encapsulates http://193.30.112.134/F/?func=find-c&ccl_term=IDN%3DTT050005321 ; bundle:encapsulates http://opac.bib-bvb.de:8080/InfoGuideClient.fasttestsis/start.do?Query=-1="BV035413315" ; bundle:encapsulates http://pollux.bsz-bw.de/DB=2.1/PPNSET?PPN=800003780 ; bundle:justifiedby http://culturegraph.org/bundlereason/EkiEquivalence . http://culturegraph.org/bundlereason/EkiEquivalence rdf:type bundle:AlgorithmicReason ; bundle:comment "Die Titeleinträge in den entsprechenden Bundles sind aufgrund einer Übereinstimmung der EKI als gleich identifiziert worden."@de .
Fragen:
- Wie wird die Beziehung zwischen der Manifestations-URI und den Titelsatz-URIs hergestellt? Kann man einfach sagen
? (Ich benutze hier das POWDER-Prädikat http://www.w3.org/2007/05/powder-s#describedby.)
urn:nbn:de:eki/GBVNLM003525147 wdrs:DescribedBy http://culturegraph.org/bundle/1
- Ist es nicht evtl. falsch diese Beziehung zwischen der Manifestations- und der Bündel-URI herzustellen? Sollte man nicht eher für jede einzelne URL in dem Bündel die entsprechende Aussage generieren?
Die angedeutete mögliche Lösung könnte dann graphisch etwa so aussehen:
Allerdings gibt es ja mit entstehenden Linked-Data-Diensten weitere URIs für diese Manifestation, die dementsprechend gebündelt werden müssen, in unserem Fall etwa http://lobid.org/resource/TT050005321. Das ist ja das eigentliche Ziel dieses Projekts: dezentral generierte URIs für bibliographische Ressourcen (FRBR-Manifestationen) zu verknüpfen. Aus diesem Grund lässt sich die Graphik wie folgt erweitern:
6 Kommentare
Pascal Christoph sagt:
01.02.2011Wenn Du diese Beziehung zwischen der Manifestations- und Bündel-URI nicht herstellen willst, und statt dessen die Manifestations-URIs einzeln mit allen Titelsatz-URLs aus dem Titelsatz-Bundle durch wdrs:describedBy verbinden willst (wie in dem 1. Schaubild gezeigt), stellt sich mir die Frage warum die dann überhaupt gebündelt werden sollen? Denn ein Problem wird sofort ersichtlich:
Im Szenario "es kommt eine neue Titelsatz URL hinzu" müsstest Du
1. die URL in das Bundle integrieren
2. die URL mit der Manifestations URI durch wdrs:describedBy verknüpfen
und wenn Du einen der Punkte vergessen solltest hast Du blöde Inkonsistenzen. Also, wenn da ein Einfallstor zu Fehlern durch das Design gegeben ist, dann ist das Design schlecht (oder gibt es die vonmir behauptetet Inkonsistenz nicht?).
Die Frage ist: warum ist es denn falsch diese Beziehung zwischen der Manifestations- und der Bündel-URI herzustellen? Was spricht genau dagegen? Denn eigentlich will einer ja das haben was Du händisch in Schaubild 1 darstellst, nur eben implizit durch die In-Beziehung setzen der Manifestations-URI mit dem Bundle. Meiner Auffassung nach ist das auch so, allerdings bin ich nicht der Experte, - was sind Deine Zweifel? Lässt sich das Bündel nicht übersetzen durch "alle Aussagen die über dieses Bündel gemacht werden sind in Wirklichkeit Aussagen über alle Elemente in dem Bündel? Ich verstehe die Bundle Ontologie nämlich so wie gerade beschrieben, s.a. "to make the assertion that the Agent who owns or has created this bundle believes that these URIs are the same." Eine Aussage über das Bünel sind Aussagen über die URIs in dem Bündel, dafür genau ist das doch da.
Dann bleibt bei mir noch eine ganz grundsätzliche Frage, warum die Titelsatz-URIs gebündelt werden sollen: denn die Datensätze sind ja durch eine EKI-Gleichheit mit owl:sameAs verbunden. D.h. doch dass die vier verschiedenen Verbund-Manifestations-URIs verbunden sind durch owl:sameAs. Da nun jede Manifestations-URI durch eine Titelsatz-URL "described" wird, führt damit automatisch eine Anfrage "gib mir die URLs zu den Repräsentationen der Titeldatensätze der EKI foo:bar" zu dem Ergebnis aller vier Titeldatensatz-URLs. Oder was habe ich nicht verstanden?
Adrian Pohl sagt:
01.02.2011Danke für deinen ausführlichen Kommentar. Du hast recht, dass es sicherlich unsinnig ist, die URIs einerseits zu bündeln und andererseits die Beziehung wdrs:describedBy zwischen den gebündelten URI und der Manifestations-URI herzustellen. Das ist eine Dopplung derselben Aussage und ist - wie du sagst - ein Beispiel für schlechtes Design.
Es ist falsch, weil dieselbe URI gleichzeitig für zwei Dinge - also nicht eindeutig - verwendet wird. Einmal als "kanonische" URI für das, was die gebündelten URIs koreferenzieren und zum anderen als URI für das Bundle, für eine Menge von URIs. Wenn ich die Aussage mache
sage ich etwas über das Bündel von URIs und wenn ich sage
spreche ich über die durch die gebündelten URIs koreferenzierte Resource. Das ist inkonsistent und sollte vermieden werden.
Die coref-Ontologie hat als Lösung dieses Problems das Prädikat coref:canon, das wie folgt beschrieben wird: "The Canonical URI that should be used for all URIs in its bundle." Eine ähnliche Lösung fehlt bei der bundle-Ontologie. Man könnte eventuell auch einfach nur eine der gebündelten URIs verwenden und die restlichen Aussagen auf dieser Basis inferieren, allerdings kann man dann evtl auch gleich owl:sameAs nutzen.
Apropos owl:sameAs:
Wir wollten ja eigentlich eben nicht owl:sameAs benutzen, weil es eine zu starke Aussage ist und weil wir auch noch URI-Bündel auf der Basis andere Matching-Algorithmen (ISBN, BibKey etc.) herstellen wollen. Deshalb habe ich ja überhaupt erst diese Koreferenz-Vokabulare untersucht, um diese verschiedenen Äquivalenzklassen abbilden zu können. Eine Anwendung derselben scheint auf jeden Fall gar nicht so trivial zu sein.
Ich möchte hier noch unterstreichen, dass diese Problematik wegfallen würde, wenn wir es eben nur mit Manifestations-URIs wie http://lobid.org/resource/TT050005321 oder urn:nbn:de:eki/GBVNLM003525147 zu tun hätten, weil dann die Beschreibungseben weggekürzt wäre und die Beziehung zwischen Entität und Beschreibung nicht abgebildet werden müsste. Davon sind unsere ursprünglichen Überlegungen auch ausgegangen. Vielleicht habe ich ja auch nur mit der Unterscheidung Manifestation-Beschreibung ein Problem aufgebaut, was leicht gelöst werden kann, indem wir uns allein auf der Manifestations-Ebene begeben. Das hieße: http://lobid.org/resource/TT050005321, urn:nbn:de:eki/GBVNLM003525147 etc. bündeln und die urn:nbn:eki (als kanonische EKI) mit den einzelnen Beschreibungen durch Nutzung von wdrs:describedBy verbinden...
Pascal Christoph sagt:
01.02.2011Auf die Gefahr hin dass ich jetzt was falsch sehe (nur so kann es ja korrigiert werden
) - du schriebst einleitend:
nun steht da 1. "als identisch erkannt" und 2. "auf Basis der EKI-Gleihheit", und das , nämlich die EKI-Gleichheit, ist für mich tatsächlich der Grund die Manifestations-URIs durch owl:sameAs zu verbinden (und durch nichts anderes!). Du schreibst dass wir später auch unschärfere Matchings haben werden, und für diese ist natürlich richtig dass wir eine schwächere Referenzierungsstrategie benötigen, aber erst für diese.( M.E. sollte da wirklich ein Schlussstrich gesetzt werden - denn die EKI war auch so von der AG-KVA als "owl:sameAs" gedacht gewesen.)
Danke für den immer wieder erhellenden Satz:
Allerdings muss es da irgendeinen Trick geben, sonst halte ich dieses Bündeln für nicht befriedigend. OK, in der coref-Ontologie gibt es sowas wie coref:canon - dann muss sowas eben für die bundle-Ontologie erfunden werden (benosteen anschreiben). Du schreibst weiter:
Ah - das ist wahrscheinlich das was benosteen beschreibt unter dem Stichwort "Binding". Benosteen sagt aber im vorigen post, wo er die bundle-Ontologie vorstellt) :
Ich verstehe dass so, dass es sich bei Bündeln um "dynamische, nämlich kontextabhängige" owl:sameAs (oder eben: nicht owl:sameAs (ich gebe zu, das ist binär gedacht. Aber es ließen sich wohl noch andere Inferenzen bilden, mit anderen, schwächeren Referenzprädikaten? Dann wäre das nicht mehr nur binär)) handelt (ich verwende hier extra owl:sameAs). Und nichts anderes als das tust Du doch, wenn du die EKI durch wdrs:describedBy mit allen Titeldatensaetzen-URLs verbindest, mit dem Trick, da die EKI und die Titeldatenstz-URLs aber im Bundle sind, dass die Aussagen darüber "wackelig(=kontextabhängig)" und nur "wenn du willst" als tatsächlich identisch verwendet werden. Worauf ich hinaus will ist das wir auf das M.E. redundante, deklarative wdrs:describedBy verzichten können und stattdessen das Wissen funktional (also:algorithmisch) ableiten. Wie das auch immer genau aussehen mag, aber ich habe es so verstanden dass das möglich ist.
Adrian Pohl sagt:
03.02.2011Deinem ersten Punkt - der Nutzung von owl:sameAs bei EKI-Gleicheit - kann ich nur unter der Bedingung zustimmen, dass klar ist, was denn diese Dinge sind, die hier gleichgesetzt werden. Wenn man - wie wir es hier tun - sagt, dass es um FRBR-Manifestationen geht, die durch diese und jene Eigenschaften definiert sind, dann mag das passen; vorausgesetzt natürlich die Katalogisierungspraxis in Deutschland ist wirklich einigermaßen einheitlich (d.h. es werden wirklich Katalogisate für die gleichen Entitäten angelegt). Das Problem ist, dass FRBR in culturegraph bisher keine Rolle spielt.
Dem Rest deines Kommentars kann ich nur zustimmen, ich verstehe unter dem Zweck des Bundles dasselbe (bis auf dein Verständnis von Binding, was hier aber nicht so wichtig ist) wie du.
Genau, allerdings muss dann mindestens zwischen einer gebündelten URI (und nicht der Bundle-URI) und der Manifestations-URI die Beziehung wdrs:isdescribedby ausgesagt werden, um irgendetwas inferieren zu können.
Pascal Christoph sagt:
04.02.2011Hm. In Deinem selbstkonstruierten Beispiel oben unter 4. gehst Du aber davon aus dass es sich um FRBR-Manifestationen handelt :
Müssen wir die AG-KVA fragen ob die mit einer EKI versehenen Titelsätze tatsächlich auch immer das Gleiche aussagen (wenn zwei Verbünde die selbe EKI haben, beschreiben sie das Gleiche)? Ich dachte genau dafür ist die EKI erfunden worden, und zwar egal ob nun die EKI Manifestationen identifiziert oder auch Work oder was-auch-immer. Und da, wo die Katalogisierungspraxis auseinanderläuft (wie, glaube ich, bei manchen Überordnungen/Unterordnungen (Stichwort: beck "schwarze reihe")) gibt es wohl auch keine EKI (nachfragen bei AG-KVA!).
Ich möchte nochmal sagen: wir brauchen kein Bundle wenn die cg-URI die Titeldatensätze "bündelt" solange der Grund dieser "Bündelung" die Gleichheit der EKI ist. Dann sind die im "Bündel" enthaltenen URIs mit owl:sameAs zu verbinden - und die cg-URI ist dann auch owl:sameAs zu den Titeldatensatz-URIs, oder wie wird das technisch umgesetzt, habe ich das richtig verstanden?
Für diese Titeldatensaetze braucht es dann kein Bündel um auf wdrs:describedBy zu gelangen weil ich ein SPARQL machen kann der mir automatisch alle descriptions der Titeldatensaetze holt, wenn denn auch die OPAC-URLs da irgendwo mitverspeichert werden. Werden sie momentan nicht. Wie machen wir das, oder habe ich hier ein falsches Verständnis, geht das überhaupt, dürfen wir das?
Anonym sagt:
12.12.2011Lieber Herr Pohl,
einer, der vorher nicht gewußt hat, was eine bundle ontology ist, weiß es auch nach Ihrer Erklärung ganz oben nicht. Hinter einer Erklärung muss der Wille stecken, dass der Leser dann genau versteht, worum es geht. Ich würde mich freuen, wenn Sie es einfacher und strukturierter erklären würden. Vielen Dank!
Mit freundlichen Grüßen
Maurizio Grilli