XML und Datenbanken Kapitel 7: Modellierung, Teil 2

1. XML und DatenbankenKapitel 7: Modellierung, Teil 2 Meike Klettke Universität Rostock Fakultät für Informatik und Elektrotechnik meike@informatik.uni-rostock.de www.xml-und-datenbanken.de

2. Inhalt Teil 1: • Motivation, warum ein Schema erforderlich ist • Schemata für XML-Dokumente • DTDs • XML Schema Teil 2: • konzeptuelle Modellierung • 1. Vorteile einer Modellierung • Methoden zur konzeptuellen Modellierung • 2. Verwendung des Entity-Relationship-Modells • 3. Einsatz von UML • 4. Graphbasierte Verfahren • 5. eigener Ansatz • 6. Ableitung von Schemainformationen aus XML-Dokumenten • 7. Metriken • 8. Weiterführende Literatur • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

3. 1. Vorteile einer konzeptuellen Modellierung Wunschvorstellung: • Modellierung auf einem höheren Niveau, das von der konkreten Realisierung im Schema zunächst unabhängig ist • soll von Domainexperten verstanden werden • direkte Übersetzung in ein XML-Schema möglich • Enthält keine Implementierungsdetails • Schrittweise Konkretisierung • Graphische Darstellung Ziel: • höhere Qualität der Dokumente - exakteres Vorgehen es gibt noch keine akzeptierte Modellierungssprache für den Entwurf von XML/DTD/XML-Schemata. Häufig wird auch „Reverse-Engineering“ angewendet, aus XML- Dokumenten erfolgt die Ableitung der DTD durch Tools. • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

4. Modelle • Modelle werden heute in allen Wissenschaftsgebieten eingesetzt • weit akzeptierte allgemeine Modelltheorie wurde 1973 von Herbert Stachowiak vorgeschlagen. • Modellbegriff darin ist domänenübergreifend anwendbar, Modell hat drei Eigenschaften: • Abbildung: Modell ist immer ein Abbild von etwas, eine Repräsentation natürlicher oder künstlicher Originale, die selbst wieder Modelle sein können. • Verkürzung: Ein Modell erfasst nicht alle Attribute des Originals, sondern nur die jeweils relevanten • Pragmatismus: Orientierung am Nützlichen, Fragen wie Für wen?, Warum? und Wozu? werden berücksichtigt

5. Beispiel eines Modells • maßstabgetreues 1:100-Modell des Stephansdoms • originalgetreue, detailreiche Modell für blinde und sehbehinderte Menschen • Auch Kindern wird es damit erleichtert, die Dimensionen der Kirche zu "begreifen"

6. Modellierungsmethode für XML • einige Vorschläge für XML-Modelle und Modellierungmethoden • Ziele dabei sollen sein: • so einfach wie möglich • so komplex wie nötig • Vollständige XML-Schema-Unterstützung • Verwendung von Defaultwerten und Voreinstellungen entgegengesetzte Eigenschaften

7. Konzeptueller Entwurf von XML- Dokumenten konzeptuelle Ebene Möglichkeiten zur Modellierung ?? konzeptuelle Ebene • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur Modellierung von Struktur und Inhalt dok-zentriert baumbasierte XML-Editoren Modellierung von semi- strukturiert Struktur und Inhalt ?? Modellierung von Struktur datenzentriert ER UML ORM

8. 2. Entity-Relationship-Modell für den Datenbankentwurf/ 1 • Für den Datenbankentwurf Verlag gibt_heraus Buch schreibt Autor • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur Name Verlag Ort [1,n] gibt_ heraus [1,1] Titel Buch ISBN [1,n] schreibt [0,n] Name Autor Vorname ID

9. Entity-Relationship-Modell für den Datenbankentwurf/ 2 • jede Darstellung im ER findet Entsprechung in relationalen Datenbanken • Entwurf auf einen abstrakteren Level (konzeptuell) • Eindeutige Abbildung der Entity-Relationship-Diagrammes • Alle relevanten Informationen einer relationalen Datenbank können aus dem Entwurf abgeleitet werden • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

10. Entity-Relationship Modell für DTDs • Für den Entwurf von DTDs • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur Name <!ELEMENT Buchanwendung (schreibt*, Verlag*,Autor*)> <!ELEMENT Verlag (gibt_heraus*)> <!ATTLIST Verlag Name ID #REQUIRED Ort CDATA #REQUIRED> <!ELEMENT gibt_heraus (Buch)> <!ELEMENT Buch EMPTY> <!ATTLIST Buch Titel CDATA #REQUIRED ISBN ID #REQUIRED> <!ELEMENT schreibt EMPTY> <!ATTLIST schreibt Buch_ref IDREF #REQUIRED Autor_ref IDREF #REQUIRED > <!ELEMENT Autor EMPTY> <!ATTLIST Autor Name CDATA #REQUIRED Vorname CDATA #REQUIRED ID ID #REQUIRED> Verlag Ort [1,n] gibt_ heraus [1,1] Titel Buch ISBN [1,n] schreibt [0,n] Name Autor Vorname ID

11. Entity-Relationship Modell für XML-Schemata /1 • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur Name Verlag <Buchanwendung> <schreibt Buch_ref="i1234-5678-9" Autor_ref="a0007"/> <schreibt Buch_ref="i9876-5432-1" Autor_ref="a0008"/> <schreibt Buch_ref="i9876-5432-1" Autor_ref="a0009"/> <Verlag Name="dpunkt" Ort="Heidelberg"> <gibt_heraus> <Buch Titel="XML und Datenbanken" ISBN="i1234-5678-9"/> </gibt_heraus> <gibt_heraus> <Buch Titel="Web und Datenbanken" ISBN="i9876-5432-1"/> </gibt_heraus> </Verlag> <Autor Name="Meyer" Vorname="Holger" ID="a0007"/> <Autor Name="Rahm" Vorname="Erhard" ID="a0008"/> <Autor Name="Vossen" Vorname="Gottfried" ID="a0009"/> </Buchanwendung> Ort [1,n] gibt_ heraus [1,1] Titel Buch ISBN [1,n] schreibt [0,n] Name Autor Vorname ID

12. Entity-Relationship Modell für XML-Schemata/ 2 • Abbildung nicht einfach nachvollziehbar • Unterschiedliche Behandlung der Kardinalitäten 1:n und n:m • Abbildung der Schlüssel auf ID (nicht das identische Konzept) • Keine Möglichkeit zur Darstellung von Alternativen, Mixed Content und ANY • Entity-Relationship-Modell bietet Konzepte, die sich nicht einfach abbilden lassen und es gibt Konzepte in XML, die sich nicht im Entity-Relationship-Modell darstellen lassen • Verwendet werden kann also „erweiterte Untermenge“ • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

13. 3. Einsatz von UML – Klassendiagrammen /1 • Darstellung von Elementdeklarationen durch Klassen • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur adresse ort plz <!ELEMENT (ort, plz, strasse, strasse hausnummer, postfach?> hausnummer postfach [0..1]

14. Einsatz von UML –Klassendiagrammen /2 • Darstellung vom Inhaltsmodell Sequenz • Deklaration von Attributen • (UML-Konstrukt: Aggregation, Teil-Ganzes-Beziehungen zwischen einem Aggregat und seinen Teilen) • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur hotel <<meta>> url:CDATA <<meta>> datum[0..1]:CDATA <<meta>> autor [0..1] CDATA <!ELEMENT hotel (hotelname, kategorie?, adresse> <!ATTLIST hotel url CDATA #REQUIRED datum CDATA #IMPLIED autor CDATA #IMPLIED> 0..1 hotelname kategorie adresse

15. Einsatz von UML –Klassendiagrammen /3 • Darstellung von Alternativen • (UML-Konstrukt: Generalisierung, Ist-Ein-Beziehungen zwischen Klassen) • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur unterkunft <!ELEMENT unterkunft ( hotel | pension | ferienwohnung )> {disjoint} hotel pension ferienwohnung

16. Komplexeres Beispiel hotel <<meta>> url:CDATA <<meta>> datum[0..1]:CDATA • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur <<meta>> autor [0..1] CDATA {sequence : 1} 0..1 1..n hotelname kategorie adresse telefon preise {sequence : 1} {choice : 0 .. n} plz ort strasse hausnummer einzelzimmer doppelzimmer apartment <<content>> #PCDATA <!ELEMENT adresse (ort, plz, strasse, hausnummer)><!ELEMENT ort (#PCDATA)><!ELEMENT plz (#PCDATA)><!ELEMENT strasse (#PCDATA)><!ELEMENT hausnummer (#PCDATA)><!ELEMENT preise (#PCDATA | einzelzimmer | doppelzimmer | apartment )*><!ELEMENT einzelzimmer (#PCDATA)><!ELEMENT doppelzimmer (#PCDATA)><!ELEMENT apartment (#PCDATA)> <!ELEMENT hotel (hotelname, kategorie?, adresse, telefon+, preise)><!ATTLIST hotel url CDATA #REQUIRED><!ATTLIST hotel datum CDATA #IMPLIED><!ATTLIST hotel autor CDATA #IMPLIED><!ELEMENT hotelname (#PCDATA)><!ELEMENT kategorie (#PCDATA)><!ELEMENT telefon (#PCDATA)>

17. Bewertung • In beiden Fällen • „erweiterte Untermenge“ wird eingesetzt, das heißt: • Einige Konstrukte des ERM bzw. aus UML lassen sich nicht adäquat abbilden • Beispiel n:m-Kardinalitäten • Andere Bestandteile einer DTD oder eines XML Schemas lassen sich nicht geeignet darstellen • Beispiel mixed content • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

18. 4. Verwendung von Editoren • Visualisierung der Baumstruktur der XML-Dokumente oder der Graphstruktur der Schemata • Beispiel XML Spy • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

19. 5. CoDEX-Modell (für Entwurf und Evolution) • Grundbestandteile: • Elemente, • Attributgruppen, • einfache und komplexe Typen, • Module • weitere spezielle Knoten für Inhaltsmodelle • Sequenz, Alternative, mixed Content • Verbindungen dazwischen: gerichtete und ungerichtete Kanten • Rootknoten= „Einstiegsknoten“ • Beschreibungen zu den Knoten (z.B. Wertebereichsbeschreibungen, facets)

20. CoDEX - Beispiel • Graph, verschiedene Knotenarten von Knoten (Elemente, Module, Inhaltsmodelle, Typen) • Rootknoten (ausgezeichnete Elemente oder Module) • Operationen darauf: • Eigenschaften testen (erlaubte Zustände) • Übersetzung in XML-Schema, dazu Übersetzungsreihenfolge bestimmen

21. Verwendung von Modulen im CoDEX-Modell • Graphische Notation: wie UML-packages • Zuordnung von XML-Schemata (können auch durch den CoDEX-Editor erzeugt sein)

22. Model Driven Engineering • Automatische Modellvervollständigung • Beispiel: • Ergänzen von • simple Types • complex Types • Inhaltsmodellen

23. Eigenschaften der Modellierungsmethode • Einfache graphische und formale Notation • Übersetzung in XML-Schemata • Vorteile: • Vollständige Modellierung von XML-Schemata möglich (einiges fehlt in der Implementierung: Typhierarchien, list, union) • Modularisierung möglich • Nachteile: • kein richtiges „konzeptionelles“ Modell, es fehlt die Vereinfachung • dafür aber automatische Vervollständigung vereinfachter Modelle • Weitere Eigenschaften • Reverse-Engineering: vorhandenes XML-Schema -> CoDEX • Einsatz des Verfahrens zur Evolution (Weiterentwicklung, Propagieren der Änderungen, ...)

24. Formales Modell von CoDEX • Graph, mehrere Arten von Knoten • Elemente • Attributgruppen, • Module • einfache Typen • komplexe Typen • Inhaltsmodelle (sequence, choice, all) • zwei Arten von Kanten: gerichtet und ungerichtet • ungerichtete Kanten nur während des Entwurfes • Rootknoten (gekennzeichnete Elemente oder Module) • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

25. Übersetzung: CoDEX in XML-Schema • zunächst: • Modellprüfung und • Modellvervollständigung • dann Übersetzung: • Darstellen der Adjazenzmatrix zum Graphen, in dieser sind die Knoten und ihre Kanten enthalten • Übersetzung beginnt bei den Rootkonzepten • im nächsten Schritt Übersetzung der Konzepten, von denen eine Kante zu den Rootkonzepten besteht • Übersetzung erfolgt bis alle Knoten des Graphen übersetzt sind • erzeugt wird Schema im Modellierungsstil Venetian Blind • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

26. Weitere Eigenschaften des Entwurfstools • Reverse-Engineering ist möglich • erster Schritt: • Umwandlung eines Schemas in Modellierungsstil Venetian Blind • zweiter Schritt: • Erstellen des zugehörigen CoDEX-Modells (Verwenden eines automatischen Layouts) • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

27. damit • verschiedene Entwurfsverfahren vorgestellt • alle haben auch Nachteile • entweder nicht alles darstellbar, was XML-Schema darstellen kann oder • nicht einfach genug, weil zu detailliert • bisher außer den XML-Editoren keine Methode etabliert • jetzt: weiterer Punkt, wenn zu XML-Dokumenten kein Schema bekannt ist, so kann dieses aus den Dokumenten abgeleitet werden • Verfahren dazu folgen anschließend

28. Ableitung von Schema-Informa-tionen aus Dokumentkollektionen • Ableitung eines Schemas für ein oder mehrere gegebene XML-Dokumente • Reverse-Engineering • Beispielkollektion ausreichend groß und vielfältig • Sonst ist die abgeleitete DTD zu speziell • abgeleitete Schemabeschreibung soll durch einen Anwender überprüft werden • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

29. Schemaableitung (DTD) Die folgenden 7 Folien stammen im Wesentlichen aus dem Hauptseminarvortrag von Matthias Brückner. Mögliche Herangehensweisen • Umwandlung der textuellen Repräsentation der Dokumente (XTRACT) • Betrachtung der Dokumente als XML–Trees (DTD-Miner) Eingabe • Menge von XML-Dokumenten Ausgabe • DTD für die gegebene Dokumentkollektion • Ergebnis soll • allgemein gehalten sein (für weitere XML-Dokumente), aber • auch speziell genug für die betreffende XML-Kollektion • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

30. DTD-Miner • DTD Generation Module • Document Tree Extraction Sub-Module • Umwandlung der XML Dokumente in eine Baumstruktur • Spanning Graph Construction Sub-Module • Zusammensetzen der Dokumentbäume zu einem zusammenhängenden Graphen • DTD Construction Sub-Module • Ableiten einer DTD aus dem zusammenhängenden Graphen • Anwendung von Heuristiken • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

31. DTD-Miner (2) • XMLTrees • Elemente  Knoten • Parent-Child Beziehungen  gerichtete Kanten • Jeder Baum erhält eine Eindeutige DocID • Jedem Knoten wird eindeutige NodeID zugeordnet • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

32. DTD-Miner (3) • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

33. DTD-Miner (4) • Der zusammenhängende Graph • XMLTrees werden nacheinander zusammengelegt • Gleiche Childelemente auf gleichen Knoten abgebildet • Abspeichern der NodeIDs in den Knoten und in den entspringenden Kanten • beim mehrfachen Auftreten eines Childelementes wird eine zusätzliche Kante eingefügt • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

34. DTD-Miner (5) • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

35. DTD-Miner (6) • Heuristische Regeln • Define Optionality • Bestimmung, ob Element opional ist, oder nicht • Merge Repeat • Bestimmung sich wiederholender Alternativen • Define Group • Bestimmung sich wiederholender Gruppen • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

36. DTD-Miner (7) • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur optionales Element, wenn für alle Kanten, die zwischen zwei Knoten existieren gilt: die Vereinigung der Kantenlabels ist eine echte Teilmenge der Labels des Startknoten (der Zielknoten ist dann optional) mehrfach auftretendes Element, Mehrere Kanten zwischen zwei Knoten

37. DTD-Miner (8) • Zur Bestimmung der optionalen Elemente: • Zwischen Knoten a und d existiert eine Kante mit dem Kantenlabel 1. Die (Mengen-) Vereinigung aller Kantenlabels ist dann {1} und es gilt: {1} ⊂ {1,7}, also ist d optional. • Weiteres Beispiel: • Zwischen b und c existieren 3 Kanten, • die Vereinigung der Kantenlabels ist • {2,8} ∪ {2} ∪ {2} = {2,8} • Diese Menge ist keine echte • Teilmenge der Knotenlables • ({2,8} ⊄ {2,8}), • damit ist das Element c nicht optional. • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

38. Beispiel zur Schemaableitung /1 <buch> <autor><vorname></vorname><nachname></nachname></autor> <autor><vorname></vorname><nachname></nachname></autor> <titel></titel> <verlag></verlag> <jahr></jahr> </buch> • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

39. Beispiel zur Schemaableitung /2 <buch> <editor><vorname></vorname><nachname></nachname></editor> <titel></titel> <verlag></verlag> <jahr></jahr> <auflage></auflage> </buch> • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

40. Beispiel zur Schemaableitung /3 mehrfaches Auftreten: mehrfache Kanten zwischen zwei Knoten optionales Auftreten: Kantenbeschriftung enthält nicht alle IDs des Knotens, von dem die Kante ausgeht • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

41. Beispiel zur Schemaableitung /4 abgeleitete DTD <!ELEMENT buch (autor*, editor?, titel, verlag, jahr, auflage?) <!ELEMENT autor (vorname, nachname)> <!ELEMENT editor (vorname, nachname)> • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

42. Teilaufgaben • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur Überprüfung Änderung Erweiterung Schema- Schema- durch den beschreibung beschreibung Benutzer Schema- Ableitung durch Tools XML-Dokumente

43. Differenzen zwischen abgeleiteter DTD und Original-DTD • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur • Ursache: • zu wenige XML-Dokumente, • enthalten nicht alle Spezialfälle der Anwendung

44. Metriken - Motivation /1 Viele XML Anwendungen benötigen ein Schema, es gibt verschiedene Möglichkeiten, es zu bekommen: • Benutzer kann dieses direkt definieren • es kann mit Hilfe von Entwurfswerkzeugen abgeleitet werden, z.B. aus einem ERM • ein existierendes Schema kann verwendet (und angepasst) werden • es kann aus Beispiel-XML-Dokumenten abgeleitet werden • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

45. Metriken - Motivation /2 Evaluation des Schema Dabei stellen sich Fragen wie: • Ist das Schema einfach zu verstehen? • Ist das Schema einfach zu verwenden? • Ist das Schema einfach zu verändern? Metriken versuchen, diese Fragen zu beantworten und verschiedene Eigenschaften eines Schemas abzuschätzen • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

46. Metriken - Motivation /3 Zwei Fragestellungen existieren: • Erfüllt ein Schema die Anforderungen einer Anwendung • Ist das Schema einfach zu verstehen/zu warten/.. Metriken beantworten (nur) die zweite Frage. • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur Schema1 Anwendung Metriken Schema2 XML

47. Softwaremetriken Merkmale der ISO 9126 • Verwendung von Metriken zur Qualitätsbewertung Qualitätsmodell Funktionalität Zuverlässigkeit Benutzbarkeit Effizienz Änderbarkeit Übertragbarkeit ISO/IEC 9126 Merkmal Teilmerkmal Metriken

48. Funktionalität Zuverlässigkeit Benutzbarkeit Effizienz Änderbarkeit Übertragbarkeit Software Metriken Die gleiche Methode gibt es im Bereich Software Merkmale Untermerkmale Metriken Verständlichkeit Erlernbarkeit Bedienbarkeit McCabe-Metrik Fan-Out-Metrik Analysierbarkeit Veränderbarkeit Stabilität Testbarkeit Halstedt Metrik

49. Klassifikation von Software Metriken • Produktmetriken bewerten das Schema von XML-Dokumenten • Ressourcenmetriken bewerten die Ressourcen, die zur Verarbeitung von XML-Dokumenten erforderlich sind • Prozessmetriken bewerten den Entwurfsprozess eines Schemas • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur

50. Produktmetriken -1 • Visualisieren einer DTD durch einen Graphen <!ELEMENT publications (book | article)*> <!ELEMENT book (author, title, content)> <!ATTLIST book isbn CDATA #REQUIRED> <!ELEMENT article (title, author+, content, conference)> <!ELEMENT title (#PCDATA)> <!ELEMENT author (#PCDATA)> <!ELEMENT conference (#PCDATA)> <!ELEMENT content (section+, references*)> <!ELEMENT section (#PCDATA)> <!ELEMENT references (publications)> • Ableitung von Produktmetriken aus dem Graphen • Vorteile der • Modellierung • ERM • UML • Editoren • EMX • Reverse- • Engineering • Metriken • Literatur public. book article isbn authors title content conf. section ref.