naustica / bim-108-01-solutions Goto Github PK

Hallo @naustica

Sehr gut. Bei der letzten Aufgabe ist ganz interessant, dass die Daten nicht lokal vorhanden sind sondern über ein Web Service abgefragt werden. Das ist ein wesentlicher Unterschied zu den anderen Aufgaben.

Glückwunsch, @naustica ... bist der einzige der alle Übungen eingereicht hat!

Sehr gut!

Die XML Syntaxregeln erwarten, dass ein Element eindeutig benannte Attribute hat. Deine Korrektur ist somit richtig. Alternativ hätte man das eine Attribut auch unbennenen können, z.B. year="The Wall". Bemerke, dass es der Software erstmals "egal" ist ob das Sinnvoll ist.

Also Vorschlag, die Datei lecture-01.ipynb noch in ein Verzeichnis lecture-01 packen. Nicht unbedingt nötig aber für die weiteren Lösungen keine schlechte Idee.

Hallo @naustica

Betreffend Syntax und Semantik:

eq(Literal('1973'), Literal('1973', datatype=XSD.int)) 
# Erklärung: Da es sich beim rechten Literal um ein typisiertes Literal handelt und links um ein untypisiertes Literal, sind die Literale syntaktisch ungleich.

Datentypen ermöglichen eine Interpretation des Wertes, z.B. '1973'. Mittels Interpretation (als Prozess) erhält man Bedeutung (Semantik). Also, sind die Literale insb. semantisch ungleich, eben weil die Interpretation der Werte '1973' einmal als Zeichenfolge und einmal als Zahl unterschiedliche Bedeutung haben. Syntaktisch sind die Literale aber schon auch ungleich.

gday und gmonth schreibt man (glaubs, nachprüfen!) gDay und gMonth. Ähnlich wie gYear.

Übrigens, gMonth schreibt man --01, --02, etc. Habe noch nicht rausgefunden warum das -- nötig ist, aber es ist so. Ich habe das in der XML Schema Lösung noch aufgenommen.

Die Aufgabe geschlossene Liste ist keine Liste und nicht geschlossen. Schau nochmals die Turtle Syntax für geschlossene Listen an.

Sehr gut, @naustica

Bei

rdf = """
[TODO]
"""

g = Graph()
r = g.parse(data=rdf, format='[TODO]')
print(g.serialize(format='[TODO]').decode('utf-8'))

ist die Idee, dass du das vorherige RDF/XML hier als Input nimmst und dann nach N-Triples konvertierst. Also, überall wo [TODO] steht muss man etwas ersetzen.

Hallo @naustica

g = Graph()
g.bind('ex', ex)
aAlbum = uri()
g.add(statement(aAlbum, RDF.type, uri('Album')))
g.add(statement(aAlbum, uri('title'), Literal('The Dark Side of the Moon')))
visualize(g)

Dieser Graph hat 2 (!) Kanten, rdf:type und ex:title. Nicht von der Visualisierung beirren lassen.

Hier

g = Graph()
g.bind('ex', ex)
aAlbum = uri()
g.add(statement(aAlbum, RDF.type, uri('Album')))
g.add(statement(aAlbum, uri('title'), Literal('The Dark Side of the Moon')))
g.add(statement(aAlbum, uri('label'), Literal('Harvest, EMI')))
g.add(statement(aAlbum, uri('releasedOn'), Literal('1973-03-16')))
g.add(statement(aAlbum, uri('released'), bn))
g.add(statement(bn, uri('year'), Literal('1973')))
g.add(statement(bn, uri('month'), Literal('03')))
g.add(statement(bn, uri('day'), Literal('16')))
visualize(g)

Auch hier. Dieser Graph hat 8 Statements. Ein Statement setzt sich aus zwei über eine Kante verbundene Knoten, also drei Elemente: Knoten1, Kante, Knoten2. Jede g.add() Anweisung fügt dem Graphen g ein Statement hinzu.

Im eigenen Beispiel wird uri('author') sowohl als Objekt als auch als Prädikat verwendet. Das ist in RDF möglich, aber es wird dann bei RDF Schema klar, dass dies nicht sinnvoll ist.

Hallo @naustica

Bei

query("""
SELECT ?title WHERE { 
  [] ex:title ?title
}
""")

# Was ist der Unterschied zum vorherigem Beispiel? Antwort: der Spaltenname work taucht nicht auf, da er in der Abfrage auch nicht auftaucht. Dadurch wird auch kein Listenpunkt "work" erstellt.

kann man auch noch sagen, dass [] ein blank node ist (non-distinguished variable) und diese kann man in der Resultatsmenge nicht angeben.

Bei

query("""
SELECT ?title WHERE { 
  [] rdf:type ex:Album ; 
     ex:title ?title
}
""")

# Warum nur zwei Resultate? Antwort: weil "What God Wants, Part 1" den Präix ex:single hat. Hier wird explizit nach rdf:type:ex:album gefragt.

ist ex:Single kein Präfix. Das ist der Typ der URI im Subjekt. Bei RDF Schema wird das dann eher klar: Es handelt sich um eine Klasse, eine Menge, wobei die Subjekt URI <uri> mittels <uri> rdf:type ex:Single als Instanz dieser Menge definiert wird.

Hallo @naustica

 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"><xs:sch 
  <xs:element name="title" type="xs:string"/>
</xs:schema>

isvalid(xsd, '<title>1973</title>') # Warum ist dieses Dokument gültig? Antwort: Der Elementtyp wird als String definiert. Hier ist allerdings eine Zahl verbaut.

Dies ist gültig weil die Zahl automatisch als string interpretiert wird. Das geht natürlich nicht, wenn das Schema eine Zahl spezifiziert und das Dokument Text hat.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="work" type="WorkType"/>
  <xs:element name="album" type="AlbumType"/>
  <xs:complexType name="WorkType">
    <xs:sequence>
      <xs:element name="title" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="AlbumType">
    <xs:complexContent>
      <xs:extension base="WorkType">
        <xs:sequence>
          <xs:element name="label" type="xs:string"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
 </xs:complexType>
</xs:schema>

Bei diesem Schema ist es so, dass der AlbumType auf dem WorkType aufbaut. WorkType deklariert zuerst das Element title und erst AlbumType das Element label. Somit ist die Sequenz title, label.

Hallo @naustica

:album rdf:type rdfs:Class.
:r1 rdf:type :album.
:album rdf:type rdfs:Class.
:r2 rdf:type :album.
:single rdf:type rdfs:Class.
:r3 rdf:type :single.
:r1 :title "The Dark Side of the Moon" .
:r2 :title "The Wall" .
:r3 :title "What God Wants, Part 1" .

Zwar nicht falsch, aber es genügt :album rdf:type rdfs:Class einmal zu deklarieren. Man muss das nicht tun jedes mal man die Klasse verwendet (z.B. in rdf:type statement). Per Konvention werden übrigens Klassen gross geschrieben, also :Album nicht :album. Das ist aber nur eine Konvention, wie bei Programmiersprachen.

Das pattern '?work rdf:type :Work .' selektiert alle unterklassen von :Work, '?work :title ?title .' 
selektiert daraufhin die Titel mit dem prädikat :title. Würde man statt :work :album benutzen 
würde man nur die unterklassen von album selektieren.

Streng genommen selektiert hier das triple pattern ?work rdf:type :Work in der Tat nur nach Instanzen der Klasse :Work. Davon gibt es aber drei, denn die Klasse :Work hat zwei Unterklassen mit insgesamt drei Instanzen. Diese sind auch automatisch Instanzen der Überklasse :Work. Wenn du dir die Hilfsfunktion reason() oben anschaust siehst du, dass die Software zuerst diese impliziten Klassenzugehörigkeiten zuerst auflöst und dann die SPARQL Abfrage ausführt.

Aber deine Erklärung ist nicht ganz falsch. Man kann in der Tat es auch so implementieren wie du es beschreibst, also die ursprüngliche SPARQL Abfrage so ändern, dass auf Unterklassen von :Work selektiert wird. Dem sagt man "reasoning at query time", also Inferenzen (implizite Aussagen) werden zur Zeit der SPARQL Abfrageausführung aufgelöst.

Dem ersteren sagt man "materialization", weil die Inferenzen materialisiert werden, sprich, die Ursprungsdaten werden mit den impliziten Aussagen zuerst erweitert. Diese stehen dann auch explizit in den Daten zur Verfügung. Die Daten werden somit grösser (man erhält mehr Tripel). Bei "reasoning at query time" bleiben die Daten gleich.

Perfekt, @naustica!

Sehr gut!

Im Codeblock für das Beispiel mit Namensräume gibt es ein Fehler (der war bis kurz vor der Vorlesung letzte Woche noch in meinem Code).

Folgendes

d = ("""
<disc:discography xmlns:disc="http://discography.org" xmlns:alb="http://albums.org" xmlns="http://default.org">
<alb:albums>
<alb:album title="The Dark Side of the Moon" alb:year="1973"/>
</alb:albums>
</disc:discography>
""")

sollte so korrigiert werden

d = et.fromstring("""
<disc:discography xmlns:disc="http://discography.org" xmlns:alb="http://albums.org" xmlns="http://default.org">
<alb:albums>
<alb:album title="The Dark Side of the Moon" alb:year="1973"/>
</alb:albums>
</disc:discography>
""")

Sehr gut.

Ein Vokabular setzt sich aus "Terme" zusammen und Regeln wie diese benutzt werden. Bei Buchsammlung gibt es z.B. die folgenden Terme: Buch, Titel, Author, Jahr, Verlag, ISBN. In XML können diese Terme entweder Elemente oder Attribute sein, damit diese Daten über konkrete Bücher und Sammlungen aufnehmen können. Nun gibt es viele mögliche Kombinationen.

Beispiele:

So können unterschiedliche Systeme die gleichen XML Daten ganz anders darstellen. Das hindert Interoperabilität, denn man kann diese Daten nicht so einfach austauschen. Deshalb ist es wichtig, dass man sich auf ein Vokabular eignet.