ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ

Transcript

1 ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΜΗΧΑΝΙΚΩΝ ΥΠΟΛΟΓΙΣΤΩΝ ΕΡΓΑΣΤΗΡΙΟ ΕΠΕΞΕΡΓΑΣΙΑΣ ΠΛΗΡΟΦΟΡΙΑΣ ΚΑΙ ΥΠΟΛΟΓΙΣΜΩΝ ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ ΑΥΤΟΜΑΤΗ ΕΞΕΥΡΕΣΗ ΔΙΑΔΙΚΤΥΑΚΩΝ ΥΠΗΡΕΣΙΩΝ ΜΕ ΤΗΝ ΑΞΙΟΠΟΙΗΣΗ ΤΟΥ ΣΗΜΑΣΙΟΛΟΓΙΚΟΥ ΙΣΤΟΥ Συγγραφέας Δημήτριος Γούτης, ΑΕΜ 6912 Επιβλέποντες Επίκουρος καθηγητής, Δρ. Ανδρέας Συμεωνίδης Μεταδιδακτορικός ερευνητής, Δρ. Κυριάκος Χατζηδημητρίου Θεσσαλονίκη, Οκτώβριος 2017

2 ii

3 Ευχαριστίες Θα ήθελα να ευχαριστήσω τον Ανδρέα Συμεωνίδη για την ευκαιρία που μου έδωσε να καταπιαστώ με την συγκεκριμένη διπλωματική εργασία, καθώς και τον Κυριάκο Χατζηδημητρίου για την καθοδήγησή του κατά την εκπόνηση της εργασίας. Ευχαριστώ τους γονείς μου για την εμπιστοσύνη που μου έδειξαν όλα αυτά τα χρόνια. Ιδιαίτερα ευχαριστώ τους φίλους και συναδέλφους Ναταλία και Σωτήρη που με συντρόφευσαν στα φοιτητικά χρόνια. Τέλος θα ήθελα να εκφράσω την ευγνωμοσύνη μου στον Νικόλα για την αμέριστη βοήθειά του στα πρακτικά και όχι μόνο, προβλήματα που ανέκυπταν. iii

4 iv

5 Περίληψη Το διαδίκτυο προσαρμόζεται προκειμένου να χειριστεί το μέγεθος των συνεχώς αυξανόμενων δεδομένων. Ο σημασιολογικός ιστός όπως τον οραματίστηκε ο Tim Berners Lee, εξαπλώνεται με αργούς ρυθμούς, αν και οι απαιτούμενες μέθοδοι και τεχνολογίες είναι ήδη εδώ και περιμένουν να εφαρμοστούν σε μεγάλη κλίμακα. Η τρέχουσα εργασία επικεντρώνεται στην αυτοματοποίηση της εξεύρεσης και χρήσης διαδικτυακών υπηρεσιών. Η βασική ιδέα της εργασίας περιστρέφεται γύρω από την ιδέα ότι σε μια επικοινωνία μεταξύ των συμμετεχόντων είτε είναι άνθρωποι είτε μηχανές, πρέπει να υπάρχει ένα κοινό πλαίσιο επικοινωνίας μεταξύ τους. Αυτό το θεμελιώδες πλαίσιο υλοποιείται με τις τεχνολογίες που προσφέρει ο Σημασιολογικός Ιστός. Χρησιμοποιείται το πλαίσιο περιγραφής πόρων (RDF) για τη μορφή δεδομένων. Επιπλέον, διατίθεται μια ποικιλία λεξιλογίων για την ανάθεση των εννοιών στα μοντέλα δεδομένων και τις υπηρεσίες. Στα πλαίσια της υλοποίησης δημιουργήθηκε ένα δίκτυο διακομιστών που προσφέρουν διαδικτυακές υπηρεσίες. Το περιεχόμενό τους περιγράφεται με όρους από το λεξιλόγιο HYDRA. Το μοντέλο δεδομένων είναι βασισμένο πάνω στους όρους του schema.org σε αντίθεση με τον απλό σχολιασμό. Ο γενικός πελάτης (client) είναι σε θέση να κατανοήσει αυτούς τους όρους και να επικοινωνήσει με τους διακομιστές με τη βοήθεια γραφημάτων RDF και όχι με απευθείας κλήσεις στις διευθύνσεις URL τους. Στη μέση αυτής της επικοινωνίας βρίσκεται ο API-Resolver, ένας εξυπηρετητής εξοπλισμένος με αναλυτή RDF και έναν διακομιστή SPARQL, προκειμένου να επιλύσει και να αντιστοιχήσει τα αιτήματα από τον πελάτη στον επιθυμητό διακομιστή. Οι κύριοι στόχοι της παρούσας εργασίας είναι δύο: Η αξιολόγηση αυτής της πρότυπης υλοποίησης και η επίδειξη των δυνατοτήτων του Σημασιολογικού Ιστού. Μόνο με την υιοθέτησή του σε πραγματικές συνθήκες, ωστόσο, θα γίνει δυνατή η αυτοματοποίηση πολλών διαδικασιών και η επέκτασης της λειτουργικότητας του τρέχοντος ιστού. v

6 vi

7 Abstract Autodiscovery of Web services utilizing the Semantic Web The Web is adapting in order to handle the magnitude of the ever increasing data. The semantic web, as envisioned by Tim Berners Lee, is emerging slowly, although the required methods and technologies are already there to be applied at large scale. The current thesis is focused on automating the discovery and usage of Web services. We argue that in a dialogue between participants whether they are human or machines, there has to be a common context between them. This context guarantees the soundness of their communication. This fundamental context is described through technologies offered by the Semantic Web toolchain. We use the Resource Description Framework (RDF) for our data format. Additionally, a variety of vocabularies is provided, in order to assign meaning to data models and services. A network of servers offering Web services is implemented. Their content is described with terms from the HYDRA vocabulary. The data model is built upon schema.org terms rather than being simply annotated. The generic client is able to understand those terms and communicate with the servers with the aid of RDF graphs, instead of direct calls to their URL. In the middle of this communication lies the API-Resolver, a server equipped with an RDF parser and a SPARQL endpoint aspiring to resolve and match the requests from the client to the desired server. The goal of the current thesis is twofold. The evaluation of this proof of concept implementation and the exhibition of the Semantic Web potential. However, only with its adoption in large scale, the automation of many processes and the extension of the functionality of the current Web will become feasible. Goutis Dimitris gts.dmtr@gmail.com Electrical & Computer Engineering Department AUTH, Greece October 2017 vii

8 viii

9 ΠΙΝΑΚΑΣ ΠΕΡΙΟΧΟΜΕΝΩΝ ΛΙΣΤΑ ΔΙΑΓΡΑΜΜΑΤΩΝ... XI ΛΙΣΤΑ ΕΙΚΟΝΩΝ... XII ΛΙΣΤΑ ΑΠΟΣΠΑΣΜΑΤΩΝ ΚΩΔΙΚΑ... XIII ΛΕΞΙΚΟ ΟΡΩΝ ΚΑΙ ΟΡΙΣΜΩΝ... XIV 1 ΕΙΣΑΓΩΓΗ Εισαγωγικά στοιχεία Σκοπός διπλωματικής εργασίας Μεθοδολογία Οργάνωση κεφαλαίων ΘΕΩΡΗΤΙΚΟ ΚΑΙ ΤΕΧΝΟΛΟΓΙΚΟ ΥΠΟΒΑΘΡΟ - ΣΧΕΤΙΚΗ ΒΙΒΛΙΟΓΡΑΦΙΑ Θεωρητικό Υπόβαθρο Σημασιολογικός Ιστός (Semantic Web) Πλαίσιο Περιγραφής Πόρων (RDF) JSON-LD Λεξιλόγια Αρχιτεκτονική REST SPARQL Σχετική Βιβλιογραφία Αυτόματη τεκμηρίωση RESTful APIs RESTdesc Call by Meaning ΑΥΤΟΜΑΤΗ ΕΞΕΥΡΕΣΗ ΔΙΑΔΙΚΤΥΑΚΩΝ ΥΠΗΡΕΣΙΩΝ ΟΡΙΣΜΟΣ Ανάπτυξη Λογισμικού για το Διαδίκτυο Ο σημασιολογικός ιστός σήμερα Μία απλή αναζήτηση Σημασιολογική σήμανση δεδομένων Τα γενικό πλαίσιο σε μια επικοινωνία Τεχνητή νοημοσύνη Η αποφυγή της σημασιολογίας ΥΛΟΠΟΙΗΣΗ Εισαγωγή ix

10 4.2 Διαδικτυακές υπηρεσίες με τη χρήση του HYDRA Αυτοματοποίηση δημιουργίας κλάσεων Περιγραφή υπηρεσιών με όρους HYDRA Πρότυπο RESTful API Resolver Αναλυτής Γράφου Apache Jena/Fuseki Διεπαφή API-Resolver Γενικευμένος πελάτης Schydra Client Συνοπτική παρουσίαση ΠΡΑΚΤΟΡΑΣ ΛΟΓΙΣΜΙΚΟΥ ΓΙΑ ΤΑΞΙΔΙΩΤΙΚΕΣ ΥΠΗΡΕΣΙΕΣ Εισαγωγή Παρουσίαση Server, παρόχου υπηρεσίας Μοντέλο δεδομένων Οι παρεχόμενες υπηρεσίες του Server Σύγκριση με υπάρχουσα διαδικασία ανάπτυξης παρόχου Παρουσίαση Πελάτη - Client Μοντέλο δεδομένων Εξεύρεση API Χρήση του API Σύγκριση με υπάρχουσα διαδικασία ανάπτυξης πελάτη Τελικό αποτέλεσμα Αποτελέσματα και παρατηρήσεις ΣΥΜΠΕΡΑΣΜΑΤΑ Γενικά Call by Context Μετάβαση στον σημασιολογικό ιστό ΜΕΛΛΟΝΤΙΚΕΣ ΕΠΕΚΤΑΣΕΙΣ SHACL Λεξιλόγιο περιορισμών μέσω σχημάτων Linked Data Fragments ConceptNet Επίλογος ΠΑΡΑΡΤΗΜΑ A ΒΙΒΛΙΟΓΡΑΦΙΑ x

11 Λίστα διαγραμμάτων Διάγραμμα 1: WWW proposal (1989) [2] Διάγραμμα 2: Αναπαράσταση Συστήματος Διάγραμμα 3: Παράδειγμα γράφου RDF [6] Διάγραμμα 4: Παράδειγμα γράφου σε μορφή JSON-LD Διάγραμμα 5: Βασικές κλάσεις και ιδιότητες του RDFS Διάγραμμα 6: Οι σχέσεις ανάμεσα στις οντότητες του HYDRA [18] Διάγραμμα 7: Υιοθέτηση λεξιλογίου schema.org (I) [similartech.com] Διάγραμμα 8: Υιοθέτηση λεξιλογίου schema.org (II) [similartech.com] Διάγραμμα 9: Χρήση της κλάσης schema:recipe [similartech.com] Διάγραμμα 10: Αναπαράσταση συνολικού συστήματος Διάγραμμα 11: Διάγραμμα κλάσεων του Schydra Client Διάγραμμα 12: Διάγραμμα ροής Schydra Client Διάγραμμα 13: API-Resolver performance metrics xi

12 Λίστα εικόνων Εικόνα 1: Περιγραφή ταχυδρομικής διεύθυνσης κατά το schema.org Εικόνα 2: Παράδειγμα αναζήτησης στην Google (I) Εικόνα 3: Τυπική περιγραφή API, API-Resolver Εικόνα 4: Παράδειγμα διεπαφής τεκμηρίωσης Server Εικόνα 5: User Interface xii

13 Λίστα αποσπασμάτων κώδικα Απόσπασμα κώδικα 1: Παράδειγμα εγγράφου JSON-LD (I) Απόσπασμα κώδικα 2: Παράδειγμα εγγράφου JSON-LD (IΙ) Απόσπασμα κώδικα 3: Παράδειγμα χρήσης schema.org (I) Απόσπασμα κώδικα 4: Παράδειγμα περιγραφής μοντέλου δεδομένων μιας υπηρεσίας αεροπορικών εισιτηρίων με όρους από το schema.org Απόσπασμα κώδικα 5: Παράδειγμα HYDRA περιγραφής εντός κλάσης Απόσπασμα κώδικα 6: Περιγραφή ζητούμενης κλάσης (client request) Απόσπασμα κώδικα 7: SPARQL ερώτημα προς εξεύρεση ζητούμενης κλάσης Απόσπασμα κώδικα 8: Η περιγραφή της κλάσης ως γράφος σε JSON-LD Απόσπασμα κώδικα 9: Παράδειγμα αρχικοποίησης μοντέλου δεδομένων Απόσπασμα κώδικα 10: Αναπαράσταση κλάσεων μέσω schema.org [schema.yml] Απόσπασμα κώδικα 11: Υλοποίηση PHP κλάσης GeoCoordinates Απόσπασμα κώδικα 12: Υλοποίηση PHP κλάσης TouristAttraction Απόσπασμα κώδικα 13: Κεντρικός γράφος περιγραφής παρόχου Απόσπασμα κώδικα 14: Απάντηση Server σε μορφή JSON-LD Απόσπασμα κώδικα 15: Περιγραφή μοντέλου δεδομένων client Απόσπασμα κώδικα 16: Αρχικοποίηση κλάσεων και εξεύρεση υπηρεσιών Απόσπασμα κώδικα 17: Απόδοση τιμών στις εσωτερικές κλάσεις (I) Απόσπασμα κώδικα 18: Απόδοση τιμών στις εσωτερικές κλάσεις (II) Απόσπασμα κώδικα 19: Υλοποίηση αναζήτησης Απόσπασμα κώδικα 20: Ανάθεση επιστρεφόμενων δεδομένων Απόσπασμα κώδικα 21: Συνάρτηση υλοποίησης απαιτούμενης λειτουργικότητας xiii

14 Λεξικό όρων και ορισμών Αναλυτής εγγράφου Parser Ο αναλυτής εγγράφου αναγνωρίζει λέξεις κλειδιά και προκαθορισμένο συντακτικό ώστε να πραγματοποιήσει συνήθως κάποιες αυτοματοποιημένες διαδικασίες ή απλά να μετατρέψει το έγγραφο από μια αναπαράσταση σε μία άλλη. Ανατρέχω Dereference Η διαδικασία κατά την οποία ακολουθούμε έναν υπερσύνδεσμο ώστε να αποκτήσουμε πρόσβαση στο περιεχόμενο που μας δείχνει. Αντικείμενο Object Το αντικείμενο μιας πρότασης RDF αποτελεί το περιεχόμενο της αποδιδόμενης ιδιότητας σε μία πρόταση RDF. Γράφος Graph Ένας γράφος κατά το πρότυπο RDF. Δομημένα Δεδομένα Structured Data Τα δομημένα δεδομένα, χρησιμοποιούν μεταδεδομένα για να περιγράψουν αναλυτικά το περιεχόμενό τους. Διαχωρίζονται από την απλή αναπαράσταση καθώς κάθε πεδίο σε αυτή τη δομή αντιστοιχεί και σε μια έννοια. Κατηγόρημα Predicate Το κατηγόρημα εκφράζεται συνήθως με τη μορφή ιδιότητας ή μεταβατικού ρήματος και αποδίδει στο υποκείμενο την περιγραφόμενη ιδιότητα, στο πλαίσιο του προτύπου RDF. Μεταδεδομένα - Metadata Μεταδεδομένα ονομάζουμε την πληροφορία η οποία περιγράφει ένα σύνολο δεδομένων με σαφή τρόπο. xiv

15 Πολυμεσικό περιεχόμενο Hypermedia content/controls Μία διασύνδεση πολλών μη ιεραρχημένων στοιχείων. Τα στοιχεία έχουν πολλές μορφές όπως του γραπτού κειμένου, εικόνας, ήχου κ.α. Παράλληλα με το περιεχόμενο, περιέχουν και τα εργαλεία πλοήγησης/ελέγχου τους όπως είναι οι υπερσύνδεσμοι. Πόρος - Resource Πόρος νοείται ένα γενικευμένο αντικείμενο εντός του διαδικτύου. Ένας πόρος μπορεί να είναι μια ιστοσελίδα με κείμενο, ένα βίντεο ή ακόμη και ένα υποσύνολο αυτών. Πράκτορας - Agent Λογισμικό το οποίο πραγματοποιεί κάποια ενέργεια. Πρόταση Statement Ο όρος πρόταση χρησιμοποιείται εντός του κειμένου για να περιγράψει τη μορφή των δεδομένων του προτύπου RDF. Προτασιακή λογική Η χρήση περιγραφικών προτάσεων οι οποίες είναι είτε αληθείς είτε ψευδείς. Σετ δεδομένων Dataset Ένα σύνολο από γράφους κατά το πρότυπο RDF. Σημασιολογικός Ιστός - Semantic Web Η χρήση δεδομένων που περιγράφουν άλλα δεδομένα στα πλαίσια του διαδικτύου ονομάζεται σημασιολογικός ιστός. Υποκείμενο Subject Ο όρος υποκείμενο περιγράφει τον κόμβο μιας RDF πρότασης στον οποίο αποδίδεται μία ιδιότητα. Υπερκλάση Μία ανώτερη ιεραρχικά κλάση η οποία περιέχει ένα σύνολο άλλων. xv

16 Υποκλάση Μία κλάση η οποία περιέχεται από μία άλλη, υπερκλάση. Φυλλομετρητής - Browser Φυλλομετρητής ιστού, πλοηγός διαδικτύου, λογισμικό πελάτη διαδικτύου. IRI Internationalized Resource Identifier Ένα αλφαριθμητικό αποτελούμενο από το σύνολο χαρακτήρων του UTF-8 χρησιμοποιείται στο διαδίκτυο σαν αναγνωριστικό ενός πόρου. που RDF Resource Description Framework Πλαίσιο περιγραφής πόρων, πρότυπο. [1] Schema.org Λεξιλόγιο που χρησιμοποιούμε για να αποδώσουμε σημασιολογία στον περιγραφόμενο όρο/λέξη κλειδί.. SPARQL endpoint Ο server που απαντά σε ερωτήματα SPARQL. URI Uniform Resource Identifier Ένα αλφαριθμητικό αποτελούμενο από υποσύνολο του ASCII που χρησιμοποιείται στο διαδίκτυο σαν αναγνωριστικό ενός πόρου. URL Ένα αλφαριθμητικό που χρησιμοποιείται στο διαδίκτυο σαν αναγνωριστικό ενός πόρου, περιγράφοντας και το πρωτόκολλο επικοινωνίας (HTTP, FTP, κ.α.) Wrapper Λογισμικό το οποίο παρεμβάλλεται σε μία διαδικασία ώστε να πραγματοποιήσει απαραίτητες μετατροπές σε δεδομένα για παράδειγμα. xvi

17 1 Εισαγωγή 1.1 Εισαγωγικά στοιχεία Σήμερα όσο ποτέ ο κόσμος είναι διασυνδεδεμένος. Οι αποστάσεις μικραίνουν και η αντίληψη του ανθρώπου για αυτόν πλαταίνει. Σε αυτή την κατεύθυνση καταλυτική επίδραση είχε η εφεύρεση και ραγδαία υιοθέτηση του παγκόσμιου ιστού μαζί με την ταχεία ανάπτυξη της Πληροφορικής. Το 1990 δημιουργήθηκε η πρώτη έκδοση του πρωτοκόλλου HTTP (Διάγραμμα 1). Ο παγκόσμιος ιστός είναι πυλώνας του σημερινού πολιτισμού, της λεγόμενης κοινωνίας της πληροφορίας. Η καθημερινότητάς μας διαπλέκεται με τον παγκόσμιο ιστό σε κάθε έκφανσή της. Στο χώρο εργασίας, ακόμη και αν είναι καθαρά χειρωνακτική εργασία, στις διαπροσωπικές μας σχέσεις μέσω των κοινωνικών δικτύων, στη διασκέδασή μας η οποία μοιάζει πλέον εξατομικευμένη μέσα από σωρεία επιλογών που προσφέρονται, στον τρόπο που πραγματοποιούμε τις αγορές μας ακόμη και για βασικά αγαθά. Ότι και να σκεφτεί κανείς, μπορεί να το αναζητήσει στον παγκόσμιο ιστό. Παράλληλα το άτομο έχει καταλάβει σημαντικό ρόλο σαν δημιουργός περιεχομένου με ποικίλες μορφές (κείμενα, βίντεο, μουσική), άλλες φορές ερασιτεχνικά και άλλες επαγγελματικά. Το φαινόμενο αυτό της καθολικής αποδοχής και χρήσης του ιστού δεν έχει να κάνει μόνο με τις τεχνολογικά ανεπτυγμένες χώρες, αλλά εμφανίζεται παγκοσμιοποιημένο. Η ανάπτυξη του παγκόσμιου ιστού πραγματοποιείται καθημερινά και ταχύτατα τόσο σε επίπεδο τεχνολογίας όσο και σε επίπεδο περιεχομένου. Ένας από τους στόχους που έχουν τεθεί είναι η μετάβαση στον λεγόμενο σημασιολογικό ιστό. Ο όρος σημασιολογικός ιστός έκανε την εμφάνισή του λίγο μετά τη γέννηση του παγκόσμιου ιστού και δεν είναι κάτι καινούριο. Περιγραφικά ο σημασιολογικός ιστός είναι ένας ιστός που παρέχει τη δυνατότητα σε έναν πράκτορα λογισμικού να περιηγηθεί μέσα στο διαδίκτυο με τον ίδιο τρόπο που ένας άνθρωπος περιηγείται σήμερα στον παγκόσμιο ιστό. Η δυνατότητα δηλαδή να ανακτήσει τις απαραίτητες πληροφορίες που επιθυμεί ακολουθώντας υπερσυνδέσμους. Εδώ πρέπει να σημειωθεί ότι ενώ πληθώρα εργαλείων και προτύπων έχει σχεδιαστεί ήδη από τις αρχές του 2000, αυτό το όραμα δεν έχει υλοποιηθεί στο βαθμό που θα μπορούσε. Η ικανότητα των μηχανών να διατρέξουν τον παγκόσμιο ιστό είναι περιορισμένη σε κάποια ευφυή συστήματα. Αυτό το ζήτημα είναι πολυπαραγοντικό και θα εξεταστεί εκτενέστερα στο Κεφάλαιο 3. 17

18 Διάγραμμα 1: WWW proposal (1989) [2] 1.2 Σκοπός διπλωματικής εργασίας Η παρούσα εργασία αποσκοπεί στην ανάπτυξη και εφαρμογή της αυτόματης εξεύρεσης υπηρεσιών στο διαδίκτυο (Web API autodiscoverability) αξιοποιώντας τις τεχνολογίες που παρέχει ο σημασιολογικός ιστός. Οι έννοιες του σημασιολογικού ιστού (Semantic Web) παρά το γεγονός της ύπαρξής τους για αρκετά χρόνια στο πλαίσιο του διαδικτύου, δεν εμφανίζονται κατά τη δημιουργία διαδικτυακών υπηρεσιών. Αφού αναλυθούν λοιπόν διάφορες πτυχές του σημασιολογικού ιστού και της ανάπτυξης λογισμικού στα πλαίσιά του, θα εφαρμοστεί μια σειρά από νέες τεχνολογίες. Θα δημιουργηθεί, ένα ολόκληρο οικοσύστημα από παρόχους υπηρεσιών με σημασιολογική περιγραφή. Σε αυτό το οικοσύστημα, θα εξεταστεί η υλοποίηση ενός πράκτορα λογισμικού ο οποίος χρησιμοποιεί αυτές τις υπηρεσίες. Στόχος είναι η ανάδειξη τόσο των απαιτήσεων που πρέπει να πληρούνται για την πραγματοποίηση της αυτόματης εξεύρεσης εφαρμογών, όσο και της σημασίας της εγκαθίδρυσης του σημασιολογικού ιστού. 1.3 Μεθοδολογία Η μεθοδολογία που ακολουθείται έχει σαν βασικό στοιχείο τη χρήση κοινών εννοιών για να περιγραφούν οι ζητούμενες και προσφερόμενες υπηρεσίες. Επιλέγεται, δηλαδή, ένας κοινός τρόπος αναπαράστασης της πληροφορίας. Η αναπαράσταση αυτή είναι 18

19 ανεξάρτητη από τη γλώσσα προγραμματισμού που χρησιμοποιηθεί και έχει τη μορφή λεξιλογίου. Στόχος είναι η χρήση των ίδιων όρων από την πλευρά του παρόχου και του πελάτη ώστε να δηλώνουν σαφώς την ίδια έννοια. Οι όροι αυτοί ανήκουν σε κοινώς αποδεκτά λεξιλόγια, δηλαδή περιγραφικά σύνολα οντοτήτων τα οποία αποτελούν μία από τις πολλές τεχνολογίες του σημασιολογικού ιστού. Αποτελούν το πλαίσιο ή τα συμφραζόμενα (context) μέσα στα οποία πραγματοποιείται η επικοινωνία. Εντός αυτού του πλαισίου επικοινωνίας, ένας πράκτορας λογισμικού ικανός να το κατανοήσει, μπορεί να πραγματοποιήσει αυτόματα σύνθετες ενέργειες εφόσον αυτές περιγράφονται σαφώς. Αρχικά καθορίστηκε το πλαίσιο της επικοινωνίας χρησιμοποιώντας λεξιλόγια ικανά να περιγράψουν τη λειτουργία ενός παρόχου (server) μιας υπηρεσίας, καθώς και την υπηρεσία αυτή καθαυτή. Σχεδιάστηκε ο πράκτορας λογισμικού ο οποίος θα ήταν σε θέση να ερμηνεύσει αυτές τις περιγραφές και να τις διαχειριστεί κατάλληλα (Client API consumer, Διάγραμμα 2). Παράλληλα δημιουργήθηκε μια σειρά από παρόχους - μεσολαβητές οι οποίοι τροφοδοτούνται με πραγματικά δεδομένα (HYDRA Wrapper, Διάγραμμα 2) στα οποία αποδίδουν τις αντίστοιχες περιγραφές με βάση τους λεξιλογικούς όρους που επιλέχθηκαν. Η αναζήτηση και αυτόματη εξεύρεση υπηρεσιών πραγματοποιείται μέσω κλήσης σε έναν κεντρικό κόμβο (API Resolver, Διάγραμμα 2) ο οποίος λειτουργεί σαν μηχανή αναζήτησης. Ο κεντρικός κόμβος γνωρίζει τις περιγραφές των παρεχόμενων υπηρεσιών. Δέχεται την περιγραφή της ζητούμενης υπηρεσίας από τον πελάτη και επιστρέφει τους παρόχους που πληρούν τα αντίστοιχα κριτήρια. Στη συνέχεια ο πράκτορας λογισμικού που διαθέτει ο πελάτης είναι σε θέση να αναλάβει την επικοινωνία με τον πάροχο και να αξιοποιήσει τις παρεχόμενες υπηρεσίες. Με αυτή την αλληλουχία ενεργειών πραγματοποιείται η αναζήτηση, η εξεύρεση και η αυτόματη χρήση μίας υπηρεσίας στα πλαίσια του συστήματος που δημιουργήθηκε. 19

20 Διάγραμμα 2: Αναπαράσταση Συστήματος. Δεξιά βρίσκονται οι πελάτες, αριστερά οι εξυπηρετητές και στο κέντρο ο API-Resolver που τους συνδέει σημασιολογικά. 1.4 Οργάνωση κεφαλαίων Στο Κεφάλαιο 2 παρατίθενται αναλυτικά οι τεχνολογίες στις οποίες βασίστηκε η παρούσα εργασία, καθώς και το θεωρητικό υπόβαθρο που απαιτείται. Με λίγα λόγια αναλύεται η έννοια του σημασιολογικού ιστού, το πρότυπο RDF στο οποίο βασίζεται, οι έννοιες της οντότητας και του λεξιλογίου. Θα παρουσιαστούν τα εργαλεία που χρησιμοποιούνται για την αναπαράσταση και αξιοποίηση των δεδομένων κατά RDF [3]. Τέλος εξετάζεται η τρέχουσα βιβλιογραφία για υλοποιήσεις που έχουν παρόμοια στόχευση και υπόβαθρο. Στο Κεφάλαιο 3 ορίζεται σαφώς και αναλύεται το πρόβλημα προς αντιμετώπιση. Παράλληλα παρουσιάζονται επιμέρους προβλήματα τα οποία λήφθηκαν υπόψιν κατά τη σχεδίαση. Στο Κεφάλαιο 4 θα αναλυθεί η παρουσιαζόμενη υλοποίηση σε επίπεδο λογικής με τη βοήθεια αποσπασμάτων κώδικα, ενώ στο Κεφάλαιο 5 θα εξεταστεί σαν ένα μαύρο κουτί ώστε να γίνει καλύτερα κατανοητή η αξία του. Τέλος στο Κεφάλαιο 6 και στο Κεφάλαιο 7 παρουσιάζονται αντίστοιχα τα συμπεράσματα και οι μελλοντικές επεκτάσεις της συγκεκριμένη υλοποίησης. 20

21 2 Θεωρητικό και τεχνολογικό υπόβαθρο - Σχετική βιβλιογραφία Το κεφάλαιο αυτό παρουσιάζει το απαραίτητο τεχνολογικό και θεωρητικό υπόβαθρο που απαιτείται ώστε να είναι γίνουν κατανοητές οι επόμενες ενότητες που θα ακολουθήσουν. Οι τεχνολογίες που θα συζητηθούν σχετίζονται κυρίως με τον σημασιολογικό ιστό. Αποτελούν τα εργαλεία και τα πρότυπα που δημιουργήθηκαν στην προσπάθειά δόμησης της έννοιας της σημασιολογίας στον παγκόσμιο ιστό. 2.1 Θεωρητικό Υπόβαθρο Σημασιολογικός Ιστός (Semantic Web) Ο όρος σημασιολογικός προκύπτει από το γεγονός ότι μόνο ο άνθρωπος ο οποίος μπορούσε να κατανοήσει το κείμενο της ιστοσελίδας μπορούσε να περιηγηθεί και να εκτελέσει ενέργειες στον ιστό. Επομένως έπρεπε να δημιουργηθεί μια σημειολογία η οποία θα ήταν κατανοητή από έναν πράκτορα λογισμικού ώστε να μπορεί να διατρέχει αυτόματα τον ιστό. Η απαίτηση αυτή έφερε στο προσκήνιο την έννοια των μεταδεδομένων. Τα μεταδεδομένα είναι πληροφορίες οι οποίες αφορούν τα ίδια τα δεδομένα. Ένα βιβλίο για παράδειγμα, είναι γνωστό ότι περιγράφεται από ένα σύνολο από χαρακτηριστικά όπως ο συγγραφέας, ο εκδοτικός οίκος, η ημερομηνία έκδοσης κ.α. Το πλαίσιο των μεταδεδομένων ορίζεται πάντα σε σχέση με την πληροφορία και την περιγράφει αναλυτικά. Ενδιαφέρον παρουσιάζει λοιπόν το πλαίσιο στο οποίο τα μεταδεδομένα εκφράζονται. Αντίστοιχα με το βιβλίο, αποτελεί ζητούμενο η απόδοση μιας περιγραφικότητας στα δεδομένα που περιέχει μια ιστοσελίδα και κατ' επέκταση ολόκληρο το διαδίκτυο. Σκοπός πάντα είναι αυτή η περιγραφή ή σημασιολογία να μπορεί να αξιοποιηθεί από αυτοματοποιημένες λύσεις λογισμικού και όχι μόνο από τον άνθρωπο. Η σημασιολογία αυτή ενυπήρχε σαν ιδέα μέσα στις πρώτες προδιαγραφές του διαδικτύου, αλλά χρειαζόταν κάποιο χρονικά διάστημα για να έρθει στο προσκήνιο. Ήδη από το 1994 ο όρος URI (Uniform Resource Identifier), μια γενίκευση του γνωστού URL, δεν απευθυνόταν σε ιστοσελίδες ή ιστότοπους συγκεκριμένα αλλά σε μια γενικότερη οντότητα ή αλλιώς αντικείμενο [4]. Πράγμα που υποδηλώνει ότι δεν σχεδιάστηκε απλά για την περιήγηση σε σελίδες κειμένου. Μέσω ενός URI που ορίζουμε απλοϊκά τη μοναδική διεύθυνση μιας ιστοσελίδας, μπορεί κανείς να ορίσει και ένα χαρακτηριστικό μιας δομής δεδομένων ή έναν πόρο. Σήμερα είναι τυπική τακτική να ακολουθούμε βοηθητικούς υπερσυνδέσμους μέσα στην ίδια ιστοσελίδα ώστε να μεταβαίνουμε από 21

22 παράγραφο σε παράγραφο ή γενικότερα από πόρο σε πόρο. Οι υπερσύνδεσμοι αυτοί εντός μιας ιστοσελίδας έχουν ρόλο αντίστοιχο με αυτόν του ευρετηρίου ενός βιβλίου. Επεκτείνοντας τη λογική αυτή, μπορούμε να αποδώσουμε πλήθος μεταδεδομένων σε έναν πόρο, τα οποία θα μπορούσε να αντιληφθεί ένας πράκτορας λογισμικού και να διαχειριστεί αυτόματα την παρεχόμενη πληροφορία. Ερχόμαστε λοιπόν να αποδώσουμε τον ορισμό του σημασιολογικού ιστού από τον δημιουργό του Sir Tim Berners Lee [5]: The Semantic Web is an extension of the current Web in which information is given well-defined meaning, better enabling computers and people to work in cooperation. [...] A web of data that can be processed directly and indirectly by machines. Σε αυτή την κατεύθυνση ήδη από το 1999 υιοθετήθηκε το Πλαίσιο Περιγραφής Πόρων (Resource Description Framework) [3]. Η πρώτη περιγραφή που χρησιμοποιήθηκε για το RDF ήταν το πρότυπο εγγράφου XML [6] το οποίο δε γνώρισε ιδιαίτερη αναγνώριση. Για αρκετό διάστημα δεν υπήρξε κάποια πραγματική κίνηση προς αυτή την κατεύθυνση Πλαίσιο Περιγραφής Πόρων (RDF) Το Πλαίσιο Περιγραφής Πόρων (RDF) [3] δημιουργήθηκε από την ανάγκη διαχείρισης του τεράστιου όγκου δεδομένων που είχε ήδη αρχίσει να δημιουργείται λίγο πριν το Το μοντέλο δεδομένων RDF στην αρχική πρόταση, περιγράφει τον τρόπο διαχείρισης των μεταδεδομένων ώστε οι εφαρμογές να μπορούν να καταλαβαίνουν το περιεχόμενο των πληροφοριών και να ενεργούν σε αυτές. Αποτελεί δηλαδή μία δομή για την αναπαράσταση πληροφορίας. Παρακάτω παρουσιάζεται εποπτικά η δομή του RDF. 22

23 Διάγραμμα 3: Παράδειγμα γράφου RDF [6] Η δομή RDF χρησιμοποιεί προτάσεις (statements) σχετικά με πόρους (resources). Κάθε πόρος έχει ένα αναγνωριστικό σε μορφή URI. Μία πρόταση αποτελείται από το υποκείμενο (subject), το κατηγόρημα ή ιδιότητα (predicate) και το κατηγορούμενο ή αντικείμενο (object). Πρέπει να γίνει αντιληπτό ότι όλη η πληροφορία αποθηκεύεται με μορφή προτάσεων. Δεν θα βρούμε πόρους οι οποίοι δεν ανήκουν σε μια πρόταση. Δεν συναντώνται δηλαδή οι όροι της πρότασης κατά μόνας. Επομένως μέσω μιας τέτοιας πρότασης με τη σειρά εμφάνισής υποκείμενο ιδιότητα αντικείμενο μπορεί να περιγραφεί το παραπάνω γράφημα (Διάγραμμα 3) ως εξής: <Bob> <is a> <person>. <Bob> <is a friend of> <Alice>. <Bob> <is born on> <the 4th of July 1990>. <Bob> <is interested in> <The Mona Lisa>. <The Mona Lisa> <was created by> <Leonardo da Vinci>. <La Joconde à Washington> <is about> <the Mona Lisa>. 23

24 Το γράφημα που παρουσιάστηκε, αποτελεί έναν RDF γράφο. Οι κόμβοι του γράφου είναι τα υποκείμενα και τα αντικείμενα των προτάσεων. Η ιδιότητα ή κατηγόρημα μιας πρότασης είναι μια κατευθυνόμενη ακμή με φορά από το υποκείμενο προς το αντικείμενο. Επομένως οι γράφοι που περιγράφονται στο RDF είναι κατευθυνόμενοι. Με αυτή την προτασιακή λογική λοιπόν δημιουργούνται γράφοι δεδομένων. Μία συλλογή γράφων αντιστοιχεί σε ένα σετ δεδομένων (dataset). Ως αναγνωριστικά για τους όρους της πρότασης χρησιμοποιούνται URI, που επιτρέπουν την πρόσβαση σε λεπτομέρειες για τον κάθε όρο της πρότασης. Το γεγονός ότι είναι καθολικής εμβέλειας υποδηλώνει ότι δύο διαφορετικές αναφορές στον ίδιο όρο (URI) είναι ταυτοτικές. Τα αλφαριθμητικά μπορούν να κατέχουν μόνο τη θέση του κατηγορούμενου, ενώ ο ιδιότυπος κενός κόμβος δεν δύναται να βρίσκεται στη θέση της ιδιότητας/σχέσης. Ο κενός κόμβος συνήθως χρησιμοποιείται σαν μεταβατικός κόμβος ώστε να ανατεθεί ένα πλήθος από ιδιότητες στο υποκείμενο. Η δομή από μόνη της είναι αρκετά απλή και δεν παρουσιάζει κάποια δυσκολία στην κατανόηση. Η χρήση της όμως σε πολύπλοκα σενάρια καθιστά δύσκολη την αποσφαλμάτωση τυχών λογικών λαθών. Σε συνδυασμό με την πρώτη της αναπαράσταση μέσω του προτύπου RDF/XML [7], η δομή αποθάρρυνε την υιοθέτησή της από τους προγραμματιστές και έτσι δεν χρησιμοποιήθηκε ευρέως. Δεν είχαμε λοιπόν την επιθυμητή ανάπτυξη πόρων που να συμπεριλαμβάνουν μεταδεδομένα. Σαν αντιμετώπιση αυτού και άλλων προβλημάτων δημιουργήθηκαν οι αναπαραστάσεις Turtle [8], N-Triples [9], N-Quads [10], N3 [11], JSON-LD [12]. Επιλέχθηκε από δω και στο εξής η χρήση του προτύπου JSON-LD το οποίο αμβλύνει αυτό ακριβώς το πρόβλημα με κομψό και γνώριμο τρόπο όπως περιγράφεται παρακάτω JSON-LD Στο διαδίκτυο αλλά και πέρα από αυτό είναι διαδεδομένη η χρήση της γνωστής και εύχρηστης αναπαράστασης αρχείων JSON [13] (JavaScript Object Notation). Είναι μια αναπαράσταση καθαρή και ευανάγνωστη από τον άνθρωπο, ενώ είναι υπολογιστικά φθηνή κατά την επεξεργασία της. Πάνω λοιπόν στο πολυχρησιμοποιημένο JSON βασίζεται το JSON-LD [12] (JavaScript Object Notation Linked Data). Το JSON-LD χρησιμοποιεί ουσιαστικά το συντακτικό του JSON με κάποιες λέξεις κλειδιά οι οποίες το χαρακτηρίζουν και του προσδίδουν κάποιες ιδιότητες. Περιέχει δηλαδή μεταδεδομένα με την ευρεία έννοια του όρου. Οι λέξεις κλειδιά αρχίζουν με το ώστε να γίνονται αντιληπτές από τον αναλυτή του εγγράφου (parser). Καθώς προσθέτουμε μόνο κάποιες λέξεις κλειδιά και δεν αλλάζει η μορφή του εγγράφου μπορούμε να χρησιμοποιήσουμε ένα JSON-LD σαν απλό JSON. Η αναπαράσταση αυτή 24

25 αφορά το πρότυπο Linked-Data [14] και μας δίνει τη δυνατότητα να περιγράψουμε τις γνωστές προτάσεις του RDF, με μεγαλύτερη ευχέρεια από ότι η δομή RDF/XML. Κατά τη σύνταξη του JSON έχουμε το παρακάτω αντικείμενο: 1 object: { 2 "@id": "/testnode" 3 "name": "Manu Sporny", 4 "homepage": " 5 "image": " 6 } Απόσπασμα κώδικα 1: Παράδειγμα εγγράφου JSON-LD (I) Το αντικείμενο object (Απόσπασμα κώδικα 1) διαθέτει τέσσερις ιδιότητες (@id, name, homepage, image) με αντίστοιχες τιμές ( /testnode, Manu Sporny, ). Η αναφορά στις τιμές γίνεται στη γλώσσα JavaScript για παράδειγμα με τη χρήση των αναγνωριστικών ως εξής Object[ name ] = Manu Sporny. Όταν ερμηνεύσουμε το παραπάνω σαν JSON-LD όμως έχουμε την απαίτηση για προτασιακή σύνταξη. Έτσι έχουμε: Οτιδήποτε περιβάλλεται από τις αγκύλες {} αποτελεί έναν κόμβο μέσα σε έναν γράφο RDF. Το υποκείμενο (subject) της πρότασής μας είναι το (Απόσπασμα κώδικα 1, γραμμή 2) με τιμή /testnode. Η ιδιότητα-σχέση της πρότασής μας είναι τα υπόλοιπα πεδία που ακολουθούν. Στην προκειμένη τα name, homepage, image, αποδίδουν όλα μια ιδιότητα στο υποκείμενο. Τα αντικείμενα των προτάσεων είναι οι τιμές των αντίστοιχων πεδίων που ακολουθούν. Αν παραλείψουμε τον τότε έχουμε έναν ανώνυμο κόμβο. Ο οποίος ερμηνεύεται μόνο τοπικά και δεν έχουμε άμεσο τρόπο αναφοράς σε αυτόν. Μόνο μέσα από την περιγραφή μιας πρότασης που αναφέρεται σε αυτόν. Το αναγνωριστικό object έξω από τις αγκύλες (Απόσπασμα κώδικα 1, γρ. 1) ερμηνεύεται σαν ιδιότητα-σχέση ενός κόμβου που τον εμπεριέχει. Το object δηλαδή είναι μια ιδιότητα που αποδίδει σαν αντικείμενο έναν άλλο κόμβο, ο οποίος περιγράφεται επιτόπου. Επομένως οι προτάσεις RDF που προκύπτουν από τα παραπάνω είναι οι ακόλουθες: </testnode> <name> <"Manu Sporny">. 25

26 </testnode> <homepage> < >. </testnode> <image> < >. Βασικοί όροι ενός JSON-LD εγγράφου είναι οι Χρησιμοποιείται για να δηλωθούν συντομεύσεις του εγγράφου κατά την ανάθεση όρων και Το αναγνωριστικό ενός κόμβου, αν απουσιάζει τότε θεωρείται τοπικός ανώνυμος Περιγράφει τον τύπου του κόμβου. Βασική ιδιότητα του Ορίζει το προκαθορισμένο πρόθεμα που χρησιμοποιείται στο παρόν Το βασικό IRI (Internationalized Resource Identifier) στο οποίο βασίζονται τα σχετικά IRI που περιγράφονται στο κείμενο. Στη συνέχεια, παρατίθεται ένα ακόμη παράδειγμα JSON-LD με τη χρήση επιπλέον όρων και πως αυτοί ερμηνεύονται. 1 { 2 "@context": { 3 "name": " 4 "image": { 5 "@id": " 6 "@type": "@id" 7 }, 8 "homepage": { 9 "@id": " 10 "@type": "@id" 12 } 13 }, 14 { 15 "name": "Manu Sporny", 16 "homepage": " 17 "image": " 18 } 19 } Απόσπασμα κώδικα 2: Παράδειγμα εγγράφου JSON-LD (IΙ) Στο παραπάνω παράδειγμα παρουσιάζεται ένας τοπικός κόμβος ο οποίος χρησιμοποιώντας ένα επιπλέον λεξιλόγιο, το schema.org περιγράφει τα ίδια δεδομένα που εμφανίστηκαν και στο πρώτο παράδειγμα. Αναλύοντας αυτή τη φορά το περιεχόμενο 26

27 Η εμφάνιση του όρου name (Απόσπασμα κώδικα 2, γρ. 3) θα πρέπει να ταυτίζεται με τον όρο Έτσι αποδίδεται πληροφορία για τον τύπο της σχέσης. Ποια είναι δηλαδή η σημειολογία του name. Ανατρέχοντας στο IRI που το περιγράφει αποκτάται πληροφορία για τον ορισμό του. Ο όρος image (Απόσπασμα κώδικα 2, γρ. 4), έχει παραπάνω ιδιότητες. Έτσι πρέπει να χρησιμοποιηθεί ο για να τον ταυτιστεί με τον όρο Παράλληλα με τη σχέση δηλώνει ότι ο τύπος του image είναι ένα αναγνωριστικό, ένα IRI και όχι ένα αλφαριθμητικό. Εξετάζοντας την ερμηνεία στο λεξιλόγιο, βλέπει κανείς ότι αναμένει ένα URL το οποίο αντιστοιχεί σε μια εικόνα. Ο όρος homepage δεν περιέχει κάποια νέα πληροφορία. Οι αντίστοιχες προτάσεις διαμορφώνονται ως εξής: < Κόμβος_Χ> < < Manu Sporny >. <Κόμβος_Χ> < < <Κόμβος_Χ>< ng>. Παρατηρώντας τις παραπάνω προτάσεις που ερμηνεύουν το JSON-LD αντιλαμβάνεται κανείς ότι δεν υπάρχει κάποιο IRI που περιγράφει τον κόμβο. Επομένως οι προτάσεις αναφέρονται σε ένα τοπικό υποκείμενο <Κόμβος_Χ>. Επίσης οι ιδιότητες-σχέσεις έχουν αντικατασταθεί από Τέλος, δύο από τα τρία αντικείμενα είναι πλέον IRI που μπορούν να αναφέρονται σε κόμβους ή απλά σε πόρους. 27

28 Διάγραμμα 4: Παράδειγμα γράφου σε μορφή JSON-LD Λεξιλόγια Τα λεξιλόγια (vocabularies) είναι κομμάτι του πλαισίου RDF ώστε να περιγράψουμε τις διάφορες οντότητες, να αποδώσουμε νόημα στα δεδομένα και να ορίσουμε τη σημασιολογία. Το RDF είναι το μοντέλο δεδομένων και χρησιμοποιείται μαζί με τα λεξιλόγια. Η βάση όλων των λεξιλογίων είναι το RDFS [3] το οποίο μαζί με το OWL [15] αποτελούν γενικεύσεις και χρησιμοποιούνται σαν βάση για ειδικότερα λεξιλόγια. Τα λεξιλόγια αυτά χαρακτηρίζονται από λογική συνέπεια. Δηλαδή, εξάγονται συμπεράσματα από τις σχέσεις που περιγράφουν χωρίς να είναι σαφώς δηλωμένα στο γράφο μέσω συνεπαγωγής. Το βασικό λεξιλόγιο που προσφέρει το RDFS φαίνεται παρακάτω (Διάγραμμα 5). Καθώς το RDFS είναι ένα μετα-λεξιλόγιο, χρησιμοποιούνται πολύ πιο στοχευμένα λεξιλόγια για την περιγραφή των ποικίλων εννοιών που συναντώνται στο διαδίκτυο. Εδώ υπάρχει μια μεγάλη γκάμα επιλογών. Ο ιστότοπος LOV [16], που αποτελεί ευρετήριο τέτοιων λεξιλογίων, περιέχει εξακόσια και πλέον λεξιλόγια για την περιγραφή των δεδομένων. Επιλέχθηκε η χρήση του schema.org λόγω της ευρείας χρήσης του, καθώς αναγνωρίζεται από όλες τις μεγάλες μηχανές αναζήτησης. 28

29 Διάγραμμα 5: Βασικές κλάσεις και ιδιότητες του RDFS Schema.org Το schema.org [17] προσπαθεί να περιγράψει την πληθώρα των δεδομένων που αφορούν καθημερινές δραστηριότητες στο διαδίκτυο. Δημιουργήθηκε το 2011 και αποτέλεσε μια σύμπραξη των εταιριών Google, Microsoft, Yahoo και Yandex ώστε να καθορίσουν ένα κοινό πρότυπο από δομημένα δεδομένα (structured data) ώστε να χρησιμοποιηθεί σε μεγαλύτερη κλίμακα και πιο συστηματικά. Υπήρξαν και προηγούμενες μεμονωμένες προσπάθειες οι οποίες όμως δεν είχαν τα αναμενόμενα αποτελέσματα. Έχει εκδοθεί με βάση την άδεια Apache License 2.0, επομένως είναι ανοικτού κώδικα με κάποιους περιορισμούς. Παρακάτω φαίνεται πως περιγράφει το schema.org μια ταχυδρομική διεύθυνση, η οποία έχει ένα κοινό μοτίβο σε ολόκληρο τον κόσμο (Εικόνα 1). Εικόνα 1: Περιγραφή ταχυδρομικής διεύθυνσης κατά το schema.org Η δομή του, ακολουθεί το RDFS, και περιέχει ένα σύνολο από κλάσεις ή αλλιώς τύπους δεδομένων με πιο γενικό όλων την κλάση Thing, η οποία είναι υπερκλάση. Ακολουθούν έπειτα μια σειρά από υποκλάσεις οι οποίες όλες κληρονομούν ιδιότητες από τις προγενέστερες. Έχουμε μια σειρά από ιδιότητες που αποδίδονται σε κλάσεις. Οι 29

30 ίδιες οι ιδιότητες μπορούν να αναφέρονται σε κλάσεις, δεχόμενες σαν τιμές ολόκληρες κλάσεις. Ένα τέτοιο παράδειγμα είναι το ακόλουθο (Απόσπασμα κώδικα 3). 1 "@context": " 2 "location": { 3 "@type": "Place", 4 "address": { 5 "@type": "PostalAddress", 6 "addresslocality": "Denver" 7 "addressregion": "CO", 8 "postalcode": "80209", 9 "streetaddress": "7 S. Broadway" 10 } 11 } Απόσπασμα κώδικα 3: Παράδειγμα χρήσης schema.org (I) Μια ταχυδρομική διεύθυνση έχει συγκεκριμένα στοιχεία που την περιγράφουν. Μπορούν να αποδοθούν όλα σε ένα αλφαριθμητικό αλλά έτσι χάνεται πληροφορία. Σε αυτή την περίπτωση χρησιμοποιούνται εμφωλευμένοι κόμβοι και πεδία με σαφή ορισμό για να την περιγραφή. Με αυτόν τον τρόπο παρέχεται πρόσβαση σε κάθε ξεχωριστό πεδίο που περιγράφει την ταχυδρομική διεύθυνση, όπως στην πόλη (Απόσπασμα κώδικα 3, γρ. 6) ή τον ταχυδρομικό κώδικα (Απόσπασμα κώδικα 3, γρ. 8) για παράδειγμα. Ένα λεξιλόγιο είναι μια σύμβαση που ορίζεται. Αν αυτή γίνει αποδεκτή τότε μπορεί να αναγνωριστεί η αξία του σημασιολογικού ιστού. Στο Κεφάλαιο 3, θα εξεταστεί περαιτέρω η χρήση των λεξιλογίων μιας και αποτελεί σημαντική παράμετρο στην παρούσα εργασία. Λεξιλόγιο HYDRA Το HYDRA [18] [19] είναι άλλο ένα λεξιλόγιο που θα χρησιμοποιηθεί. Αποτελεί ένα συνεκτικό λεξιλόγιο που σκοπό έχει να περιγράψει τα APIs που προσφέρει ένας server ώστε να διευκολύνει την εναλλαγή των καταστάσεων ενός client. Το HYDRA εφαρμόζεται στα πλαίσια της αρχιτεκτονικής RESTful και προσπαθεί να περιγράψει τη διαδικασία HATEOAS. Σκοπός του HYDRA είναι η δυνατότητα δημιουργίας γενικευμένων πελατών (client) που θα μπορούσαν να διατρέξουν αυτόματα έναν ιστότοπο ή έναν πόρο γενικότερα. Μέσω του HYDRA περιγράφεται ένα API σαν ένας γράφος RDF. Ένα σύνολο δηλαδή από προτάσεις από τις οποίες εξάγονται συμπεράσματα και η περιήγηση πραγματοποιείται μέσω επαγωγικής λογικής και όχι μέσω έτοιμων διαδικασιών. Ολόκληρο το λεξιλόγιο φαίνεται πολύ περιγραφικά στο διάγραμμα παρακάτω (Διάγραμμα 6). Η δομή του λεξιλογίου ξεκινά από την κλάση ApiDocumentation, η οποία περιλαμβάνει μια σειρά από κλάσεις supportedclass που περιγράφουν τα παρεχόμενα δεδομένα. Οι υποστηριζόμενες κλάσεις (στιγμιότυπα Class) περιέχουν τις ιδιότητες 30

31 (supportedproperty) και τις αντίστοιχες ενέργειες (supportedoperation). Έπειτα υπάρχουν μία σειρά από βοηθητικές οντότητες. Τέτοιες αφορούν τις ιδιότητες (SupportedProperty), τις ενέργειες (Operation), τη μορφή των υπερσυνδέσμων (Link, IriTemplate) καθώς και κλάσεις για τη διαχείριση σφαλμάτων. Το λογισμικό ακόμη δεν μπορεί να αντιληφθεί το περιεχόμενο και τα συμφραζόμενα γύρω από τους υπερσυνδέσμους ώστε να περιηγηθεί μέσα στο Web όπως ο άνθρωπος. Για να καταφέρει να προσεγγίσει αυτή τη δραστηριότητα χρειαζόμαστε σχέσεις και χαρακτηριστικά ώστε σε ένα καθορισμένο περιβάλλον να καταφέρει να πραγματοποιήσει τις κατάλληλες αντιστοιχίες και να φτάσει στον στόχο του. Η αυτοματοποίηση της διαδικασίας αναγνώρισης ενός API είναι εφικτή μέσω του HYDRA το οποίο αποτελεί το βασικότερο συστατικό της υλοποίησης. Αποτελεί αυτή τη στιγμή προσχέδιο προς κατάθεση στο W3C. Η ανάπτυξή του συνεχίζεται, αλλά δεν υπάρχει εκείνο το πλήθος παραδειγμάτων και εφαρμογών το οποίο να επιτρέπει σε πλήθος προγραμματιστών να το υιοθετήσει. 31

32 Διάγραμμα 6: Οι σχέσεις ανάμεσα στις οντότητες του HYDRA [18] Αρχιτεκτονική REST Το πρότυπο REST αποτελεί κοινό τόπο σήμερα, στην ανάπτυξη διαδικτυακών υπηρεσιών. Είναι γνωστό σε μεγάλη μερίδα προγραμματιστών ανεξάρτητα αν ακολουθούν ή όχι το πλήρες πρότυπο. Η βασική έννοια που το χαρακτηρίζει είναι η αποσύζευξη μεταξύ server - client. Όπως περιγράφει ο Roy Fielding [20] [21], με τον ίδιο τρόπο που χρησιμοποιείται ο ίδιος φυλλομετρητής για την περιήγηση σε όλες τις ιστοσελίδες, με τον ίδιο τρόπο θα έπρεπε να χρησιμοποιείται και ένας client ο οποίος θα είναι σε θέση να επικοινωνεί με διαφορετικούς servers δίχως να γνωρίζει λεπτομέρειες για το μοντέλο δεδομένων που χρησιμοποιεί ο καθένας ή να γνωρίζει εκ των προτέρων που να απευθυνθεί (IRI). Το πρότυπο REST αποτελεί προαπαιτούμενο της υλοποίησης. Στη συνέχεια περιγράφονται οι έξι περιορισμοί οι οποίοι πρέπει να ισχύουν και θα αναλυθούν παρακάτω. 32

33 i. Client Server Ο server και ο client πρέπει να είναι αποσυζευγμένοι. Η αναπαράσταση των πόρων αφορά τον client. Ο server οφείλει μόνο να προσφέρει τους πόρους σε μια μορφή κατανοητή από τον client. Χαρακτηριστικό παράδειγμα είναι η διαφορετική αναπαράσταση μίας ιστοσελίδας ανάλογα με τη συσκευή ή τον φυλλομετρητή που χρησιμοποιεί κανείς. ii. Stateless Ο server δεν κρατάει στοιχεία για τη μεταξύ τους επικοινωνία. Ο client είναι υπεύθυνος για τη διαχείριση της επικοινωνίας και της μεταξύ τους συνεδρίας. Αν αναμένεται κάποια απάντηση από το server τότε ο client βρίσκεται σε μεταβατική κατάσταση. Η μετάβαση από κατάσταση σε κατάσταση μπορεί να επιτευχθεί μέσω IRI. iii. Cachable Η δυνατότητα για προσωρινή αποθήκευση μιας απάντησης οφείλει να είναι εφικτή, αλλά να δηλώνεται ρητά. Από την πλευρά του server, μιας και η επικοινωνία δεν έχει κατάσταση, θα μπορούσαν να αποθηκευτούν προσωρινά απαντήσεις σε ερωτήματα που είναι συχνά από πλήθος clients. Με αυτόν τον τρόπο εξοικονομούνται πόροι συστήματος και προσφέρεται καλύτερη εμπειρία χρήστη. iv. Layered System Η διαστρωμάτωση (layering) επιτρέπει την επέκταση του συστήματος, δίχως να απασχολεί η επικοινωνία με τον client, καθώς οι λειτουργικότητες χωρίζονται σε πολλαπλά επίπεδα. Με αυτό τον τρόπο βελτιστοποιείται η διαχείριση του φόρτου εργασίας. v. Code on demand Η δυνατότητα αυτή δεν είναι απαραίτητη αλλά επεκτείνει τις προσφερόμενες δυνατότητες μιας εφαρμογής. Εξετάζοντας την απαίτηση αντίστροφα, επιτρέπει τη μείωση της κίνησης-φόρτου, προσφέροντας πιο λιτές αναπαραστάσεις. vi. Uniform Interface Αναγνώριση πόρων Κάθε πόρος αναγνωρίζεται μέσω URI, και δεν ταυτίζεται με την αναπαράστασή του. 33

34 Διαχείριση του πόρου μέσω της αναπαράστασής του Η αναπαράσταση του πόρου επιτρέπει στον client να επεξεργαστεί τον πόρο που διαθέτει. Για παράδειγμα μαζί με μία φόρμα προς συμπλήρωση ο client γνωρίζει το URI στην οποία θα πραγματοποιήσει POST. Αυτοπεριγραφικά μηνύματα Κάθε μήνυμα/επικοινωνία οφείλει να περιέχει επαρκή πληροφορία για τον client ώστε να μπορεί να το διαχειριστεί πλήρως. HATEOAS Η διαδικασία με την οποία ο client μεταβαίνει από κατάσταση σε κατάσταση πραγματοποιείται μέσω του πολυμεσικού περιεχομένου. Το πολυμεσικό περιεχόμενο θα μπορούσε να περιγραφεί ως διασυνδεδεμένα μέσα αναπαράστασης, τα οποία περιέχουν τόσο την πληροφορία όσο και τα εργαλεία για να περιηγηθεί κανείς μέσα σε αυτά. Κατά την αναζήτηση σε μια ιστοσελίδα ο υπερσύνδεσμος είναι εκείνος που μας οδηγεί στη ζητούμενη πληροφορία. Αντίστοιχα για διαφορετικά μέσα αναπαράστασης θα παρέχονται διαφορετικά ήδη ελέγχου. Για παράδειγμα σε ένα κολλάζ από εικόνες, πατώντας σε μία από αυτές θα μπορούσε να μας οδηγήσει σε μία άλλη σειρά εικόνων. Με τον ίδιο τρόπο το λεξιλόγιο του HYDRA προσπαθεί να περιγράψει έναν σύνολο όρων ώστε αυτοί οι υπερσύνδεσμοι να αποκτούν σαφές νόημα για έναν πράκτορα λογισμικού SPARQL Η SPARQL αποτελεί το εργαλείο με το οποίο ανακτάται πληροφορία από ένα σετ δεδομένων RDF. Είναι σε θέση να απαντήσει ερωτήματα, εξετάζοντας έναν γράφο με προτάσεις. Αν εξεταστεί η SPARQL σε σύγκριση με την SQL η οποία αφορά σχεσιακές βάσεις δεδομένων, θα έλεγε κανείς ότι διαχειρίζεται μια βάση δεδομένων όπου όλα τα δεδομένα είναι αποθηκευμένα στη μορφή υποκείμενο, ιδιότητα, αντικείμενο ή για να χρησιμοποιήσουμε τους ακριβείς όρους subject, predicate, object. Θα μπορούσε να παρομοιαστεί πιο σωστά με NoSQL [22] βάσεις δεδομένων όπως η MongoDB [23]. Η SPARQL μπορεί να επιστρέψει μεμονωμένα αποτελέσματα στη μορφή IRI, που είναι το αναγνωριστικό για μεμονωμένους όρους ή ακόμη και ολόκληρους γράφους. Οι βασικές εντολές της περιγράφονται από τους παρακάτω όρους: SELECT: Όπου επιστρέφει σε μορφή πίνακα τα αναγνωριστικά που επιλύουν τις δοσμένες προτάσεις. 34

35 ASK: Μία πρόταση ή σειρά από αυτές θέτεται προς επαλήθευση και επιστρέφει αληθές/ψευδές. DESCRIBE: Θέτοντας ένα ερώτημα μέσω DESCRIBE αναμένεται να επιστρέψει όχι μόνο τα αναγνωριστικά που επαληθεύουν τις προτάσεις, αλλά να τα περιγράψει. Δηλαδή να επιστρέψει όλες τις σχέσεις προτάσεις που σχετίζονται με αυτά. Επιστρέφει δηλαδή ένα κομμάτι του γράφου. CONSTRUCT: Χρησιμοποιείται για να επιστρέψει πληροφορίες σε RDF μορφή. WHERE: Ο όρος αυτός υποδηλώνει τις συνθήκες οι οποίες οφείλουν να ισχύουν. Παράδειγμα SPARQL Ποιες είναι οι πρωτεύουσες των χωρών της Αφρικής; PREFIX ex: SELECT?capital?country WHERE {?x ex:cityname?capital; ex:iscapitalof?y.?y ex:countryname?country; ex:isincontinent ex:africa. } Σε ελεύθερο κείμενο: - Για X όπου το όνομα της πόλης είναι capital και - για Χ το οποίο είναι πρωτεύουσα της Υ, όπου - η Υ έχει όνομα χώρας το country, και - η Υ βρίσκεται στην Αφρική Μιας και οι μεταβλητές που έχουν επιλεγεί προς επίλυση είναι οι country και capital, θα ληφθεί ένας πίνακας με κάθε πρωτεύουσα και χώρα ανά γραμμή. 2.2 Σχετική Βιβλιογραφία Με το εύρος των επιλογών σε διαδικτυακές υπηρεσίες που υπάρχει σήμερα αρχικά δημιουργήθηκαν ιστοσελίδες για να τις καταγράψουν και να διευκολύνουν τους προγραμματιστές στην εξεύρεση αυτών. Παράλληλα αναζητήθηκαν τρόποι για την αυτοματοποίηση των διαδικασιών της συγγραφής APIs και της τεκμηρίωσής τους. Στο πεδίο της αυτόματης εξεύρεσης (autodiscoverability) και στη χρήση τεχνολογιών του 35

36 σημασιολογικού ιστού δεν υπήρξε σημαντική πρόοδος. Ενώ είναι διαθέσιμα ένα πλήθος από σημασιολογικά δεδομένα, αυτά παραμένουν πίσω από SPARQL endpoints, τα οποία δεν είναι εύκολα προσβάσιμα, τουλάχιστον στον βαθμό που είναι τα δεδομένα προσφερόμενα από RESTful APIs, ενώ δεν μπορούν να διαχειριστούν αξιόπιστα μεγάλο όγκο ερωτημάτων Αυτόματη τεκμηρίωση RESTful APIs Υπάρχει μια σειρά από πρότυπα τα οποία καθορίζουν τον τρόπο με τον οποίο αυτοματοποιείται η τεκμηρίωση (documentation) μιας RESTful εφαρμογής. Αντίστοιχα είναι διαθέσιμες μια σειρά από ολοκληρωμένες λύσεις που διευκολύνουν τη διαδικασία. Τέτοιες λύσεις είναι το RAML [24], json-schema [25] και το OpenAPI [26] (Swagger). Η απουσία κάποιας σημασιολογίας επί των δεδομένων όμως δεν επιτρέπει τη χρήση τους στα πλαίσια του σημασιολογικού ιστού. Το json-schema αποτελεί ένα πρότυπο που βοηθά την περιγραφή των δεδομένων αναλυτικά με έμφαση στους περιορισμούς και στις αναμενόμενες τιμές, με αντίστοιχο τρόπο που περιγράφονται σε λεξιλόγια οντοτήτων. Βέβαια ζητούμενο είναι η χρήση κοινών περιγραφών όσο το δυνατόν γίνεται. Μπορούν να αξιοποιηθούν τέτοιες λύσεις στα πλαίσια μιας πληρέστερης υλοποίησης RESTdesc Η τεχνολογία RESTdesc [27], αποτελούσε την πλησιέστερη λύση στο πρόβλημα που έχει θέσει. Ο τρόπος που προσεγγίζει το πρόβλημα της δημιουργίας και εξεύρεσης APIs συμπλέει με την περιγραφή που δόθηκε. Χρησιμοποιεί επίσης μία σειρά από τεχνολογίες του Semantic Web οι οποίες περιγράφηκαν στο παρών κεφάλαιο. Αξιοποιεί τα υπάρχοντα λεξιλόγια, και τους RDF γράφους ώστε να περιγράψει ένα API. Δυστυχώς όμως δεν υπάρχουν διαθέσιμα παραδείγματα και εργαλεία ώστε να δημιουργηθεί ένα δοκιμαστικό περιβάλλον. Παράλληλα, η χρήση της μορφοποίησης N3 [11] για την περιγραφή των σημασιολογικών δεδομένων δεν είναι εύχρηστη και σαφώς ορισμένη Call by Meaning Το πρόβλημα που θα εξεταστεί αρχικά ορίστηκε στην εργασία Call by Meaning [28]. Όπου καταδεικνύεται η δυσκαμψία στην αξιοποίηση Web APIs, καθώς πρέπει να είναι γνωστή τόσο η διεύθυνση του API, όσο και η αναλυτική περιγραφή του ώστε να χρησιμοποιηθεί από τον εκάστοτε προγραμματιστή. Η λύση που προτείνει η εργασία αυτή, ονομάζεται χαρακτηριστικά call by meaning, δηλαδή κλήση με βάση την περιγραφόμενη έννοια. Στα πλαίσια της βάσης γνώσης CyC [29] υλοποιείται μια πρότυπη γλώσσα προγραμματισμού. Με τη χρήση αυτού του συντακτικού 36

37 περιγράφονται τα ζητούμενα δεδομένα χρησιμοποιώντας φυσική γλώσσα. Έπειτα χρησιμοποιώντας προτασιακή λογική και τις δυνατότητες εξαγωγής συμπερασμάτων του CyC, πραγματοποιούνται ερωτήματα σε φυσική γλώσσα και λαμβάνονται απαντήσεις με τα αντίστοιχα αντικείμενα/κλάσεις που προσφέρουν τις ζητούμενες υπηρεσίες. Η προσέγγιση αυτή εμφανίζει μεγάλο ενδιαφέρον αλλά δυστυχώς οι απαιτήσεις της ξεπερνούν κατά πολύ το σημερινό διαδίκτυο. Η σημασιολογία στον ιστό περιπλέκεται σε μεγάλο βαθμό με τη τεχνητή νοημοσύνη και τη δυνατότητα συλλογιστικής της μηχανής. Αφενός διαταράσσει το περιβάλλον στο οποίο ο προγραμματιστής έχει μάθει να δουλεύει και αφετέρου αποζητά υπολογιστική ισχύ που ένας client ή ακόμη και ένας server δεν διαθέτουν. Η εφαρμογή αυτής της λύσης δεν μπορεί στην παρούσα φάση να ενσωματωθεί ενώ ακόμη η ίδια η έννοια του σημασιολογικού ιστού δεν έχει εγκαθιδρυθεί. 37

38 3 Αυτόματη εξεύρεση διαδικτυακών υπηρεσιών 3.1 Ορισμός Στην ενότητα αυτή παρουσιάζεται αναλυτικά το πρόβλημα το οποίο εξετάζει η παρούσα εργασία. Η βασική παρατήρηση είναι η έλλειψη ενός αυτόνομου client, ο οποίος θα είναι σε θέση να επικοινωνήσει με μια σειρά από Web APIs. Αναμένεται δηλαδή από έναν πράκτορα λογισμικού να είναι σε θέση να λάβει μια σειρά από δεδομένα και να καταφέρει να επιστρέψει ένα αποτέλεσμα. Επίσης ζητούμενο είναι ο agent να είναι σε θέση να επικοινωνήσει με διάφορες υπηρεσίες (Web APIs) ώστε να συγκεντρώσει τις απαιτούμενες πληροφορίες, να τις επεξεργαστεί και να επιστρέψει μια σειρά αξιοποιήσιμων δεδομένων. Ο πράκτορας, πρέπει να είναι σε θέση να ανακαλύψει αυτόματα τα APIs που θα χρησιμοποιήσει αξιοποιώντας ένα σετ περιγραφικών πληροφοριών, δίχως προκαθορισμένη κλήση των παρόχων (servers), αλλά μέσα από μια διαδικασία αναζήτησης και αντιστοίχισης. Η διαδικασία της επίλυσης του προβλήματος εντός των πλαισίων του σημερινού διαδικτύου φέρνει στο προσκήνιο τον σημασιολογικό ιστό. Το τεχνολογικό και θεωρητικό υπόβαθρο υπάρχουν ήδη για να επιτευχθεί ο παραπάνω στόχος. Αυτό που απουσιάζει είναι μια σαφής μεθοδολογία καθώς και ένα παράδειγμα το οποίο να παρουσιάζει τις δυνατότητες αυτές. 3.2 Ανάπτυξη Λογισμικού για το Διαδίκτυο Η προσθήκη λειτουργικότητας με την αξιοποίηση μιας υπάρχουσας υπηρεσίας αποτελεί βασικό κομμάτι της ανάπτυξης Web εφαρμογών. Σήμερα είναι κοινός τόπος να χρησιμοποιούνται αρκετές υπηρεσίες συνδυαστικά, προσφερόμενες από πολλούς και διαφορετικούς παρόχους. Σε ένα ηλεκτρονικό κατάστημα για παράδειγμα, τα σχόλια για τα προϊόντα διαχειρίζονται με μια υπηρεσία, τα βίντεο που παρουσιάζουν τα προϊόντα με μία άλλη και οι πληρωμές με μία τρίτη υπηρεσία. Το παράδειγμα αυτό θα μπορούσε να το χαρακτηρίσει κανείς τυπικό σήμερα. Αυτό σημαίνει ότι κατά την υλοποίηση ο προγραμματιστής οφείλει να διαβάσει και να υλοποιήσει τρεις διαφορετικούς client ώστε να επικοινωνήσει με τα εκάστοτε APIs. Διαφορετικά, θα μπορούσε να ενσωματώσει τρεις έτοιμους client που προσφέρουν οι πάροχοι των υπηρεσιών. Και οι δύο λύσεις απαιτούν την εξοικείωση με συγκεκριμένο λογισμικό και σετ δεδομένων για τη χρήση της κάθε υπηρεσίας. Σε αυτή τη διαδικασία λοιπόν μπορεί οι εφαρμογές να είναι συμβατές με το πρότυπο RESTful, αλλά δεν υπάρχει κάποιος πράκτορας λογισμικού οποίος θα μπορέσει να τις 38

39 χρησιμοποιήσει. Αυτό που διατίθεται είναι μια σειρά εργαλείων και τεχνολογιών για την αυτοματοποιημένη παραγωγή τεκμηρίωσης και κώδικα για τον χρήστη της υπηρεσίας όπως αναφέρθηκε και στην Ενότητα Ο σημασιολογικός ιστός σήμερα Μία απλή αναζήτηση Παραδείγματα αξιοποίησης του σημασιολογικού ιστού σήμερα εμφανίζονται καθημερινά, αλλά ενώ αντιλαμβάνεται κανείς την αξία του δεν αναγνωρίζεται σαν τεχνολογία πίσω από το αποτέλεσμα. Πιθανόν να δημιουργείται η πεποίθηση ότι υπάρχει ισχυρή υπολογιστική ισχύς πίσω από τέτοια παραδείγματα, ενώ στην πραγματικότητα υπάρχει μια πολύ πρακτική σύμβαση. Εικόνα 2: Παράδειγμα αναζήτησης στην Google (I) Ένα τέτοιο παράδειγμα αποτελεί η μηχανή αναζήτησης Google μέσω του λεγόμενου Knowledge Graph [30] όπως φαίνεται παραπάνω (Εικόνα 2). Όπου για παράδειγμα η αναζήτηση ενός προσώπου, πέρα από τα αποτελέσματα που καταφέρνει να συγκεντρώσει σε μορφή υπερσυνδέσμων, επιστρέφει και μια κάρτα με συνοπτικές πληροφορίες στα δεξιά. Εκεί έχει συγκεντρώσει τις βασικές πληροφορίες για το ζητούμενο πρόσωπο από διάφορες πηγές τις οποίες η μηχανή αναζήτησης ήταν σε θέση να αντιληφθεί. Η έννοια της αντίληψης αφορά την ικανότητα του να εξετάσει τα δεδομένα και μέσω συσχετίσεων να τα συνδυάσει και να τα επιστρέψει ως απάντηση. Η λειτουργία του Knowledge Graph 39

40 βασίζεται ακριβώς στο πλήθος των σημασιολογικών δεδομένων που υπάρχουν στο διαδίκτυο. Αν τα δεδομένα δεν διαθέτουν την αντίστοιχη περιγραφή/σημειολογία όσο ευφυής και να είναι ο αλγόριθμος, δεν θα είναι σε θέση να διαχειριστεί τόσο μεγάλο όγκο δεδομένων σε επιθυμητό χρονικό διάστημα. Η τεχνολογία του Knowledge Graph ανατρέχει σε δεδομένα τα οποία πριν έχουν ήδη επεξεργαστεί και αποθηκευτεί σε μία δομή δεδομένων με χαρακτηριστικά γράφου. Τα δεδομένα αυτά λοιπόν έχουν ήδη δημοσιευθεί με τα μεταδεδομένα τους στο Web και είναι προσπελάσιμα. Η δημιουργία του Knowledge Graph σχετίζεται και χρονικά με τη σύσταση της ομάδας πίσω από το λεξιλόγιο schema.org. Από το παραπάνω παράδειγμα, βλέπει κανείς ότι ένας κρίσιμος όγκος δεδομένων ο οποίος διαθέτει σημειολογία είναι προσβάσιμος. Αυτό που απουσιάζει είναι υπηρεσίες οι οποίες βασίζονται στον σημασιολογικό ιστό, και μπορούν να αξιοποιήσουν τόσο τα υπάρχοντα δεδομένα όσο και να δημιουργήσουν νέα Σημασιολογική σήμανση δεδομένων Η επιλογή του schema.org για την περιγραφή των δεδομένων βασίστηκε στο κριτήριο της δημοτικότητάς του ανάμεσα στους προγραμματιστές του διαδικτύου και στην αξιοποίησή του από τις μηχανές αναζήτησης. Όμως, παρά τη δημοτικότητα του schema.org σε σχέση με τα άλλα λεξιλόγια, δεν είναι τόσο κοινότυπο σαν εφαρμοζόμενη τεχνολογία [31]. Τα στοιχεία που συλλέχθηκαν είναι υποσχόμενα, αλλά δείχνουν ότι η μετάβαση στον σημασιολογικό ιστό αφορά συγκεκριμένα πεδία όχι το ευρύτερο διαδίκτυο. Διάγραμμα 7: Υιοθέτηση λεξιλογίου schema.org (I) [similartech.com] 40

41 Διάγραμμα 8: Υιοθέτηση λεξιλογίου schema.org (II) [similartech.com] Τα διαγράμματα που παρουσιάζονται παραπάνω από την υπηρεσία similartech.com [31] οπτικοποιούν το βαθμό διείσδυσης της χρήση του λεξιλογίου schema.org. Όπως φαίνεται στο Διάγραμμα 7, στους εκατό χιλιάδες δημοφιλέστερους ιστότοπους τα ποσοστά χρήσης του λεξιλογίου είναι κάτω από 7%. Οι όροι που εμφανίζονται έχουν γενική σημειολογία όπως είναι η περιγραφή μιας ιστοσελίδας ή ενός οργανισμού. Η μικρή απόκλιση μεταξύ των διαφόρων όρων μπορεί να ερμηνευθεί από το γεγονός ότι ένας ιστότοπος χρησιμοποιεί μια σειρά από όρους και όχι μεμονωμένους. Εξετάζοντας το Διάγραμμα 8 το οποίο σαν δείγμα χρησιμοποιεί το σύνολο των ιστοσελίδων (10 10 ) που έχει επεξεργαστεί η συγκεκριμένη υπηρεσία η εικόνα είναι πολύ διαφορετική. Οι όροι που συναντήθηκαν στις πιο δημοφιλής ιστοσελίδες, βρίσκονται στο 1%, ενώ στα επίπεδα του 10% εμφανίζονται όροι που σχετίζονται με προσωπικά ιστολόγια (blogs). Η εξήγηση αυτή βασίζεται στο γεγονός ότι τα περισσότερα ιστολόγια παρέχονται σαν υπηρεσία από εταιρίες όπως η Google (blogspot.com) ή η Wordpress. Επομένως η χρήση όρων για την περιγραφή του περιεχομένου δεν αφορά μονάχα τον χρήστη αλλά και την ίδια την εταιρία. Οι αριθμοί φαίνονται απογοητευτικοί και αιτία είναι ο τρόπος εισαγωγής του σημασιολογικού ιστού καθώς και η έλλειψη εργαλείων. Δόθηκε ιδιαίτερη βαρύτητα στις οντότητες και στον τρόπο που αυτές περιγράφουν τα δεδομένα σε αφηρημένο επίπεδο. Παράλληλα όμως δεν υλοποιήθηκαν τα κατάλληλα εργαλεία που θα επέτρεπαν σε έναν προγραμματιστή να πειραματιστεί με τις νέες τεχνολογίες. Δημιουργήθηκε λοιπόν η εντύπωση ότι η μετάβαση στον σημασιολογικό ιστό ήταν μια πολύπλοκη διαδικασία που απαιτούσε αρκετό χρόνο ενώ οι δυνατότητές του δεν ήταν ακόμη απτές. 41

42 Διάγραμμα 9: Χρήση της κλάσης schema:recipe [similartech.com] Η χρήση της κλάσης schema:recipe περιγράφει μία συνταγή μαγειρικής. Η ίδια υπηρεσία μας δίνει μια σειρά από στοιχεία, μερικά από τα οποία φαίνονται παραπάνω (Διάγραμμα 9). Το πλήθος των ιστοσελίδων που χρησιμοποιούν την κλάση ανέρχεται συνολικά στα Υπάρχει επομένως αρκούντως μεγάλος αριθμός επιλογών. Ενώ τα δέκα δημοφιλέστερα έχουν παραπάνω από δέκα εκατομμύρια προβολές. Οι πιο δημοφιλής ιστοσελίδες λοιπόν χρησιμοποιούν όρους από λεξιλόγια για να περιγράψουν τα δεδομένα τους, καθώς έχουν αντιληφθεί την αναγκαιότητα της σημειολογίας. Παράλληλα αναμένεται να είναι και αυτοί που θα υιοθετήσουν νέες τεχνολογίες στην προσπάθειά τους να παραμείνουν ανταγωνιστικοί. Πρέπει να σημειωθεί ότι ένας από τους βασικούς λόγους που ξεκίνησαν να υιοθετούνται αυτές οι πρακτικές βασίζεται στο κίνητρο που δημιούργησε η χρήση τους από κολοσσούς του Web. Η βελτιστοποίηση ενός ιστότοπου απέναντι στους αλγορίθμους προσπέλασης και κατάταξης των μηχανών αναζήτησης (Search Engine Optimization) ήταν αυτό που οδήγησε πλήθος από ιστοσελίδες να προσθέσουν δομημένα χαρακτηριστικά στην πληροφορία που παρείχαν. Επίσης, διάφορες υπηρεσίες κοινωνικής δικτύωσης χρησιμοποιούν μεταδεδομένα για την καλύτερη ενσωμάτωση της πληροφορίας. Τέτοιο παράδειγμα είναι το OpenGraph [32] του Facebook. Με αυτό τον τρόπο είναι σε θέση να παρουσιάζουν σε συνοπτική και συστηματική μορφή την πληροφορία στον χρήστη όταν για παράδειγμα χρησιμοποιεί παραπομπές από άλλες υπηρεσίες. Τα παραπάνω, ίσως είναι ο μόνος λόγος που παρατηρείται σταθερή μετάβαση προς τον σημασιολογικό ιστό. Είναι εμφανής η πίεση που ασκήθηκε από τη μεριά των διαχειριστών της πληροφορίας σήμερα. Από τη μία μπορεί να χαρακτηριστεί θετικά η κατεύθυνση αυτή, από την άλλη διαφαίνεται η τεράστια επιρροή στον τρόπο που δομείται το Web, αν αναλογιστεί κανείς ότι το τεχνολογικό υπόβαθρο προϋπήρχε. Τα λεγόμενα microformats [33] δημιουργήθηκαν από το 2005 ενώ παράλληλα οι μηχανές αναζήτησης προωθούσαν τα δικά τους σημασιολογικά λεξιλόγια. Η χρήση βέβαια των microformats δεν ήταν διευρυμένη. Οφείλουμε να κρατήσουμε τα κίνητρα που οδηγούν στην υιοθέτηση μιας τεχνολογίας ή όχι, ειδικά σε ένα ανταγωνιστικό 42

43 περιβάλλον όπως είναι το Web. Γίνεται φανερός ο λόγος που επιλέχθηκε να χρησιμοποιηθεί το λεξιλόγιο schema.org για την περιγραφή των δεδομένων. 3.4 Τα γενικό πλαίσιο σε μια επικοινωνία Στο πλαίσιο της εργασίας θα υλοποιηθεί ένας αυτόματος πράκτορας, οποίος θα είναι σε θέση να χρησιμοποιήσει μια διαδικτυακή υπηρεσία. Στην Ενότητα περιγράφηκε η αποσύζευξη client server η οποία σήμερα είναι μια πρακτική που ακολουθείται. Προκύπτει λοιπόν το ερώτημα, του πως θα αποδοθεί αντίληψη στον πράκτορα, εφόσον αυτός λειτουργεί σε αποσύζευξη από τον πάροχο. Ποιο είναι το μαγικό συστατικό που μπορεί να τον κάνει να καταλάβει τη δομή της υπηρεσίας και να ζητήσει τις σωστές πληροφορίες; Σε αυτό το ερώτημα, μία απάντηση είναι ένας εξαιρετικά έξυπνος πράκτορας με μεγάλη βάση γνώσης (Knowledge Base) ώστε να είναι σε θέση να εξάγει τα σωστά συμπεράσματα πιθανόν και από την ανάγνωση του ίδιου κειμένου που θα διάβαζε ένας άνθρωπος. Αυτή η υλοποίηση όμως φαίνεται πολύ προχωρημένη για να συμπεριληφθεί σε μια διαδικτυακή εφαρμογή. Η προσέγγιση που ακολουθείται είναι πιο απλή και βασίζεται στην απλή παραδοχή ότι μέσα από ένα κοινώς κατανοητό λεξιλόγιο όρων και σχέσεων η διαδικασία της κατανόησης απλοποιείται. Η χρήση ενός κοινού πλαισίου στην επικοινωνία πράκτορα και server είναι απαραίτητη. Όπως απαραίτητη είναι και σε μία συζήτηση μεταξύ ανθρώπων. Ξεκινώντας από την ίδια τη γλώσσα, αν ο ένας συνομιλητής δε γνωρίζει τη γλώσσα στην οποία μιλά ο άλλος δεν υπάρχει συνεννόηση. Αντίστοιχα αν το πλαίσιο με βάση στο οποίο κουβεντιάζουν είναι διαφορετικό τότε οι παρερμηνεύσεις είναι κοινό φαινόμενο. Θα μπορούσε να χαρακτηρίστεί σαν γλώσσα το πρωτόκολλο HTTP και σαν συμφραζόμενα το λεξιλόγιο (στα πλαίσια του RDF) με βάση το οποίο περιγράφονται οι υπηρεσίες και τα δεδομένα. Σε αυτή την κατεύθυνση λοιπόν έρχεται να συνδράμει το λεξιλόγιο HYDRA, το οποίο δίνει ακριβώς αυτή την απαραίτητη περιγραφή για τις προσφερόμενες υπηρεσίες ενός server ή καλύτερα, περιγράφει τι μπορεί κανείς να αναμένει από ένα URL. Το λεξιλόγιο του HYDRA όμως είναι λιτό, και δίνει μόνο τις βασικές οδηγίες. Στα πλαίσια του REST όπου η υπηρεσία είναι δομημένη με βάση τα δεδομένα/πόρους (resources) είναι απαραίτητο να περιγραφούν σαφώς και οι πόροι οι οποίοι αναζητώνται/προσφέρονται. Για την περιγραφή των πόρων υπάρχουν πολλές επιλογές. Σύμφωνα με το διαδικτυακό ευρετήριο λεξιλογίων LOV [34], υπάρχουν περισσότερα από 600 λεξιλόγια με εννοιολογικές οντότητες. Κάποια από αυτά είναι πολύ εξειδικευμένα ενώ άλλα σαφώς αφηρημένα. Πηγαίνοντας ένα βήμα παραπέρα, η παρούσα υλοποίηση δεν αρκέστηκε στην απόδοση όρων από το λεξιλόγιο στα δεδομένα. Στόχος είναι η σχεδίαση του μοντέλου των 43

44 δεδομένων με βάση το συγκεκριμένο λεξιλόγιο. Εξετάστηκαν δηλαδή τα δεδομένα που θα προσφέρει η υπηρεσία αλλά και αυτά που θα επεξεργάζεται ο client με βάση τις κλάσεις και τις ιδιότητες που εμφανίζονται μέσα στο λεξιλόγιο. Η συγκεκριμένη μεθοδολογία μπορεί να γενικευτεί και να χρησιμοποιηθεί σε κάποιο άλλο λεξιλόγιο ή ακόμη και να καταλήξει στη δημιουργία ενός νέου που πληροί τον σκοπό. Με αυτό τον τρόπο τα δεδομένα σχεδιάζονται εξ αρχής σαν οντότητες, έχουν σαφή δομή και προσθέτουν πληροφορία στο Web καλύτερα αξιοποιήσιμη. 3.5 Τεχνητή νοημοσύνη Έχει περιγραφεί σε αδρές γραμμές ο τρόπος με τον οποίο οι τεχνολογικές λύσεις που θα χρησιμοποιηθούν διαπλέκονται στοχεύοντας στη λύση του τελικού προβλήματος που είναι ένας γενικευμένος πράκτορας έτοιμος να επικοινωνήσει με όσες υπηρεσίες μιλάνε την ίδια γλώσσα με αυτόν. Ο πράκτορας είναι αυτόνομος, αλλά δεν είναι έξυπνος. Μπορεί να καταλάβει σαφής όρους που έχουν μια καθορισμένη σημασία και να ακολουθήσει τις μεταξύ τους σχέσεις, αλλά δεν μπορεί να εξάγει συμπεράσματα καθώς η πληροφορία που γνωρίζει περιέχεται σε ένα μικρό (συγκριτικά) γράφο. Η αρχική διατύπωση του σημασιολογικού ιστού αφορούσε απλά την ανάλυση των δεδομένων και όχι την κατανόηση σε υψηλότερο επίπεδο. Ο πράκτορας καταφέρνει να διασχίσει μια μεγάλη απόσταση που υπάρχει σήμερα χάρης στις συμβάσεις που πραγματοποιήθηκαν. Η λύση είναι απλή, και δεν θα πρέπει να ανησυχεί το γεγονός ότι υπολείπεται σε Τεχνητή Νοημοσύνη. 3.6 Η αποφυγή της σημασιολογίας Κατά τη υλοποίηση της προτεινόμενης λύσης, λήφθηκε υπόψιν η αντιμετώπιση άλλου ενός προβλήματος το οποίο έχει χαρακτηριστεί ως semaphobia [35]. Μπορεί ο όρος να είναι παλιός αλλά παραμένει ένα γεγονός. Η αποστροφή των προγραμματιστών απέναντι στην έννοια του σημασιολογικού ιστού είναι ένα φαινόμενο που παρατηρείται ακόμη. Σχετικά με το λεξιλόγιο schema.org που εξετάζεται, η αξία του αποτιμάται μονάχα ως προς τη διαδικασία του SEO και όχι στην πραγματική του χρηστικότητα [36]. Έτσι η χρήση του λεξιλογίου φαίνεται να ενδιαφέρει ανθρώπους εξειδικευμένους στην παραπάνω διαδικασία παρά τους ίδιους τους προγραμματιστές. Με όλα αυτά κατά νου, η επιλογή του JSON-LD σαν τη μορφή αναπαράστασης των δεδομένων και η χρήση του schema.org για την περιγραφή των δεδομένων είναι επιλογές ώστε να διευκολυνθεί κανείς να εξετάσει την προτεινόμενη λύση και να την επεκτείνει. 44

45 4 Υλοποίηση 4.1 Εισαγωγή Η ανάδειξη της λειτουργικότητας και χρηστικότητας του πράκτορα απαιτούσε τη δημιουργία ενός ολόκληρου οικοσυστήματος από παρόχους APIs τα οποία υλοποιούνται με τη χρήση των λεξιλογίων HYDRA και schema.org. Παράλληλα ήταν απαραίτητος ένας κεντρικός server ο οποίος θα διαχειριζόταν τη διαδικασία της αυτόματης εξεύρεσης του κατάλληλου API. Ο client που διαχειρίζεται τις τεχνολογίες που περιγράφηκαν στο Κεφάλαιο 2 είναι το τελευταίο κομμάτι του παζλ. Η υλοποίηση βασίζεται σε εργαλεία τα οποία αποτελούν αιχμή της τεχνολογίας, καθώς οι τεχνολογίες που πραγματεύονται είναι πρόσφατες και δεν έχουν ενσωματωθεί στην παραγωγή πλήρως. Στην προσπάθεια αυτή σημαντικό κομμάτι αποτέλεσε μία υλοποίηση βασισμένη στο γνωστό framework της PHP, το Symfony [37], με τη βοήθεια του οποίου υλοποιήθηκαν οι πάροχοι των APIs, είτε από το μηδέν είτε σαν wrappers πάνω από υπάρχοντα APIs. Για την υλοποίηση του πελάτη-client δεν βρέθηκε κάποια υλοποίηση ενός HYDRA client ο οποίος δεχόταν επέκταση οπότε υλοποιήθηκε από την αρχή. 4.2 Διαδικτυακές υπηρεσίες με τη χρήση του HYDRA Ο πρότυπος πάροχος που προσφέρει ένα ή παραπάνω APIs, οφείλει να πληροί τα ακόλουθα κριτήρια ώστε να είναι σε θέση να αξιοποιηθεί από την πλευρά του πελάτη/client: Πλήρης συμμόρφωση με το πρότυπο σχεδίασης RESTful. Αναπαράσταση των υπηρεσιών του με τη χρήση του HYDRA λεξιλογίου. Αναπαράσταση των δεδομένων που διαχειρίζεται με ένα σαφώς ορισμένο λεξιλόγιο, όπως το schema.org. Ζητούμενο είναι η πρόσβαση σε πραγματικά δεδομένα προερχόμενα από γνωστές υπηρεσίες. Επομένως κάθε πάροχος που υλοποιείται για το σενάριο αυτό είναι και ένας ενδιάμεσος συζευκτικός κόμβος (wrapper) ο οποίος επικοινωνεί με τα APIs της εκάστοτε υπηρεσίας, συλλέγει τα ζητούμενα δεδομένα και τα προσαρμόζει στην κατάλληλη δομή. Έτσι τα δεδομένα βρίσκονται σε μορφή κατανοητή από τον πράκτορα. Παράλληλα κάθε απάντηση του παρόχου περιγράφεται με τη βοήθεια του HYDRA. Η δημιουργία μιας σειράς από παρόχους που προσφέρουν τις διάφορες υπηρεσίες σχετικές με το παρόν σενάριο βασίστηκε στο εξαιρετικό πλαίσιο ανάπτυξης (framework) 45

46 API-platform [38], το οποίο μετράει μόλις ένα χρόνο υλοποίησης, βρίσκεται στην έκδοση 2 και η ανάπτυξή του είναι πολύ ενεργή Αυτοματοποίηση δημιουργίας κλάσεων Αρχικά δημιουργήθηκε το μοντέλο δεδομένων που θα παρέχει ο πάροχος. Το μοντέλο αυτό πρέπει να είναι εκφρασμένο σε αντιστοιχία με το εκάστοτε λεξιλόγιο που έχει επιλεγεί προς χρήση. Ακόμη και αν η εσωτερική αναπαράστασή των δεδομένων διαφέρει, η απαιτούμενη περιγραφή οφείλει να δημιουργηθεί με όρους του λεξιλογίου ώστε να αποκτήσουν την αντίστοιχη σημασιολογία. Μια σημαντική λειτουργικότητα που προσφέρει το API-platform είναι η αυτόματη παραγωγή της αναπαράστασης του μοντέλου δεδομένων. Λαμβάνει μια σειρά από κλάσεις και ιδιότητες που εμφανίζονται στο schema.org και δημιουργεί την αντίστοιχη PHP κλάση που περιγράφει το μοντέλο. Παράγεται λοιπόν αυτόματα το μοντέλο δεδομένων εκφρασμένο στη γλώσσα προγραμματισμού που χρησιμοποιείται. Η προσοχή του προγραμματιστή πρέπει να εστιαστεί στους όρους του λεξιλογίου που θα χρησιμοποιήσει για να περιγράψει καλύτερα τα δεδομένα, ώστε αυτά να έχουν τη σωστή σημασιολογία και να είναι σε συμμόρφωση με τη γενική χρήση τους. Για την αποτελεσματική αξιοποίηση του συγκεκριμένου εργαλείου απαιτείται καλή κατανόηση του λεξιλογίου προς χρήση. Τα δεδομένα προς διαχείριση εξετάζονται διεξοδικά μέσα από αυτή τη διαδικασία πράγμα που οδηγεί σε μία καλύτερη κατανόηση του μοντέλου τους. Αυτό οδηγεί σε συνεκτικά μοντέλα δεδομένων. Η έλλειψη τριβής με το μοντέλο δεδομένων σε μία τυπική υλοποίηση οδηγεί σε σχεδιαστικά προβλήματα, καθώς δεν επενδύεται ο απαιτούμενος χρόνος στη σύλληψή του. Αυτό είναι και μια αιτία για τις λεγόμενες RESTlike και όχι RESTful υλοποιήσεις του προτύπου. Παρακάτω παρουσιάζεται ένα μοντέλο δεδομένων με τη χρήση όρων από το schema.org. 1 types: # The list of type to generated (a PHP entity class 2 by type will be generated) 3 4 PostalAddress: 5 parent: false 6 properties: 7 addresscountry: { range: Text } 8 addresslocality: ~ 9 addressregion: ~ 10 postalcode: ~ 11 streetaddress: ~ Airport: 14 parent: false 15 properties: 16 iatacode: 17 unique: true 18 address: { range: PostalAddress } 46

47 19 20 Flight: 21 parent: false 22 properties: 23 additionaltype: ~ 24 arrivalairport: { range: Airport } 25 departureairport: { range: Airport } 26 departuretime: ~ 27 arrivaltime: ~ 28 provider: { range: Text } Offer: 31 parent: false 32 properties: 33 pricecurrency: ~ 34 itemoffered: { range: Flight } 35 price: { range: Number } 36 seller: { range: Text } Απόσπασμα κώδικα 4: Παράδειγμα περιγραφής μοντέλου δεδομένων μιας υπηρεσίας αεροπορικών εισιτηρίων με όρους από το schema.org Η περιγραφή (Απόσπασμα κώδικα 4) είναι αρκετά κατατοπιστική από μόνη της. Παρουσιάζονται τέσσερις κλάσεις οι οποίες συνδέονται μεταξύ τους. Η κλάση PostalAddress (Απόσπασμα κώδικα 4, γρ. 4) περιγράφει μια ταχυδρομική διεύθυνση. Η κλάση αυτή χρησιμοποιείται από την επόμενη κατά σειρά κλάση Airport (Απόσπασμα κώδικα 4, γρ. 13) ώστε να συμπεριληφθεί σαν τιμή στο πεδίο address (Απόσπασμα κώδικα 4, γρ. 18) που δηλώνει τη διεύθυνση ενός αεροδρομίου. Αντίστοιχα, η κλάση που περιγράφει μια απλή πτήση Flight (Απόσπασμα κώδικα 4, γρ. 20) αξιοποιεί την κλάση Airport ώστε να αναφερθεί σε ένα αεροδρόμιο. Τέλος η Offer (Απόσπασμα κώδικα 4, γρ. 30) παρέχει τη σύνδεση μεταξύ μιας πτήσης και μιας οικονομικής προσφοράς μέσω του πεδιού itemoffered (Απόσπασμα κώδικα 4, γρ. 34). Με αυτόν τον αναλυτικό τρόπο κάθε πεδίο-τιμή έχει συγκεκριμένη έννοια όχι μόνο σε αυτήν την εσωτερική αναπαράσταση αλλά και για όποιον πελάτη αντιλαμβάνεται αυτούς τους όρους. Με την αξιοποίηση της παραπάνω περιγραφής δημιουργούνται αυτόματα οι απαιτούμενες κλάσεις για την PHP η οποία είναι και η γλώσσα προγραμματισμού που χρησιμοποιείται στον πάροχο Περιγραφή υπηρεσιών με όρους HYDRA Η περιγραφή των δυνατοτήτων του server μέσω HYDRA πραγματοποιείται με τη μορφή σχολίων τα οποία διαχειρίζεται ένας συντακτικός αναλυτής (parser). Η βασική δομή είναι οι κλάσεις του παρόχου και οι ενέργειες που αυτές υποστηρίζουν. Επομένως τα σχόλια αυτά περιέχονται στον ορισμό κάθε κλάσης. Μέρος αυτής της περιγραφής δημιουργείται αυτόματα μαζί με τη δημιουργία των κλάσεων από το μοντέλο δεδομένων, 47

48 όπως περιγράφηκε στην προηγούμενη ενότητα. Για μια απλή περιγραφή αυτό μας ικανοποιεί. Καθώς δεν υπάρχει κάποια επίσημη υλοποίηση ενός HYDRA enabled server, πραγματοποιήθηκαν κάποιες μετατροπές στον κώδικα που υλοποιούσε η πλατφόρμα, προσπαθώντας παράλληλα να παραμείνει εντός των πλαισίων που ορίζει το πρότυπο στην παρούσα χρονική στιγμή. Παρακάτω περιγράφεται με όρους HYDRA μια ενέργεια της κλάσης και έπειτα το ίδιο παράδειγμα θα εξεταστεί αργότερα εντός του κεντρικού γράφου που περιγράφει τον πάροχο. 1 /** 2 * An offer to transfer some rights to an item or to provide 3 a service? for example, an offer to sell tickets to 4 an event, to rent the DVD of a movie, to stream a TV show 5 over the internet, to repair a motorcycle, or to loan a 6 book 7 * 8 Documentation on Schema.org 9 * * iri=" 12 * attributes={"filters"={"offer.search"}, 13 * collectionoperations={ 14 * "get"={"method"="get", 15 *?hydra_context"={ 16 * "@type"="schema:searchaction", 17 * "target"="/offers", 18 * "query"={"@type"="vocab:#flight"}, 19 * "result"="vocab:#offer", 20 * "object"="vocab:#offer" 21 * }}, 22 * "post"={"method"="post"} 23 * } 24 * ) 25 */ Απόσπασμα κώδικα 5: Παράδειγμα HYDRA περιγραφής εντός κλάσης Εδώ (Απόσπασμα κώδικα 5) έχουμε την κλάση Offers, η οποία περιγράφει τις προσφορές από αεροπορικά εισιτήρια. Το κομμάτι που ενδιαφέρει ξεκινά με το (Απόσπασμα κώδικα 5, γρ.10). Το πεδίο type ορίζει τον τύπο της κλάσης σε σύγκριση με το λεξιλόγιο που έχει επιλεγεί. Η αναφορά στις περιγραφές των τοπικών δεδομένων γίνεται με το αναγνωριστικό vocab, το οποίο μετέπειτα αντιστοιχίζεται στο URL του παρόχου. Με αυτό τον τρόπο αποδίδεται το απαιτούμενο σημασιολογικό περιεχόμενο. Το πεδίο attributes (Απόσπασμα κώδικα 5, γρ.12) είναι εσωτερικός όρος του συντακτικού αναλυτή και δηλώνει μια σειρά χαρακτηριστικών της κλάσης. Στο παρόν παράδειγμα ορίζεται η δυνατότητα αναζήτησης επί της κλάσης. Η περιγραφή αυτή επεκτείνεται από τους όρους που ακολουθούν. 48

49 Αναλυτικά, ορίζεται ότι για τις συλλογές αντικειμένων της συγκεκριμένης κλάσης, η μέθοδος GET υλοποιεί την ενέργεια κατά το schema.org SearchAction (Απόσπασμα κώδικα 5, γρ.13-16), η οποία είναι διαθέσιμη στο IRI /offers. Το ερώτημα οφείλει να περιέχει σαν δεδομένα μία άλλη κλάση τη Flight (Απόσπασμα κώδικα 5, γρ.18), ενώ σαν αναμενόμενα αποτελέσματα αναμένονται αντικείμενα της κλάσης Offer (Απόσπασμα κώδικα 5, γρ.19). Ο όρος object αναφέρεται στο αντικείμενο όπου εκτελείται η ενέργεια. Η περιγραφή αυτή εμφανίζεται τόσο στον κεντρικό γράφο που περιγράφει το σύνολο του παρόχου, όσο και στην απάντηση από το IRI /offers. Με αυτό τον τρόπο ολοκληρώνεται η περιγραφή και συνάμα η συγγραφή τόσο της κλάσης όσο και των επιτρεπόμενων ενεργειών σε αυτή Πρότυπο RESTful Ο server υλοποιεί όλες τις προϋποθέσεις της αρχιτεκτονικής REST. Ιδιαίτερη έμφαση δίνεται στη HATEOAS. Τα λεγόμενα hypermedia controls που παρέχει ο πάροχος στον πελάτη παρέχονται μέσω της περιγραφής HYDRA. Κάθε απάντηση του παρόχου περιγράφεται με όρους HYDRA οι οποίοι ενημερώνουν για τις δυνατότητες του υπάρχοντος κόμβου (URI) καθώς και για πιθανόν επόμενα ή προηγούμενα βήματα. Αναφέρθηκε στο παραπάνω παράδειγμα ότι η περιγραφή της αναζήτησης περιέχεται και στο URI, που την υλοποιεί. Με αυτό τον τρόπο, αν ένας πελάτης περιηγηθεί σε αυτό το σημείο θα είναι σε θέση να αναγνωρίσει αυτή την παρεχόμενη ενέργεια και να προχωρήσει περαιτέρω. Επιλέχθηκε να συμπεριληφθούν αυτές οι πληροφορίες στον κεντρικό γράφο, ώστε να πραγματοποιείται αναγνώριση εκ των προτέρων και να αποφευχθούν επιπλέον ερωτήματα. 4.3 API Resolver Η εξέταση της αυτόματης εξεύρεση APIs απαίτησε έναν κεντρικό κόμβο τον οποίο θα μπορούσαν να συμβουλευτούν οι πελάτες. Μία υπηρεσία σαν αυτή που παρέχει η Google για ερωτήματα κειμένου. Στην προκειμένη όμως τα ερωτήματα είναι σε μορφή γράφου και χρησιμοποιούν όρους από γνωστά και διαθέσιμα λεξιλόγια. Ο API Resolver (Διάγραμμα 10) καλύπτει ακριβώς αυτή την ανάγκη. Δέχεται μια περιγραφή του ζητούμενου API, σαν γράφο εκφρασμένο σε JSON-LD. Επεξεργάζεται τα δεδομένα και πραγματοποιεί τις απαραίτητες αντιστοιχίες. Τέλος επιστρέφει έναν άλλο γράφο στον πελάτη με τα APIs που κατάφερε να επιλύσει. 49

50 Διάγραμμα 10: Αναπαράσταση συνολικού συστήματος. Δεξιά βρίσκονται οι πελάτες, αριστερά οι εξυπηρετητές και στο κέντρο ο API-Resolver που τους συνδέει σημασιολογικά Αναλυτής Γράφου Η επικοινωνία με τους παρόχους και καταναλωτές APIs αρχικοποιείται μέσα από έναν απλό πάροχο ο οποίος έχει τη δυνατότητα να επεξεργάζεται RDF γράφους και να πραγματοποιεί SPARQL ερωτήματα στον backend server (Apache Jena/Fuseki) [39] στον οποίο είναι αποθηκευμένοι οι γράφοι. Η χρήση ενός ενδιάμεσου κόμβου (API- Resolver) ο οποίος μεσολαβεί μεταξύ του SPARQL endpoint και του πελάτη κρίνεται σημαντική στην επίτευξη σταθερότητας και διαθεσιμότητας μιας τέτοιας υπηρεσίας. Μπορεί να εφαρμοστεί μια σειρά από περιορισμούς στα ερωτήματα τα οποία δέχεται ο API-Resolver, να ομαδοποιηθούν τα δεδομένα, να διαχειριστεί καλύτερα τον φόρτο εργασίας καθώς και να αξιοποιήσει τεχνικές προσωρινής αποθήκευσης (caching). Το σενάριο που επιτελεί ο API-Resolver ξεκινά με ένα αίτημα του client σε μορφή JSON- LD που περιγράφει μια σειρά από ζητούμενες κλάσεις και τις ενέργειες επί αυτών. Για κάθε μία κλάση που περιγράφεται, ο API-Resolver κατασκευάζει ένα SPARQL ερώτημα με τους απαραίτητους περιορισμούς και παραμέτρους. Κάθε ερώτημα αποστέλλεται στο Jena/Fuseki SPARQL backend. Στη συνέχεια ο API-Resolver λαμβάνει σαν απάντηση γράφους με την περιγραφή των APIs που πληρούν τα ζητούμενα κριτήρια και δημιουργεί έναν συνολικό γράφο - απάντηση που επιστρέφει στον client. Στη συνέχεια θα παρουσιαστεί ένα παράδειγμα με ολόκληρη την αλυσίδα ερωταπαντήσεων. 50

51 1 "offer": { 2 "@type": "schema:offer", 3 "pricecurrency": '', 4 "price": '', 5 "seller": '', 6 "itemoffered": { "@type": "schema:flight" }, 7 "potentialaction": { 8 "@type": "schema:searchaction", 9 "query": {"@type": "schema:flight"}, 10 "object": "schema:offer", 11 "result": "schema:offer", 12 "target": "schema:offer" 13 } 14 } Απόσπασμα κώδικα 6: Περιγραφή ζητούμενης κλάσης (client request) Ο πελάτης αναζητεί μια κλάση (Απόσπασμα κώδικα 6) η οποία είναι τύπου Offer από το schema.org. Επίσης χρειάζεται τις ιδιότητες pricecurrency, price, seller, itemoffered, potentialaction. Για τις ιδιότητες που δεν έχουν κάποιο συγκεκριμένο τύπο δεδομένων, είτε είναι αδιάφορο, είτε υπάρχει μόνο ένας επιτρεπτός τύπος δεδομένων (default). Η ιδιότητα itemoffered (Απόσπασμα κώδικα 6, γρ. 6) χρειάζεται συγκεκριμένα ένα αντικείμενο τύπου Flight. Με αυτό τον τρόπο δηλώνεται ότι αναζητούνται προσφορές για πτήσεις. Η ιδιότητα potentialaction (Απόσπασμα κώδικα 6, γρ. 7) έχει ιδιαίτερη βαρύτητα καθώς περιγράφει τις ζητούμενες ενέργειες επί των δεδομένων. Εδώ ο client απαιτεί τη δυνατότητα αναζήτησης σε αντικείμενα τύπου Offer (Απόσπασμα κώδικα 6, γρ. 10), στέλνοντας ερωτήματα τύπου Flight (Απόσπασμα κώδικα 6, γρ. 9) και αναμένοντας απαντήσεις τύπου Offer (Απόσπασμα κώδικα 6, γρ. 11). Υπάρχει μια σαφής περιγραφή των απαιτούμενων δεδομένων, η οποία γίνεται ακόμη πιο ξεκάθαρη από τη χρήση του HYDRA. 1 PREFIX schema: < 2 PREFIX rdf: < 3 PREFIX rdfs: < 4 PREFIX hydra: < 5 6 DESCRIBE?class?target 7 WHERE { 8?class rdf:type < 9?class hydra:supportedproperty?prop1. 10?prop1 hydra:property?prop1_iri. 11?prop1_IRI rdf:type schema:itemoffered. 12?prop1_IRI rdfs:range schema:flight. 13?action2_IRI schema:object?class. 14?action2_IRI schema:query?query. 15?query rdf:type?queryclass. 16?queryClass rdf:type schema:flight. 17?action2_IRI schema:result?result. 18?result rdf:type < 19?action2_IRI schema:target?target. 20?class hydra:supportedproperty?prop3. 21?prop3 hydra:property?prop3_iri. 22?prop3_IRI rdf:type schema:price. 51

52 23?class hydra:supportedproperty?prop4. 24?prop4 hydra:property?prop4_iri. 25?prop4_IRI rdf:type schema:pricecurrency. 26?class hydra:supportedproperty?prop5. 27?prop5 hydra:property?prop5_iri. 28?prop5_IRI rdf:type schema:seller. 29 } Απόσπασμα κώδικα 7: SPARQL ερώτημα προς εξεύρεση ζητούμενης κλάσης Ο API-Resolver, δέχεται την κλήση του πελάτη, την επεξεργάζεται και συντάσσει το ερώτημα σε SPARQL για τη ζητούμενη κλάση (Απόσπασμα κώδικα 7). Όλες οι παράμετροι που έδωσε ο πελάτης είναι παρούσες ώστε να περιοριστούν τα επιστρεφόμενα δεδομένα. Στην παρούσα διάταξη όσες κλάσεις πληρούν τα κριτήρια επιστρέφονται. Με αυτόν τον απλό τρόπο μπορεί να αξιοποιηθεί ένα σύνολο από APIs δίχως επιπλέον κόπο. Ακολουθεί η απάντηση που αποστέλλει ο Jena/Fuseki που διαχειρίζεται τους γράφους. 1 "@id": "vocab:#offer", 2 "@type": [ "hydra:class", " ], 3 "rdfs:label": "Offer", 4 "hydra:title": "Offer", 5 "hydra:supportedproperty": [ { 6 "@type": "hydra:supportedproperty", 7 "hydra:property": { 8 "@id": "vocab:#offer/pricecurrency", 9 "@type": [ "rdf:property", " 10 org/pricecurrency" ], 11 "rdfs:label": "pricecurrency", 12 "domain": " 13 "range": "xmls:string" }, 14 "hydra:title": "pricecurrency", 15 "hydra:required": true, 16 "hydra:readable": true, 17 "hydra:writable": true, 18 "hydra:description": "The currency" }], 19 { 20 "@type": "hydra:supportedproperty", 21 "hydra:property": { 22 "@id": "vocab:#offer/itemoffered", 23 "@type": [ "rdf:property", " 24 org/itemoffered" ], 25 "rdfs:label": "itemoffered", 26 "domain": " 27 "range": " }, 28 "hydra:title": "itemoffered", 29 "hydra:required": false, 30 "hydra:readable": true, 31 "hydra:writable": true, 32 "hydra:description": "The item being offered" }], 33 "hydra:supportedoperation": [ { 34 "@type": [ "hydra:operation", "schema:action" ], 35 "hydra:method": "GET", 36 "hydra:title": "Retrieves Offer resource.", 37 "rdfs:label": "Retrieves Offer resource.", 38 "returns": " }, Απόσπασμα κώδικα 8: Η περιγραφή της ζητούμενης κλάσης ως γράφος σε JSON-LD 52

53 Στο παραπάνω απόσπασμα (Απόσπασμα κώδικα 8) περιγράφεται μόνο η ζητούμενη κλάση και όχι η απαραίτητη ενέργεια. Εδώ έχουμε πλήρη αντιστοιχία με το ζητούμενο μοντέλο. Αν μια κλάση περιέχει και επιπλέον ιδιότητες τότε θα πληρούσε τα κριτήρια και θα επιστρεφόταν επίσης Apache Jena/Fuseki Το framework Jena/Fuseki [39] αποτελεί ένα αξιόπιστο εργαλείο στη διαχείριση εφαρμογών σημασιολογικού ιστού. Υλοποιεί το SPARQL endpoint στο οποίο απευθύνεται ο API-Resolver. Παρέχει μια σειρά από λειτουργίες ώστε να αξιοποιηθεί η προτασιακή λογική του RDF. Τέτοιες είναι η αποθήκευση RDF δεδομένων, η εξαγωγή συμπερασμάτων από αυτά, ερωτήματα σε ελεύθερο κείμενο καθώς και το συντακτικό ARQ το οποία είναι μια γενίκευση της SPARQL. Το Fuseki εκφράζει αυτή τη λειτουργικότητα στο πρωτόκολλο HTTP, ώστε να χρησιμοποιήσουμε το Jena μέσω αντίστοιχων κλήσεων. Ο γράφος που περιγράφει έναν πάροχο API αποθηκεύεται στο σετ δεδομένων (dataset) του Jena ώστε να πραγματοποιηθεί η αναζήτηση και η επιλογή των υπηρεσιών - APIs. Στο απλό σενάριο δεν εφαρμόζεται κάποια άλλη ενέργεια επάνω στους γράφους πέραν της αναζήτησης μέσω SPARQL. Η χρήση όμως του Jena εξασφαλίζει αξιοπιστία και επεκτασιμότητα της λειτουργικότητας μελλοντικά Διεπαφή API-Resolver Ο API-Resolver προσφέρει το δικό του API και την αντίστοιχη τεκμηρίωση με βάση το Swagger ώστε να διευκολυνθεί η πρόσβαση στους προγραμματιστές. Αξιοποιεί και αυτός τις ίδιες τεχνολογίες με σκοπό την προβολή των πληροφοριών των APIs που έχει διαθέσιμα. Προσφέρει τη δυνατότητα αναζήτησης για API με βάση το επιθυμητό λεξιλόγιο και κλάση. Έτσι ο προγραμματιστής μπορεί να αποκτήσει μια συνεκτική εικόνα για τις προσφερόμενες υπηρεσίες που παρέχονται κάθε στιγμή. 53

54 Εικόνα 3: Τυπική περιγραφή API, API-Resolver 4.4 Γενικευμένος πελάτης Schydra Client Η αλυσίδα του συστήματος που παρουσιάζεται ολοκληρώνεται με μια σειρά από βοηθητικές συναρτήσεις για τον επίδοξο πελάτη. Ο πελάτης, ο οποίος είναι σε θέση να αξιοποιήσει τις δυνατότητες των HYDRA server που παρουσιάστηκαν στην Ενότητα 4.2, πρέπει με τη σειρά του να πληροί κατ' αντιστοιχία τα ίδια κριτήρια όπως αυτά περιγράφηκαν. Παράλληλα πρέπει να διαθέτει τα κατάλληλα εργαλεία για να επικοινωνεί και με τον API Resolver, ώστε να πραγματοποιεί την απαιτούμενη αναζήτηση για APIs. Μοναδικό προαπαιτούμενο είναι η διαχείριση RDF γράφων η οποία επιτυγχάνεται με τη χρήση της βιβλιοθήκης rdflib.js [40]. Οι υπόλοιπες συναρτήσεις αντλούν από εκεί τα απαραίτητα δεδομένα. Όλη η επεξεργασία των δεδομένων που λαμβάνονται από τον API- Resolver γίνεται με τη χρήση γράφων. Η δομή της προσλαμβανόμενης απάντησης δεν μας απασχολεί, αρκεί να υπάρχουν οι απαραίτητες προτάσεις με τα αναγνωριστικά του HYDRA και του schema.org. Δεν πραγματοποιείται δηλαδή συντακτική ανάλυση (parsing) με βάση κάποιο πρότυπο. Οφείλει όμως να περιγράφεται σωστά ο επιστρεφόμενος γράφος σε JSON-LD αναπαράσταση Συνοπτική παρουσίαση Οι βοηθητικές συναρτήσεις και κλάσεις που προσφέρονται στον προγραμματιστή είναι οι εξής: 54

55 init(rawjson, resolverserver, graph) Βασική συνάρτηση η οποία υλοποιεί ολόκληρη τη διαδικασία. Πραγματοποιεί την κλήση στον API-Resolver και επιστρέφει μια σειρά από συναρτήσεις και αντικείμενα για τη διαχείριση της πληροφορίας. Καλεί τις getliterals() και createprotos() για το σκοπό αυτό. getliterals(graph) Επιστρέφει από τον επιλεγμένο γράφο, graph, τις περιγραφές των κλάσεων και συλλογών κλάσεων. Βοηθητική συνάρτηση που προσφέρει την πληροφορία σε εσωτερική αναπαράσταση. createprotos(graph, keepall, rawjson) Δέχεται τον γράφο graph και την αρχική περιγραφή rawjson του προγραμματιστή και δημιουργεί μια σειρά από κλάσεις - αντικείμενα με βάση αυτές τις περιγραφές τα οποία έχουν τόσο το μοντέλο δεδομένων όσο και τις απαραίτητες ενέργειες. Εμπεριέχει τα ακόλουθα: classliterals{} Η περιγραφή των κλάσεων ανάλογα με τον πάροχο. collectionliterals{} Η περιγραφή των συλλογών κλάσεων ανάλογα με τον πάροχο. hyclass{}() Μία σειρά από Javascript Object Prototypes, ανάλογα με την επιλεγμένη κλάση και πάροχο. Ανάλογα τον πάροχο πιθανόν να υπάρχουν διαφοροποιήσεις στο μοντέλο. Κρίθηκε απαραίτητο να είναι διαθέσιμες στον προγραμματιστή. Έχουν τη δομή του μοντέλου δεδομένων όπως αυτό έρχεται από τον πάροχο, καθώς και τις αντίστοιχες ενέργειες προς αυτόν. Περιγράφει ένα στιγμιότυπο μίας κλάσης. hycollection{}() 55

56 Μία σειρά από JavaScript Object Prototypes, ανάλογα με την επιλεγμένη κλάση και πάροχο. Παρέχει το μοντέλο δεδομένων που περιγράφει μια συλλογή αντικειμένων από μια κλάση. Η συλλογή περιέχει ενέργειες προς τον πάροχο. Κάποιες ενέργειες πραγματοποιούνται μόνο στην αντίστοιχη συλλογή όπως η προσθήκη νέου στιγμιότυπου (instance) μιας κλάσης, και όχι στο ίδιο το στιγμιότυπο όπως αυτό περιγράφεται από τη hyclass{}. hybind{}() Μία σειρά από JavaScript Object Prototypes, ανάλογα με την επιλεγμένη κλάση. Δημιουργείται με βάση την περιγραφή που παρέχει ο προγραμματιστής όταν δημιουργεί το δικό του τοπικό μοντέλο δεδομένων με λεξιλογικούς όρους. Η δομή του δεν διανθίζεται με επιπλέον πληροφορία όταν ολοκληρωθεί η κλήση στον API-Resolver. Μονάχα πραγματοποιεί τις απαιτούμενες κλήσεις στις αντίστοιχες κλάσεις που είναι γνωστές στον γράφο. Εμπεριέχει επομένως τόσο τη hyclass{}() όσο και τη hycollection{}(). hyauto(type,url) Δέχεται σαν όρισμα τον τύπο της επιθυμητής κλάσης και το URL του παρόχου. Επιστρέφει το αντίστοιχο JavaScript Object Prototype. Αν δεν βρεθεί πάροχος, τότε επιστρέφει το γενικό hybind{}(). hyparse(members, referenceobj, url, thisobj) Δέχεται μια σειρά από αντικείμενα τύπου JSON, μια συνάρτηση αναφοράς referenceobj όπως η hyauto(), το URL του παρόχου και πιθανόν ένα αντικείμενο, thisobj, στο οποίο θα αποθηκεύσει τα δεδομένα. Εξάγει από τα αντικείμενα JSON την πληροφορία η οποία βρίσκεται σε περιγραφή HYDRA και την αποθηκεύει στο αναφερόμενο αντικείμενο ή την επιστρέφει προς ανάθεση. Είναι μια διαδικασία που πραγματοποιείται αυτόματα όταν εκτελούνται HTTP κλήσεις μέσω των αντίστοιχων πρότυπων αντικειμένων (hyclass{}(),hycollection{}(), hybind{}()). 56

57 1 var rawjson = { { 3 "@vocab" : " 4 }, 5 { 6 "airport": { 7 "@type": "Airport", 8 "iatacode": '', 9 "address": { "@type": "PostalAddress" }, 10 "geo": {"@type": "GeoCoordinates"}, 11 "potentialaction": { 12 "@type": "SearchAction", 13 "object": "schema:airport", 14 "result": "schema:airport", 15 "target": "schema:airport", 16 "query": {"@type": "schema:postaladdress"} 17 } 18 } 19 } 20 } Απόσπασμα κώδικα 9: Παράδειγμα αρχικοποίησης μοντέλου δεδομένων. Ορισμός μοντέλου Η χρήση των συναρτήσεων αυτών, ξεκινά με την αρχικοποίηση του τοπικού μοντέλου δεδομένων. Το μοντέλο μπορεί να χρησιμοποιηθεί για την εξεύρεση APIs αλλά και για τη δημιουργία μιας κλάσης αντικειμένου το οποίο διευκολύνει τη συγγραφή της εφαρμογής. Στο Απόσπασμα κώδικα 9 ορίζεται η κλάση Airport (Απόσπασμα κώδικα 9, γρ. 6). Ακολουθούν οι ιδιότητες που εμπεριέχει η κλάση, iatacode, address, geo. Η επιπλέον ιδιότητα potentialaction (Απόσπασμα κώδικα 9, γρ. 10) αφορά τη ζητούμενη ενέργεια που απαιτείται. Δημιουργία εσωτερικών κλάσεων - αντικειμένων Αν πραγματοποιηθεί επιτυχής κλήση στον API-Resolver τότε υπάρχουν διαθέσιμα πιο αναλυτικά μοντέλα μέσω των hyclass{}() και hycollection{}(). Σε διαφορετική περίπτωση αναλαμβάνει η hybind{}(). Η δομή παρουσιάζεται στο διάγραμμα (Διάγραμμα 11). Κάθε ιδιότητα που αναφέρεται σε κλάσεις, όπως οι address και geo απαιτεί να περιέχεται και το αντίστοιχο μοντέλο της αναφερόμενης κλάσης. Κατά τη δημιουργία των αντικειμένων, οι παραπάνω ιδιότητες εμπεριέχουν ολόκληρο το στιγμιότυπο της αναφερόμενης κλάσης και όχι μονάχα τις τιμές που αντιστοιχούν. Το μοτίβο αυτό συνεχίζεται για όλες τις εμφωλευμένες ιδιότητες. Οι συναρτήσεις ανάθεσης και ανάκτησης των τιμών στις ιδιότητες συντάσσονται αλυσιδωτά. Γνωρίζοντας ότι η κλάση geo περιέχει τα πεδία latitude και longitude, καλούμε τις τιμές αυτές ως airportobject.geo.latitude. Οι μέθοδοι HTTP καλούνται από τη συνάρτηση method(methodname). Οι αντίστοιχες ενέργειες, οι οποίες στην ουσία είναι και αυτές μέθοδοι HTTP, αλλά με σημασιολογική 57

58 περιγραφή καλούνται μέσω της συνάρτησης action (actionname). Οι κλήσεις σε έναν πάροχο πραγματοποιούνται αυτόματα. Στην εσωτερική αναπαράσταση είναι γνωστό το URL που θα πραγματοποιηθεί η κλήση, η μέθοδος καθώς και τυχόν δεδομένα. Συνολική διαδικασία Διάγραμμα 11: Διάγραμμα κλάσεων του Schydra Client Το διάγραμμα ροής (Διάγραμμα 12) περιγράφει συνοπτικά τη συνολική διαδικασία που ακολουθείται από την κλήση της συνάρτησης init(rawjson, resolverserver, graph). Δέχεται σαν είσοδο ένα JSON-LD αρχείο, το οποίο ορίζει τις υπηρεσίες που θα ήθελε να αξιοποιήσει ο πελάτης. Ορίζει δηλαδή το γενικό μοντέλο δεδομένων του και τις ενέργειες σε αυτό. Παράλληλα δέχεται και τον κεντρικό πάροχο στον οποίο μπορεί να πραγματοποιήσει αναζήτηση για APIs καθώς και έναν γράφο στον οποίο θα αποθηκεύσει τα επιστρεφόμενα δεδομένα. Πραγματοποιεί λοιπόν μια κλήση στον API-Resolver που έχει οριστεί αποστέλλοντας την περιγραφή του API. Η απάντηση του API-Resolver προστίθεται στον γράφο όπου πλέον διατίθεται η περιγραφή του API. Για τη διευκόλυνση της χρήσης του API, δημιουργείται μια σειρά από κλάσεις για κάθε ζητούμενη, τόσο από την αρχική περιγραφή ( hybind{}() ) όσο και από τις περιγραφές που λαμβάνονται ( hyclass{}(), hycollection{}() ). Ο προγραμματιστής δεν χρειάζεται να έχει άμεση πρόσβαση στον γράφο που περιγράφει το API αλλά χρησιμοποιεί τις ενδιάμεσες κλάσεις - αντικείμενα. Η δημιουργία κλάσεων ακόμη και στην περίπτωση αρνητικής απάντησης πραγματοποιείται με βάση το τοπικό μοντέλο που περιέγραψε ο προγραμματιστής. Με αυτό τον τρόπο διευκολύνεται στην διαχείριση τοπικών δεδομένων με αναφορά σε λεξιλογικούς όρους, ώστε να διευκολυνθεί η καθολική χρήση τους. 58

59 Διάγραμμα 12: Διάγραμμα ροής Schydra Client 59

60 5 Επίδειξη του συστήματος - Πράκτορας λογισμικού για ταξιδιωτικές υπηρεσίες 5.1 Εισαγωγή Στο κεφάλαιο αυτό χρησιμοποιώντας τα εργαλεία που υλοποιήθηκαν δημιουργείται ένα πλήρως λειτουργικό παράδειγμα. Το παράδειγμα που επιλέχθηκε αφορά τις ταξιδιωτικές υπηρεσίες όπως η εύρεση προσφορών για αεροπορικά εισιτήρια, πληροφορίες για την πόλη προορισμού καθώς και διαθέσιμα ξενοδοχεία. Ένα τέτοιο παράδειγμα είναι ένα καθημερινό σενάριο. Για να οργανώσει κανείς ένα ταξίδι χρειάζεται να χρησιμοποιήσει μια σειρά από υπηρεσίες. Για να είναι πιο αληθοφανές το σενάριο χρησιμοποιήθηκαν APIs από γνωστές υπηρεσίες τα οποία εκφράστηκαν με τα κατάλληλα λεξιλόγια ώστε να είναι αναγνωρίσιμα από τον πράκτορα λογισμικού. Οι υπηρεσίες που ενσωματώθηκαν είναι οι SkyScanner [41] και Sabre [42] για αναζήτηση πτήσεων, οι Sabre και Amadeus [43] για αναζήτηση ξενοδοχείων και η Amadeus για αναζήτηση σημείων ενδιαφέροντος. Στόχος είναι η ανάδειξη του επιπέδου αυτοματοποίησης που έχει επιτευχθεί, το επίπεδο δυσκολίας από πλευράς προγραμματιστή, καθώς και ο διαχωρισμός μεταξύ του μοντέλου δεδομένων και της υλοποίησής του σε κάποιο περιβάλλον προγραμματισμού. 5.2 Παρουσίαση Server, παρόχου υπηρεσίας Η ανάλυση ξεκινά από τον πάροχο που επιστρέφει τα σημεία ενδιαφέροντος μιας και έχει μικρή αλλά συνεκτική περιγραφή. Θα εξεταστούν εδώ μονάχα τα νέα χαρακτηριστικά που εισάγονται στη διαδικασία συγγραφής της υπηρεσίας Μοντέλο δεδομένων Τα παρεχόμενα δεδομένα περιγράφονται από δύο κλάσεις (Απόσπασμα κώδικα 10). Η βοηθητική κλάση GeoCoordinates (Απόσπασμα κώδικα 10, γρ. 4) περιγράφει ένα γεωγραφικό στίγμα, και η κλάση TouristAttraction (Απόσπασμα κώδικα 10, γρ. 10) περιέχει πληροφορίες σχετικά με κάποιο σημείο ενδιαφέροντος. Το αναγνωριστικό parent, ορίζει ότι δεν υπάρχουν οι αντίστοιχες υπερκλάσεις ορισμένες στο παρόν έγγραφο και θεωρούνται οι προκαθορισμένες από το schema.org. Προσοχή δίνεται στο πεδίο geo (Απόσπασμα κώδικα 10, γρ. 17) το οποίο δέχεται ως τιμή αντικείμενα από την κλάση GeoCoordinates. 60

61 1 types: # The list of type to generated (a PHP entity class 2 by type will be generated) 3 4 GeoCoordinates: 5 parent: false 6 properties: 7 latitude: ~ 8 longitude: ~ 9 10 TouristAttraction: 11 parent: false 12 properties: 13 name: ~ 14 description: ~ 15 url: ~ 16 hasmap: ~ 17 geo: { range: GeoCoordinates} 18 image: ~ Απόσπασμα κώδικα 10: Αναπαράσταση κλάσεων μέσω schema.org [schema.yml] Αυτόματα προκύπτουν οι κλάσεις όπως φαίνονται παρακάτω (Απόσπασμα κώδικα 11, 12). Έχουν παραλειφθεί οι συναρτήσεις τύπου get, set για κάθε ιδιότητα. Το αναγνωριστικό που ενδιαφέρει είναι (Απόσπασμα κώδικα 11/12, γρ. 7). Στα πεδίο type ορίζεται ο όρος που ανταποκρίνεται στην αντίστοιχη κλάση του λεξιλογίου. Το πεδίο iri αναφέρεται στο αναγνωριστικό της κλάσης όπως αυτό θα εμφανίζεται στο γράφο της απάντησής μας. Στην κλάση TouristAttraction (Απόσπασμα κώδικα 12, γρ. 14) περιγράφεται η διαδικασία της αναζήτησης με όρους τόσο από το HYDRA όσο και από το schema.org. Η λειτουργία της αναζήτησης περιγράφεται με τον όρο SearchAction. Τα υπόλοιπα πεδία αναλύθηκαν στην Ενότητα 4.2. Οι private μεταβλητές αποτελούν τα αντίστοιχα πεδία τιμών της κλάσης. Με τη συγγραφή ενός αρχείου καθώς και τις ρυθμίσεις που αφορούν τα πεδία της αναζήτησης, ο πάροχος είναι έτοιμος. Μία σειρά από συναρτήσεις αναλαμβάνουν να αξιοποιήσουν τις παραμέτρους που ορίστηκαν κατά τον ορισμό των κλάσεων και να παρουσιάσουν το αποτέλεσμα που ακολουθεί (Εικόνα 4). 1 /** 2 * The geographic coordinates of a place or event. 3 * 4 Documentation on Schema.org 5 * * iri=" 9 */ 10 class GeoCoordinates 11 { 12 /** 13 int 14 * 15 61

62 */ 19 private $id; /** 22 float The latitude of a location. For example ``` ``` 23 * 24 nullable=true) "writeattraction"}) 28 */ 29 private $latitude; /** 32 float The longitude of a location 33 nullable=true) "writeattraction"}) 37 */ 38 private $longitude; Απόσπασμα κώδικα 11: Υλοποίηση PHP κλάσης GeoCoordinates 1 /** 2 * A tourist attraction. 3 * 4 Documentation on Schema.org 5 * 6 7 type=" 8 * iri=" 9 * attributes={"filters"={"attraction.search"}, 10 "normalization_context"={"groups"={"readattraction"}}, 11 * "denormalization_context"={"groups"={"writeattraction"}} 12 * }, 13 * collectionoperations={ 14 * "get"={"method"="get", "hydra_context"={"@type"="schema:searchaction", 15 * "target"="/tourist_attractions", 16 * "query"={"@type"="vocab:#geocoordinates"}, 17 * "result"="vocab:#touristattraction", 18 * "object"="vocab:#touristattraction" 19 * }}, 20 * "post"={"method"="post"} 21 * } 22 * ) 23 */ 24 class TouristAttraction 25 { 26 /** 27 int 28 * 62

63 */ 33 private $id; /** 36 string The name of the item 37 * "writeattraction"}) 42 */ 43 private $name; /** 46 string A description of the item 47 * "writeattraction"}) 52 */ 53 private $description; /** 56 string URL of the item 57 * "writeattraction"}) 62 */ 63 private $url; /** 66 string A URL to a map of the place 67 * "writeattraction"}) 72 */ 73 private $hasmap; /** 76 GeoCoordinates The geo coordinates of the place 77 * "writeattraction"}) 81 */ 82 private $geo; /** 85 string An image of the item. This can be a \[\[URL\]\] or a fully described \[\[ImageObject\]\] 86 *

64 89 90 "writeattraction"}) 91 */ 92 private $image; Απόσπασμα κώδικα 12: Υλοποίηση PHP κλάσης TouristAttraction Οι παρεχόμενες υπηρεσίες του Server Οι απαντήσεις που λαμβάνονται από τον πάροχο που υλοποιήθηκε παρουσιάζονται παρακάτω. Για τον απλό χρήστη δεν προσφέρει κάποια διεπαφή (Web interface), μονάχα το REST API και την τεκμηρίωσή του. Έχει συμπεριληφθεί μια διεπαφή (Εικόνα 4) στα πρότυπα του OpenAPI [26] ώστε να διατηρείται η συμβατότητα με τα υπάρχοντα πρότυπα παραγωγής RESTful υπηρεσιών. Εικόνα 4: Παράδειγμα διεπαφής τεκμηρίωσης Server Στη συνέχεια παρουσιάζονται οι απαντήσεις που λαμβάνονται από τον πάροχο σε μορφή JSON-LD. Στο Απόσπασμα κώδικα 13 αποτυπώνεται ένα μέρος από τον κεντρικό γράφο. Περιέχει όλη την πληροφορία που χαρακτηρίζει τον πάροχο και είναι ο γράφος τον οποίο εξετάζει ο API-Resolver για να πραγματοποιήσει τις αντιστοιχίες. Σε ένα 64

65 διευρυμένο δίκτυο, αναμένεται ο πάροχος να στέλνει αυτόματα τον γράφο αυτό στον αντίστοιχο κόμβο, ώστε να δημοσιοποιεί τις υπηρεσίες του. Παρακάτω φαίνεται η απάντηση (Απόσπασμα κώδικα 14) σε μια αναζήτηση για δεδομένα τύπου TouristAttraction. O πάροχος δέχεται μια κλήση τύπου GET στο IRI /tourist_attractions και απαντά με μία συλλογή πόρων. Κάθε πεδίο περιέχει τα αντίστοιχα δεδομένα του. είναι το αναγνωριστικό του πόρου για κάθε μία οντότητα. Έτσι αν απαιτείται να πραγματοποιηθούν περαιτέρω ενέργειες γίνεται αναφορά σε αυτό το αναγνωριστικό. 1 { 2 "@context": {}, 3 "@id": "/docs.jsonld", 4 "hydra:title": "API Platform's demo", 5 "hydra:description": "This is a demo application", 6 "hydra:entrypoint": "/", 7 "hydra:supportedclass": [ 8 { 9 "@id": "vocab:#geocoordinates", 10 "@type": [ 11 "hydra:class", 12 " 13 ], 14 "jsonld_context": "test", 15 "rdfs:label": "GeoCoordinates", 16 "hydra:title": "GeoCoordinates", 17 "hydra:supportedproperty": [ 18 { 19 "@type": "hydra:supportedproperty", 20 "hydra:property": { 21 "@id": "vocab:#geocoordinates/latitude", 22 "@type": [ 23 "rdf:property", 24 " 25 ], 26 "rdfs:label": "latitude", 27 "domain": " 28 "range": "xmls:decimal" 29 }, 30 "hydra:title": "latitude", 31 "hydra:required": false, 32 "hydra:readable": true, 33 "hydra:writable": true, 34 "hydra:description": "The latitude of a location. 35 }, 36 { 37 "@type": "hydra:supportedproperty", 38 "hydra:property": { 39 "@id": "vocab:#geocoordinates/longitude", 40 "@type": [ 41 "rdf:property", 42 " 43 ], 44 "rdfs:label": "longitude", 45 "domain": " 46 "range": "xmls:decimal" 47 }, 48 "hydra:title": "longitude", 65

66 49 "hydra:required": false, 50 "hydra:readable": true, 51 "hydra:writable": true, 52 "hydra:description": "The longitude of a location. 53 } 54 ], 55 "hydra:supportedoperation": [ 56 { 57 "@type": [ 58 "hydra:operation", 59 "schema:action" 60 ], 61 "hydra:method": "GET", 62 "hydra:title": "Retrieves GeoCoordinates resource.", 63 "rdfs:label": "Retrieves GeoCoordinates resource.", 64 "returns": " 65 } 66 ] 67 }, Απόσπασμα κώδικα 13: Κεντρικός γράφος περιγραφής παρόχου 1 { 2 "@context": "/contexts/touristattraction", 3 "@id": "/tourist_attractions", 4 "@type": "hydra:collection", 5 "hydra:member": [ 6 { 7 "@id": "/tourist_attractions/1", 8 "@type": " 9 "name": "Piraeus", 10 "description": "Piraeus is a port city in the region of Attica, Greece.", 11 "url": " 12 "hasmap": " 13 "geo": { 14 "@id": "/geo_coordinates/0", 15 "@type": " 16 "latitude": 37.95, 17 "longitude": }, 19 "image": " Piraeus_Mikrolimano1.JPG" 20 }, 21 { 22 "@id": "/tourist_attractions/2", 23 "@type": " 24 "name": "Attica", 25 "description": "Attica is a historical region that encompasses the city of Athens, the capital of Greece.", 26 "url": " 27 "hasmap": " 28 "geo": { 29 "@id": "/geo_coordinates/1", 30 "@type": " 31 "latitude": , 32 "longitude":

67 33 }, 34 "image": " Attica_06-13_Sounion_16_Cape_Sounion.jpg" 35 }]} Απόσπασμα κώδικα 14: Απάντηση Server σε μορφή JSON-LD Σύγκριση με υπάρχουσα διαδικασία ανάπτυξης παρόχου Σε αυτό το σημείο κρίνεται απαραίτητη η αντιπαραβολή της παραπάνω διαδικασίας με την υπάρχουσα. Η τυπική διαδικασία που θα ακολουθούσε ένας προγραμματιστής θα ξεκινούσε με τη δημιουργία του μοντέλου δεδομένων απευθείας στη μορφή κλάσεων εντός της γλώσσας προγραμματισμού που είχε επιλεγεί. Οι προγραμματιστές θα συνέτασσαν χειροκίνητα τα Απόσπασμα κώδικα 11/12. Τα κέρδη από την αυτοματοποίηση της διαδικασίας είναι ποιοτικά και όχι μόνο ποσοτικά όπως εύκολα φαίνεται. Η χρήση ενός κεντρικού αρχείου για την περιγραφή του μοντέλου μειώνει την πιθανότητα λαθών κατά την συγγραφή καθώς όλες οι κλάσεις και οι ιδιότητές τους παρουσιάζονται μαζί. Τυχόν αλλαγές είναι εύκολα ανιχνεύσιμες, σε αντίθεση με την αναζήτηση σε κάθε κλάση ξεχωριστά. Η χρήση λεξιλογικών όρων για την περιγραφή του μοντέλου απαιτεί από τον προγραμματιστή τη γνώση των αντίστοιχων λεξιλογίων. Αυτή η απαίτηση ίσως ξενίσει κάποιους προγραμματιστές αλλά τα οφέλη που αποκομίζει είναι άμεσα. Η χρήση λεξιλογίων για την περιγραφή των δεδομένων αποδίδει σαφή χαρακτηριστικά σε αυτά και εκφράζει καλύτερα την επιχειρησιακή λογική που υλοποιείται. Τα λεξιλόγια έχουν δημιουργηθεί με ιεραρχική δομή και ενέχουν και στοιχεία λογικής επαγωγής. Για τυπικές χρήσεις, η δομή του λεξιλογίου υπερκαλύπτει τις ανάγκες του μοντέλου δεδομένων. Με άλλα λόγια, στην προσπάθεια σύνθεσης του μοντέλου, ο προγραμματιστής θα συναντήσει τους όρους που χρειάζεται για να περιγράψει τα δεδομένα του και θα τον οδηγήσουν σε ένα ορθότερο μοντέλο. Ο ενδιαφερόμενος καλείται να αφιερώσει παραπάνω χρόνο στη σχεδίαση παρά στην υλοποίηση του μοντέλου δεδομένων, πράγμα το οποίο συνεπάγεται ποιοτική αναβάθμιση. Παράλληλα, τα δεδομένα είναι έτοιμα προς χρήση από μηχανές αναζήτησης και άλλες υπηρεσίες ιχνηλάτησης του διαδικτύου. Ο χρόνος που θα απαιτούνταν για να πραγματοποιηθεί η συσχέτιση ανάμεσα στα δεδομένα που προσφέρονται από την υπηρεσία με όρους του schema.org έχει εξαλειφθεί, αφού τα δεδομένα είναι ήδη σε αυτή τη μορφή. Κάθε σωστός επαγγελματίας που αναγνωρίζει την αναγκαιότητα του SEO πραγματοποιεί αυτές τις συσχετίσεις. Με τη διαδικασία που προτείνεται καταργείται ο επιπλέον χρόνος ενώ παρέχεται ορθότερη πληροφορία. 67

68 Η έκφραση της συνολικής περιγραφής των παρεχόμενων υπηρεσιών με τη βοήθεια του HYDRA δίνει τη δυνατότητα όχι μόνο του διαμοιρασμού (με τη μορφή γράφου) αλλά και της αυτοματοποίησης της τεκμηρίωσης των υπηρεσιών. Αυτό είναι μια λειτουργία που πραγματοποιείται αυτόματα, με τη βοήθεια των περιγραφών κάθε κλάσης (Απόσπασμα κώδικα 12) χρησιμοποιώντας το Μέχρι πρότινος αυτό ήταν εφικτό μέσω του Swagger, το οποίο καθιερώθηκε ως πρότυπο από τους προγραμματιστές του διαδικτύου. Η διαδικασία είναι η ίδια χρησιμοποιώντας σχόλια στον κώδικα τα οποία αξιοποιεί ένας συντακτικός αναλυτής για να δημιουργήσει τις αντίστοιχες περιγραφές. Η χρήση του HYDRA επεκτείνει αυτό το πρότυπο στον σημασιολογικό ιστό. Περιγράφει τα δεδομένα ακόμη πιο αναλυτικά, αφού μια κλάση αναφέρεται σε μια οντότητα λεξιλογίου. Οι μέθοδοι HTTP επεκτείνονται με την έννοια των ενεργειών. Αυτό συνεπάγεται και πιθανή χρήση άλλων πρωτοκόλλων πέραν του HTTP. Μια ενέργεια ενέχει σημασιολογική ερμηνεία και βρίσκεται ιεραρχικά πάνω από τις μεθόδους HTTP. Το HYDRA καλύπτει την απαίτηση σε τεκμηρίωση της υπηρεσίας όσον αφορά τη χρήση της από τον επίδοξο προγραμματιστή. Παρέχει όμως και τεκμηρίωση σε πράκτορες λογισμικού, επιτρέποντας την αυτόματη ιχνηλάτηση κάθε πόρου της υπηρεσίας. Σε όποιο τυχαίο URL της υπηρεσίας βρεθεί ένας πελάτης, είναι σε θέση να γνωρίζει τις επιλογές που είναι διαθέσιμες και τι αυτές σημαίνουν. Με παρόμοιο τρόπο που ένας άνθρωπος από μία σειρά υπερσυνδέσμων επιλέγει τον κατάλληλο με βάση το κείμενο που τον περιγράφει, έτσι και το HYDRA παρέχει την αντίστοιχη πληροφορία, κατανοητή για σημασιολογικούς πράκτορες λογισμικού. Συνοψίζοντας, εισάγεται η χρήση του λεξιλογίου schema.org για την περιγραφή του μοντέλου δεδομένων. Σαν αποτέλεσμα λαμβάνεται αυτόματα η εσωτερική αναπαράσταση τους με άμεση αναφορά στους επιλεγμένους λεξιλογικούς όρους. Η εισαγωγή του HYDRA αντικαθιστά τη χρήση τεχνολογιών όπως το Swagger και περιγράφει σημασιολογικά πλέον την παρεχόμενη υπηρεσία. Ανεξάρτητα από τη γλώσσα προγραμματισμού που χρησιμοποιείται για την υλοποίηση, ένας συμβατός πάροχος επιστρέφει απαντήσεις στο συντακτικό του JSON-LD περιγράφοντας τα δεδομένα του με λεξιλογικούς όρους και τις υπηρεσίες του με όρους HYDRA. Τελικός στόχος είναι η αυτοματοποίηση της επικοινωνίας μεταξύ παρόχου και πελάτη. 5.3 Παρουσίαση Πελάτη - Client Μοντέλο δεδομένων Η συγγραφή του πελάτη που καλείται να χρησιμοποιήσει όλες τις παρεχόμενες υπηρεσίες όπως το παράδειγμα που παρουσιάστηκε στην προηγούμενη ενότητα ξεκινά 68

69 από την ανάλυση του μοντέλου δεδομένων. Ο πελάτης αναζητά προσφορές αεροπορικών εισιτηρίων, πιθανά ξενοδοχεία και σημεία ενδιαφέροντος στον τελικό προορισμό. Η προέλευση και ο προορισμός του χρήστη καθώς και οι ημερομηνίες αναχώρησης και πιθανής επιστροφής αποτελούν τα βασικά δεδομένα. Ως αποτελέσματα επιστρέφονται το κόστος της αεροπορικής πτήσης, τα ξενοδοχεία που βρίσκονται στη γύρω περιοχή ώστε να διευκολυνθεί ως προς την πιθανή διαμονή του, και μια σειρά από σημεία ενδιαφέροντος που θα μπορούσε να επισκεφθεί. Όλη αυτή την πληροφορία οφείλει να εκφραστεί με λεξιλογικούς όρους. Στο Απόσπασμα κώδικα 15 παρουσιάζεται η αντίστοιχη περιγραφή, με γνώμονα τα δεδομένα στα οποία αποκτήθηκε πρόσβαση χρησιμοποιώντας APIs από εταιρίες που δραστηριοποιούνται στον τομέα αυτό. 1 "@vocab" : " 2 "schema" : " 3 "hydra" : " 4 "xmls" : " 5 "owl" : " 6 "rdf" : " 7 "xsd" : " 8 "rdfs" : " 9 }, 10 "offer": { 11 "@type": "Offer", 12 "pricecurrency": '', 13 "price": '', 14 "seller": '', 15 "itemoffered": { "@type": "Flight" }, 16 "potentialaction": { 17 "@type": "SearchAction", 18 "query": {"@type": "schema:flight"}, 19 "object": "schema:offer", 20 "result": "schema:offer", 21 "target": "schema:offer" 22 } 23 }, 24 "flight": { 25 "@type": "Flight", 26 "arrivalairport": {"@type": "Airport"}, 27 "departureairport": {"@type": "Airport"}, 28 "departuretime": {"@type": "xmls:datetime"}, 29 "arrivaltime": {"@type": "xmls:datetime"}, 30 "provider": "" 31 }, 32 "postaladress": { 33 "@type": "PostalAddress", 34 "addresscountry": '', 35 "addresslocality": '' 36 }, 37 "airport": { 38 "@type": "Airport", 39 "iatacode": '', 40 "address": { "@type": "PostalAddress" }, 41 "geo": {"@type": "GeoCoordinates"}, 69

70 42 "potentialaction": { 43 "@type": "SearchAction", 44 "object": "schema:airport", 45 "result": "schema:airport", 46 "target": "schema:airport", 47 "query": {"@type": "schema:postaladdress"} 48 } 49 }, 50 "poi": { 51 "@type": "TouristAttraction", 52 "name": "", 53 "description": "", 54 "url": "", 55 "hasmap": "", 56 "geo": {"@type": "GeoCoordinates"}, 57 "image": "", 58 "potentialaction": { 59 "@type": "SearchAction", 60 "object": "schema:touristattraction", 61 "result": "schema:touristattraction", 62 "target": "schema:touristattraction", 63 "query": {"@type": "schema:geocoordinates"} 64 } 65 }, 66 "geoloc": { 67 "@type": "GeoCoordinates", 68 "latitude": "", 69 "longitude": "" 70 }, 71 "hotels": { 72 "@type": "Hotel", 73 "name": "", 74 "description": "", 75 "address": {"@type":"schema:postaladdress"}, 76 "faxnumber": "", 77 "telephone": "", 78 "geo": {"@type": "schema:geocoordinates"}, 79 "potentialaction": { 80 "@type": "SearchAction", 81 "object": "schema:hotel", 82 "result": "schema:hotel", 83 "target": "schema:hotel", 84 "query": {"@type": "schema:geocoordinates"} 85 } 86 } 87 }; Απόσπασμα κώδικα 15: Περιγραφή μοντέλου δεδομένων client Οι κλάσεις που χρησιμοποιούνται είναι οι εξής: Offer (Απόσπασμα κώδικα 14, γρ. 10): Η οποία περιγράφει μία προσφορά σχετικά με κάποιο προιόν. Flight (Απόσπασμα κώδικα 14, γρ. 24): Μία πτήση με τις λεπτομέρειές της. Επίσης η πτήση εδώ θεωρείται και σαν υπηρεσία για την οποία διατίθεται και η αντίστοιχη οικονομική προσφορά. 70

71 PostalAddress (Απόσπασμα κώδικα 14, γρ. 32): Η κλάση αυτή ανήκει στην κατηγορία των δομημένων δεδομένων και περιγράφει μια ταχυδρομική διεύθυνση. Αποτελείται από πολλαπλά πεδία, τα οποία χρησιμοποιούνται συνήθως όλα μαζί σε συνδυασμό. Airport (Απόσπασμα κώδικα 14, γρ. 37): Το αεροδρόμιο χαρακτηρίζεται από τον γνωστό ΙΑΤΑ κωδικό ενώ σαν υποκλάση η οποία περιγράφει μια τοποθεσία, διαθέτει επίσης διεύθυνση και γεωγραφικές συντεταγμένες. TouristAttraction (Απόσπασμα κώδικα 14, γρ. 50): Περιγράφει μια τοποθεσία η οποία έχει κάποιο τουριστικό ενδιαφέρον. GeoCoordinates (Απόσπασμα κώδικα 14, γρ. 66): Άλλη μια κλάση η οποία περιγράφει δομημένα το γεωγραφικό στίγμα. Hotels (Απόσπασμα κώδικα 14, γρ. 71): Η κλάση που περιγράφει τα ξενοδοχεία, ανήκει ταυτόχρονα σε δύο υπερκλάσεις και περιέχει έτσι ιδιότητες και από τις δύο. Από τη μία αποτελεί μια τοποθεσία με την ευρεία έννοια ενώ από την άλλη αποτελεί και μια επιχείρηση. Έχουν οριστεί τα δεδομένα και απαιτείται ένα σύνολο ενεργειών σε αυτά ώστε να υλοποιηθούν οι αντίστοιχες λειτουργικότητες. Για να γίνει ευκολότερα κατανοητή η περιγραφή των ενεργειών παρατίθενται οι παρακάτω ερωτήσεις: Τι χρειάζεται να γνωρίζει ο client ώστε να βρει την τιμή μιας αεροπορικής πτήσης; Μία πτήση χαρακτηρίζεται στην απλούστερη περίπτωση από αεροδρόμια αναχώρησης και προορισμού. Επίσης για την αγορά ενός εισιτηρίου είναι απαραίτητες και οι ημερομηνίες καθώς οι τιμές αλλάζουν συνεχώς. Πως θα βρει τον κωδικό ΙΑΤΑ ενός αεροδρομίου; Ένα αεροδρόμιο συνήθως αναφέρεται στην πόλη την οποία εξυπηρετεί. Επομένως οφείλει να αναζητήσει αεροδρόμια με βάση μια πόλη. Θα μπορούσε να αναζητήσει αεροδρόμια και με βάση την απόσταση από ένα γεωγραφικό σημείο. Με βάση ποιο κριτήριο θα πραγματοποιηθεί η αναζήτηση σημείων ενδιαφέροντος; Τα σημεία ενδιαφέροντος εμπεριέχουν την έννοια της τοποθεσίας. Επομένως η αναζήτηση θα μπορούσε να πραγματοποιηθεί με βάση την πόλη προορισμού. Επιλέχθηκε εδώ η αναζήτηση με βάση τις γεωγραφικές συντεταγμένες. 71

72 Απαντώντας αυτά τα ερωτήματα προκύπτει με φυσικό τρόπο και η αντίστοιχη περιγραφή της αναζήτησης που στα πλαίσια του schema.org ονομάζεται SearchAction. Χρειάζεται λοιπόν η δυνατότητα αναζήτησης μιας οικονομικής προσφοράς, για την αναφερόμενη πτήση. Όπου η πτήση περιγράφεται από τις ημερομηνίες αναχώρησης και πιθανής επιστροφής, καθώς και από τα αεροδρόμια αναχώρησης και προορισμού. Με την ίδια λογική εκφράζονται και τα υπόλοιπα. Τα πεδίο της αναζήτησης περιγράφονται στο Απόσπασμα κώδικα 15 στις γραμμές 17, 43, 58, Εξεύρεση API Το επόμενο βήμα είναι η επικοινωνία με έναν server ο οποίος μπορεί να αντιληφθεί τη φύση του ερωτήματος και να απαντήσει με αντίστοιχα μέσα. Χρησιμοποιείται ο API- Resolver, όπως αυτός έχει αναλυθεί στο Κεφάλαιο 4.2. Πραγματοποιείται λοιπόν η αναζήτηση, με το παρακάτω απόσπασμα κώδικα (Απόσπασμα κώδικα 16). 1 var resolverserver = ' 2 var graph = $rdf.graph(); 3 var schydra = schydraangular.init(rawjson,resolverserver,graph); 4 schydra.then(function(hydraclass){ 5 6 }) Απόσπασμα κώδικα 16: Αρχικοποίηση κλάσεων και εξεύρεση υπηρεσιών Ορίζεται η διεύθυνση του API-Resolver, ο τοπικός γράφος που θα χρησιμοποιηθεί και καλείται η συνάρτηση init() με πρώτο όρισμα την περιγραφή του ζητούμενου API σε μορφή JSON-LD (Απόσπασμα κώδικα 15). Αυτό είναι αρκετό για να επιστρέψει τα αντίστοιχα APIs. Η περιγραφή λοιπόν του μοντέλου δεδομένων αναδεικνύεται στην πλέον σημαντική διαδικασία. Δε χρειάζεται να αναλωθεί κανείς σε μηχανές αναζήτησης χρησιμοποιώντας μια ασαφή περιγραφή για τα δεδομένα. Ο έλεγχος και η μορφοποίηση των επιστρεφόμενων δεδομένων από το εκάστοτε API έχει ελαχιστοποιηθεί αν όχι εξαλειφθεί. Αφού πραγματοποιηθεί η αντιστοιχία από πλευράς API-Resolver και επιστρέψει την ανάλογη απάντηση, αυτό που λαμβάνεται σαν αποτέλεσμα για να χρησιμοποιηθούν τα APIs είναι μια σειρά από αντικείμενα JavaScript. Κάθε αντικείμενο υλοποιεί και μια κλάση Χρήση του API Τα αντικείμενα που είναι διαθέσιμα για τον χειρισμό των APIs είναι εξοπλισμένα με βοηθητικές συναρτήσεις οι οποίες δίνουν πρόσβαση στις ιδιότητες-πεδία της κλάσης και στις ενέργειες που επιτρέπεται να πραγματοποιηθούν. Επίσης παρέχονται και κάποια 72

73 βοηθητικά πεδία τα οποία μπορούν να χρησιμοποιηθούν στη διεπαφή χρήστη για την απόδοση μιας περιγραφής του κάθε πεδίου. 1 var destinationgeo = hyauto('geocoordinates'); 2 destinationgeo.label = "Destination Location"; 3 destinationgeo.latitudelabel = 'Latitude'; 4 destinationgeo.longitudelabel = 'Longitude'; Απόσπασμα κώδικα 17: Απόδοση τιμών στις εσωτερικές κλάσεις (I) Ορίζεται εδώ μια μεταβλητή destinationgeo η οποία είναι μια κλάση τύπου GeoCoordinates. Τα πεδία που έχει είναι μονάχα δύο, latitude, longitude. Αποδίδονται τιμές στο πεδίο label, το οποίο θα εμφανιστεί στη διεπαφή σαν τίτλος της μεταβλητής. 1 //Search Address 2 var searchaddress = hyauto('postaladdress'); 3 searchaddress.label = 'Departure address'; 4 searchaddress.addresscountry = 'GR'; 5 searchaddress.addresscountrylabel = 'Country Code'; 6 searchaddress.addresslocality = 'Chios'; 7 searchaddress.addresslocalitylabel = 'City'; 8 9 //search Airport 10 var searchairport = hyauto('airport'); 11 searchairport.label = 'Search Airport'; 12 searchairport.iatacode = ''; 13 searchairport.iatacodelabel = 'IATA code'; 14 searchairport.address = searchaddress; 15 searchairport.geo = location; Απόσπασμα κώδικα 18: Απόδοση τιμών στις εσωτερικές κλάσεις (II) Στο Απόσπασμα κώδικα 18 ορίζονται τα αντικείμενο με βάση τα οποία θα πραγματοποιηθεί η αναζήτηση ενός αεροδρομίου. Αρχικά δημιουργείται η προς αναζήτηση διεύθυνση searchaddress η οποία αρχικοποιείται με τις τιμές addresslocality = Chios, addresscountry = GR (Απόσπασμα κώδικα 18, γρ. 4,6). Έπειτα η κλάση αυτή ανατίθεται, στην αντίστοιχη κλάση searchairport (Απόσπασμα κώδικα 18, γρ. 14) η οποία είναι και αυτή για την οποία απαιτήθηκε να διαθέτει την ενέργεια schemasearch. Ακολουθεί ο κώδικας που πραγματοποιεί την αναζήτηση ενός αεροδρομίου με βάση μια πόλη. 1 $scope.localsearch = function(str) { 2 var matches = []; 3 var results = $q.defer(); 4 searchaddress.addresslocality = str; 5 searchairport.address = searchaddress; 6 searchairport.action('schemasearch').then(function(response){ 7 response.parsedobjects.foreach(function(obj,i){ 8 matches.push(obj); 9 }); 10 results.resolve(matches); 73

74 11 }); 12 return results.promise; 13 }; Απόσπασμα κώδικα 19: Υλοποίηση αναζήτησης Η συνάρτηση localsearch(str) (Απόσπασμα κώδικα 19) καλείται από τον χρήστη αφότου εκείνος έχει δώσει μια πόλη στη μεταβλητή str. Ορίζονται οι βοηθητικές μεταβλητές matches, results όπου η μία περιέχει τα αεροδρόμια που ανακτήθηκαν και η δεύτερη αποτελεί μια μεταβλητή προς επίλυση. Στο πεδίο addresslocality του αντικειμένου searchaddress αποδίδεται (Απόσπασμα κώδικα 19, γρ. 4) η τιμή που έδωσε ο χρήστης. Έχουμε αποδώσει το αντικείμενο searchaddress στο πεδίο address του searchairport (Απόσπασμα κώδικα 19, γρ. 5). Το μόνο που απομένει, είναι η κλήση-αναζήτηση στο αντίστοιχο API. Η συνάρτηση searchairport.action('schemasearch') (Απόσπασμα κώδικα 19, γρ. 6) υλοποιεί την αναζήτηση που παρέχει το API. Από τις πιθανές ενέργειες που διαθέτει το αντικείμενο searchairport καλείται η schemasearch. Η schemasearch χρησιμοποιεί τα δεδομένα που περιέχει το πεδίο address μιας και αυτό πληροί τον τύπο της κλάσης που απαιτείται από το query όπως αυτό ορίστηκε (Απόσπασμα κώδικα 15). Με αυτό τον τρόπο πραγματοποιείται η αναζήτηση στα δεδομένα. Όπως εύκολα αντιλαμβάνεται κανείς ο πραγματικός server στον οποίο πραγματοποιούνται τα ερωτήματα δεν φαίνεται πουθενά. Έχει αφαιρεθεί η απαίτηση για την εκ των προτέρων γνώση του παρόχου μιας υπηρεσίας. Δεν γίνεται αντιληπτό αν η αναζήτηση πραγματοποιείται σε έναν ή σε παραπάνω παρόχους. Ο προγραμματιστής διαθέτει το μοντέλο δεδομένων και πραγματοποιεί τις ενέργειες που διαθέτει σαν να ήταν τα δεδομένα διαθέσιμα τοπικά. Για την ολοκλήρωση της ανάλυσης του παραδείγματος, παρατίθενται μερικά ακόμη απόσπασμα κώδικα. 1 $scope.assigndepartureairport = function(data) { 2 if(data.hasownproperty('originalobject')) { 3 $scope.departureairport = data.originalobject; 4 $scope.searchflight.departureairport = $scope.departureairport; 5 } 6 }; 8 $scope.assignarrivalairport = function(data) { 9 if(data.hasownproperty('originalobject')) { 10 $scope.arrivalairport = data.originalobject; 11 $scope.searchflight.arrivalairport = $scope.arrivalairport; 12 pois.geo = $scope.arrivalairport.geo; 13 hotels.geo = $scope.arrivalairport.geo; 14 } 15 }; Απόσπασμα κώδικα 20: Ανάθεση επιστρεφόμενων δεδομένων 74

75 Παραπάνω (Απόσπασμα κώδικα 20), ανατίθενται τα δεδομένα που αφορούν τα δύο ζητούμενα αεροδρόμια και τις γεωγραφικές συντεταγμένες που αφορούν το σημείο προορισμού. Όλα τα απαραίτητα δεδομένα είναι διαθέσιμα για να πραγματοποιηθούν οι τρεις αναζητήσεις και να παρουσιαστούν τα δεδομένα στο χρήστη. 1 $scope.fetchoffers = function() { 2 togglebackdrop(); 3 $scope.offer.action('schemasearch').then(function(response){ 4 $scope.retrievedoffers = $scope.offer.members ; 5 $scope.offerslength = $scope.retrievedoffers.length; 6 }); 7 pois.action('schemasearch').then(function(response){ 8 $scope.retrievedpois = pois.members; 9 $scope.poislength = $scope.retrievedpois.length; 10 }); 11 hotels.action('schemasearch').then(function(response){ 12 $scope.retrievedhotels = hotels.members; 13 $scope.hotelslength = $scope.retrievedhotels.length; 14 }); 15 }; Απόσπασμα κώδικα 21: Τελική συνάρτηση υλοποίησης απαιτούμενης λειτουργικότητας Στο Απόσπασμα κώδικα 21 φαίνεται η συνάρτηση η οποία επιστρέφει τα αποτελέσματα και για τις τρεις κατηγορίες δεδομένων προς αναζήτηση Σύγκριση με υπάρχουσα διαδικασία ανάπτυξης πελάτη Στο παράδειγμα που προηγήθηκε χρησιμοποιήθηκαν τρεις διαφορετικές κατηγορίες υπηρεσιών με στόχο να παρουσιαστεί στον τελικό χρήστη μια διεπαφή που τις συνδυάζει λειτουργικά. Πρώτη ενέργεια λοιπόν είναι η εξεύρεση των υπηρεσιών που θα παρέχουν τα δεδομένα. Η τυπική διαδικασία είναι η αναζήτηση υπηρεσιών μέσω ερωτημάτων κειμένου σε μία μηχανή αναζήτησης ή η χρήση μιας υπηρεσίας που παρέχει αναλυτικές λίστες με υπηρεσίες όπως είναι για παράδειγμα το programmableweb ( ή το rapidapi ( Ο προγραμματιστής περιηγείται λοιπόν στο διαδίκτυο αναζητώντας πιθανές υπηρεσίες. Η εύρεση των υπηρεσιών δεν συνεπάγεται άμεσα και την επιλογή τους. Καθώς στη συνέχεια ο προγραμματιστής οφείλει να εξετάσει τα δεδομένα που αυτές παρέχουν και σε τι βαθμό πρέπει να τα επεξεργαστεί ώστε να δουλέψουν απρόσκοπτα μεταξύ τους. Συνέχεια έχει η υλοποίηση της επικοινωνίας με καθεμία υπηρεσία. Σήμερα πολλές υπηρεσίες παρέχουν έτοιμες βιβλιοθήκες κώδικα οι οποίες συμπεριλαμβάνονται στον πελάτη με στόχο τη μείωση του χρόνο υλοποίησης. Σε διαφορετική περίπτωση, καλείται κανείς να διαβάσει το έγγραφο τεκμηρίωσης και να συντάξει τις απαραίτητες κλήσεις HTTP μαζί με το σύνολο των βοηθητικών συναρτήσεων. 75

76 Η προτεινόμενη λύση απαλλάσσει τον προγραμματιστή από όλη την παραπάνω διαδικασία. Σε αντίθεση με ότι ακολουθείται μέχρι σήμερα, η διαδικασία ξεκινά με την περιγραφή του μοντέλου δεδομένων που θα χρησιμοποιηθεί. Ο προγραμματιστής καλείται να συντάξει μια συνοπτική περιγραφή των κλάσεων που χρειάζεται, των ιδιοτήτων που αυτές οφείλουν να περιέχουν καθώς και των διαθέσιμων ενεργειών που θα υποστηρίζουν. Περιγράφει, δηλαδή, αναλυτικά τις απαιτήσεις του, τις οποίες μπορεί να θέσει σαν ερώτημα σε κάποια μηχανή αναζήτησης. Η περιγραφή αυτή (Απόσπασμα κώδικα 15) έχει διττό σκοπό. Ο πρώτος είναι η εξεύρεση των κατάλληλων υπηρεσιών που πληρούν τα κριτήρια και ο δεύτερος η δημιουργία βοηθητικών εσωτερικών αναπαραστάσεων ώστε να διευκολυνθεί κατά τη χρήση τους. Η εξεύρεση των υπηρεσιών πραγματοποιείται με την κλήση σε έναν γνωστό κεντρικό κόμβο. Ένας τέτοιος κόμβος είναι ο API-Resolver, ο οποίος έχει ρόλο μηχανής αναζήτησης. Δέχεται και προσφέρει όμως ερωταπαντήσεις με σημασιολογικά δεδομένα. Η απάντηση που λαμβάνει ο πελάτης είναι η περιγραφή των υπηρεσιών που ζήτησε έτοιμη προς χρήση. Το μόνο που έχει να κάνει ο προγραμματιστής είναι να καλέσει τις αντίστοιχες μεθόδους όπως αυτές περιγράφονται από τη βοηθητική βιβλιοθήκη που υλοποιήθηκε (schydraclient.js) η οποία αξιοποιεί τη σημασιολογική πληροφορία και τη μεταφράζει σε εσωτερικές αναπαραστάσεις. Δεν χρειάζεται να αναλωθεί διαβάζοντας κείμενα τεκμηρίωσης για κάθε υπηρεσία ξεχωριστά. Η περιγραφή που έδωσε, του εξασφαλίζει και τις συντομεύσεις που θα χρησιμοποιήσει κατά τη σύνταξη του κώδικα. Επίσης, χρησιμοποιεί μία βιβλιοθήκη για να επικοινωνήσει με όλες τις υπηρεσίες, αντίθετα με ότι περιγράφηκε παραπάνω. Ένα άλλο σημαντικό στοιχείο είναι η αυτόματη κλήση πλέον του ενός παρόχων. Υπάρχει η δυνατότητα κλήσης όλων των παρόχων που πληρούν τα κριτήρια δίχως να χρειάζονται ξεχωριστές κλήσεις για τον κάθε έναν. Γίνεται χρήση αυτής της λειτουργίας, όταν πραγματοποιείται μία αναζήτηση για πτήσεις, και λαμβάνονται αποτελέσματά από δύο παρόχους. Το ερώτημα που προκύπτει είναι πως ο προγραμματιστής θα γνωρίζει τους όρους με τους οποίους πρέπει να συντάξει την περιγραφή των δεδομένων. Σε αυτό ακριβώς το σημείο εμπλέκεται ο σημασιολογικός ιστός. Ο πάροχος έχει εκφράσει τη δική του περιγραφή χρησιμοποιώντας λεξιλογικούς όρους όπως το schema.org οι οποίοι είναι σαφής και καθολικοί. Έτσι, ο συντάκτης του πελάτη client επιλέγει από τα λεξιλόγια εκείνους τους όρους που περιγράφουν καλύτερα το ζητούμενο. Η αποδοχή και χρήση ενός κοινού πλαισίου επικοινωνίας μεταξύ παρόχου - πελάτη εξασφαλίζει αυτοματισμούς σε επίπεδο παραγωγής κώδικα που δεν μπορούν να αμεληθούν. Παράλληλα, η χρήση δομημένων δεδομένων σε κάθε έκφανση πληροφορίας 76

77 στο διαδίκτυο επιτρέπει την περαιτέρω αυτοματοποίηση λειτουργιών που σήμερα απαιτούν ανθρώπινη επίβλεψη. 5.4 Τελικό αποτέλεσμα Αποτελέσματα και παρατηρήσεις Το τελικό αποτέλεσμα είναι μια διεπαφή για τον τελικό χρήστη (Εικόνα 5), όπου παρουσιάζονται τα αποτελέσματα των αναζητήσεών του. Το ενδιαφέρον εδώ εστιάζεται στην προσπάθεια που απαιτήθηκε για να συγγραφεί η διασύνδεση με τα εξωτερικά APIs που χρησιμοποιεί ο πελάτης. Ο χρόνος που απαιτείται για να ενταχθεί μια επιπλέον υπηρεσία στην εφαρμογή έχει μειωθεί αισθητά. Στην παρούσα υλοποίηση, πραγματοποιείται αυτόματα κλήση σε δύο διαφορετικούς παρόχους αεροπορικών εισιτηρίων και ξενοδοχειακών υπηρεσιών. Αν υπήρχε και τρίτη υπηρεσία η οποία πληρούσε τα κριτήρια, θα αντλούνταν και από εκεί αποτελέσματα. Παράλληλα και ο ίδιος ο κώδικας που χρειάζεται να συγγραφεί, έχει μειωθεί σε όγκο. Το μεγαλύτερο μέρος του κώδικα αφορούσε την αναλυτική δημιουργία των τοπικών αντικειμένων ώστε να αποδοθούν τα απαραίτητα δεδομένα για να πραγματοποιηθούν οι κλήσεις HTTP και ετικέτες οι οποίες εμφανίζονται στη διεπαφή. Η λειτουργικότητα της εφαρμογής χρειάστηκε μερικές μονάχα κλήσεις συναρτήσεων. Εξαιρουμένων των διαδικασιών που αφορούν τη διεπαφή, πραγματοποιήθηκαν πέντε κλήσεις για ανάκτηση δεδομένων οι οποίες μεταφράζονται σε επτά κλήσεις HTTP. Το μεγαλύτερο μέρος του χρόνου δαπανήθηκε στη σύνταξη του μοντέλου δεδομένων με βάση το schema.org. Η εξοικείωση όμως με αυτό είναι μια χρήσιμη ικανότητα καθώς επεκτείνεται ο σημασιολογικός ιστός. 77

78 Εικόνα 5: User Interface Στο παρόν σενάριο, το σετ δεδομένων στον οποίο θέτονται ερωτήματα SPARQL ώστε να προκύψουν οι αντιστοιχίες είναι μικρό, της τάξεως των 5000 προτάσεων. Σε αυτή την κλίμακα μεγέθους δε προκύπτουν σαφή συμπεράσματα για τη δυνατότητα του API- Resolver να πραγματοποιήσει σε ικανοποιητικό χρόνο τη ζητούμενη επίλυση. Αξίζει παρόλα αυτά να παρουσιαστούν κάποια στοιχεία από την όλη διαδικασία. Με τη βοήθεια των εργαλείων ανάπτυξης που προσφέρει ο φυλλομετρητής Google Chrome, μετρήθηκαν οι χρόνοι απόκρισης της σελίδας τριάντα φορές. Η ιστοσελίδα χρειάστηκε κατά μέσο όρο 2,43 δευτερόλεπτα για να είναι πλήρως έτοιμη με τυπική απόκλιση 27,2ms. Ο χρόνος αυτός είναι μέσα στα επιτρεπτά πλαίσια. Ενδιαφέρον παρουσιάζει το γεγονός ότι χρειάστηκαν κατά μέσο όρο 720ms (τυπική απόκλιση 35,7ms) από τη στιγμή που πραγματοποιείται η κλήση στον API-Resolver μέχρι να αποστείλει πίσω τα ζητούμενα δεδομένα. Αυτό μεταφράζεται στην ανάλυση του αιτήματος, επικοινωνία με τον Jena/Fuseki server, και επιστροφή της ζητούμενης περιγραφής του API. Ο χρόνος αυτός μπορεί να φαίνεται αρκετός για τον μικρό αριθμό δεδομένων και κίνησης, αλλά πρέπει να αναλογιστεί κανείς ότι δεν αποθηκεύεται 78

79 προσωρινά, στην παρούσα φάση, η απάντηση του API-Resolver. Επομένως εκτελέστηκε ολόκληρη η διαδικασία της αναζήτησης και επίλυσης ενός API. Η διαδικασία όμως βρίσκεται κάτω από το όριο του ενός δευτερολέπτου. Στο Διάγραμμα 13 φαίνεται ένα στιγμιότυπο από τις αποκρίσεις του API-Resolver. Στο συγκεκριμένο στιγμιότυπο χρειάστηκε 286ms (μέσος όρος 247ms, τυπική διακύμανση 39,4ms) για να πραγματοποιήσει τις απαιτούμενες ενέργειες. Διάγραμμα 13: API-Resolver performance metrics Η χρήση caching από πλευράς API-Resolver, αλλά και από πλευράς πελάτη θα μειώσει αυτούς τους χρόνους αισθητά. Ο πελάτης θα πρέπει να επικοινωνεί με τον API-Resolver σε περίπτωση μονάχα αποτυχίας. Κάτι το οποίο θα υποδήλωνε συνήθως μη διαθεσιμότητα της συγκεκριμένης υπηρεσίας ή αλλαγής παραμέτρων για τις οποίες θα έπρεπε να ενημερωθεί αυτόματα ο client. Τα αποτελέσματα που λαμβάνονται είναι ενθαρρυντικά σχετικά με τη χρήση της περιγραφόμενης τεχνολογίας σε περιβάλλον παραγωγής. 79

80 6 Συμπεράσματα 6.1 Γενικά Στην προσπάθεια επίλυσης του προβλήματος της αυτόματης εξεύρεσης και χρήσης APIs, μελετήθηκαν διάφορες προσεγγίσεις με στόχο τη διάθεση μιας παλέτας επιλογών προς μια πρότυπη λύση. Παράλληλα δόθηκε βάση στον τρόπο με τον οποίο αναπτύσσεται σήμερα το διαδίκτυο. Εξετάστηκε η ραγδαία ανάπτυξη του διαδικτύου και του τεράστιου όγκου δεδομένων που δημιουργείται καθημερινά. Με τα παραπάνω κατά νου, η εργασία στράφηκε στην έννοια του σημασιολογικού ιστού και πως αυτός θα επιτρέψει τη βέλτιστη αξιοποίηση του διαδικτύου. Πραγματοποιήθηκε λοιπόν μια υπόθεση και υλοποιήθηκε ένα παράδειγμα ώστε να εκτιμηθούν σε πρακτικό επίπεδο τα αποτελέσματά του. Έτσι, περιγράφηκαν τα δεδομένα που παρέχει ένας πάροχος με όρους ενός διαδεδομένου λεξιλογίου, του schema.org. Αναλύθηκαν και οι λειτουργίες που μπορούν να πραγματοποιηθούν σε αυτά με σημασιολογικούς όρους. Στη συνέχεια, αποδόθηκε μια περιγραφή και στην ίδια την αναπαράσταση του παρόχου με τη βοήθεια του λεξιλογίου HYDRA. Δημιουργήθηκε λοιπόν μια σειρά από δεδομένα και παρόχους οι οποίοι χρησιμοποιούν τους ίδιους όρους για να περιγράψουν τα ίδια δεδομένα ή οντότητες γενικότερα. Το κυρίαρχο συμπέρασμα που προκύπτει είναι η ξεκάθαρη ανάγκη της επέκτασης και χρήσης των τεχνολογιών του σημασιολογικού ιστού, καθώς επιτρέπουν την ορθότερη διαχείριση των δεδομένων που εμφανίζονται σήμερα στο διαδίκτυο. 6.2 Call by Context Ο τίτλος της εργασίας προέρχεται από το γεγονός ότι δεν απαιτείται πρότερη γνώση των παρόχων των υπηρεσιών που χρησιμοποιούνται. Η χρήση ενός κοινού πλαισίου επικοινωνίας ανάμεσα στα συνδιαλεγόμενα μέρη επιτρέπει την απρόσκοπτη επικοινωνία μεταξύ τους. Ταυτόχρονα αυτοματοποιεί μεγάλο ποσοστό της επικοινωνίας αυτής. Ανατρέχοντας σε ολόκληρη τη διαδικασία που έλαβε χώρα, από τους εξυπηρετητές που παρέχουν δεδομένα μέχρι τον τελικό πελάτη client, αντιλαμβάνεται κανείς τον καίριο ρόλο που διαδραματίζει το πλαίσιο επικοινωνίας context. Το πλαίσιο αυτό δεν είναι άλλο παρά ένα σύνολο κοινών αποδεκτών λεξιλογικών όρων. Αυτό από μόνο του μπορεί να προσφέρει ένα σύνολο δυνατοτήτων όπως αυτές αναλύονται παρακάτω. Αυτοματοποίηση παραγωγής εσωτερικών αναπαραστάσεων Η δημιουργία της εσωτερικής αναπαράστασης των δεδομένων μεταφέρεται ένα επίπεδο υψηλότερα. Δεν απασχολεί η γλώσσα προγραμματισμού, αλλά εξετάζεται αφαιρετικά το μοντέλο δεδομένων, όπως και θα έπρεπε για το μεγαλύτερο πλήθος εφαρμογών. Τα 80

81 πεδία τιμών έχουν σαφείς περιορισμούς, ενώ εκφράζεται και η ιεραρχία μεταξύ των κλάσεων. Επαναχρησιμοποίηση κώδικα/μοντέλου δεδομένων Η σχεδίαση και χρήση ενός προσαρμοσμένου λεξιλογίου για μία υπηρεσία δεν αποτελεί μεγαλύτερη πρόκληση από τη σχεδίαση του μοντέλου δεδομένων σε μια σχεσιακή βάση. Δεν χρειάζεται να περιγραφεί στην ολότητά του, αντίθετα μπορεί να βασιστεί σε πιο γενικευμένα λεξιλόγια. Η χρήση ενός λεξιλογίου με σαφείς οντότητες - κλάσεις, αποδίδει στα δεδομένα ένα στιβαρό μοτίβο έκφρασης της απαιτούμενης επιχειρησιακής λογικής. Το λεξιλόγιο πιθανόν να χρειάζεται επέκταση ή μικροαλλαγές, αλλά δεν παύει να πληροί όρους και προϋποθέσεις που έχουν σχεδιαστεί αναλυτικά από μηχανικούς δεδομένων στο μεγαλύτερο κομμάτι του. Η χρήση ενός αναγνωρίσιμου και εγκαθιδρυμένου λεξιλογίου εξασφαλίζει συμβατότητα και με περισσότερες υπηρεσίες. Επίσης διευκολύνει την περιγραφή κοινότυπων μοντέλων. Κοινοποίηση μοντέλου δεδομένων Η διάθεση και δημοσιοποίηση αυτού του μοντέλου γίνεται σαφώς απλούστερη, μέσα από ένα λεξιλόγιο. Οι εναλλακτικές μέθοδοι προσφέρουν ελάχιστη επεκτασιμότητα. Καθώς πιθανές ανανεώσεις σε μια υπηρεσία μπορεί να επιφέρουν αλλαγές στο μοντέλο δεδομένων, μέσω ενός λεξιλογίου αλλά και της αντίστοιχης αυτοματοποίησης που έχει επιτευχθεί, μπορούν να ενσωματωθούν δίχως ανθρώπινη παρέμβαση. Έτσι ελαχιστοποιείται και ο χρόνος συντήρησης μιας εφαρμογής. Μείωση υπολογιστικού κόστους Το υπολογιστικό κόστος που απαιτείται για την αυτοματοποίηση των διαδικασιών είναι αισθητά μικρότερο από την απευθείας συντακτική ανάλυση τυχόν κειμένων σε ανθρώπινη γλώσσα ή αναπαραστάσεων αρκετά διαφορετικών μεταξύ τους. Επιτρέπει την ενσωμάτωση τέτοιων τεχνολογιών στον πελάτη δίχως να επιβαρύνεται η προσλαμβανόμενη εμπειρία του χρήστη. Εκθετική ανάπτυξη Η σταδιακή χρήση των τεχνολογιών αυτών θα επιφέρει εκθετική ανάπτυξη στο διαδίκτυο. Καθώς περισσότερες υπηρεσίες θα υιοθετούν τέτοιες τεχνολογίες, μεγαλύτερος όγκος πληροφοριών θα δημιουργείται, ο οποίος θα είναι προσβάσιμος και ιχνηλατίσιμος αυτόματα, δημιουργώντας έτσι μία νέα δυναμική. 81

82 Τεχνητή νοημοσύνη Σε μελλοντικό χρόνο, η προτασιακή λογική που ενέχει ένα λεξιλόγιο επιτρέπει σε όποιον διαθέτει τα κατάλληλα εργαλεία, να εξάγει και ανάλογα συμπεράσματα. Προσεγγίζεται με αυτόν τον τρόπο διακριτικά, αλλά σταθερά η ενσωμάτωση της τεχνητής νοημοσύνης στο διαδίκτυο. Αυτοματοποίηση πρακτόρων λογισμικού Παρουσιάζεται η δυνατότητα προγραμματισμού ενός πράκτορα λογισμικού ο οποίος θα πραγματοποιεί σύνθετες ενέργειες σε ένα πλήθος δεδομένων και θα επιστρέφει σαφή αποτελέσματα. Με τη γνώση των λεξιλογικών όρων εκ των προτέρων, δεν χρειάζεται η κλήση υπηρεσιών ή δεδομένων από προκαθορισμένες πηγές. Ο πράκτορας είναι σε θέση να περιηγηθεί μόνος του και να αυτοματοποιήσει διαδικασίες που μέχρι πρότινος απαιτούσαν ανθρώπινη επίβλεψη. 6.3 Μετάβαση στον σημασιολογικό ιστό Στην παρούσα εργασία, η αλυσίδα δημιουργίας εφαρμογών χρησιμοποιεί μια σειρά από εργαλεία και τεχνολογίες οι οποίες δεν είναι ενσωματωμένες στην παραγωγή, με στόχο να αυτοματοποιήσει κάποια στάδια της παραγωγής κώδικα, και να επιλύσει προβλήματα που πηγάζουν από τη ρητή κλήση APIs. Ο τρόπος που εισάγονται αυτές οι τεχνολογίες δεν είναι ασυνεχής. Βασίζεται στο πρότυπο σχεδίασης RESTful και HATEOAS. Οι τεχνολογίες που επιλέχθηκαν να εκτεθούν στον προγραμματιστή δεν είναι άγνωστες προς αυτόν. Η χρήση του JSON-LD ως αναπαράσταση ενός RDF γράφου επιλέχθηκε λόγω της διάδοσης του προτύπου JSON το οποίο χρησιμοποιείται κατά κόρον. Το λεξιλόγιο του schema.org, είναι ίσως το πιο διαδεδομένο. Αποτελεί στην ουσία απαίτηση σήμερα από τις μηχανές αναζήτησης για τη βελτιστοποίηση της κατάταξης μιας ιστοσελίδας στη λίστα αποτελεσμάτων. Δεν διαταράσσεται σημαντικά η υπάρχουσα διαδικασία παραγωγής κώδικα. Αντίθετα η επένδυση χρόνου προς αυτή την κατεύθυνση έχει σίγουρα να αποφέρει πλεονεκτήματα στην κατεύθυνση της αυτοματοποίησης εργασιών. Έχουν γίνει αρκετές κινήσεις προς τη μετάβαση στον σημασιολογικό ιστό αλλά ακόμη δεν έχει υιοθετηθεί από τους άμεσα ενδιαφερόμενους, τους προγραμματιστές και τους μηχανικούς λογισμικού. Η προσέγγιση αυτή προσπάθησε να διευκολύνει τον ενδιαφερόμενο από πλευράς σχεδίασης, αλλά και μέσω της παροχής εργαλείων και παραδειγμάτων. 82

83 7 Μελλοντικές Επεκτάσεις Η υλοποίηση που παρουσιάστηκε είναι απλή και ευέλικτη. Στόχο είχε να αναδείξει την αναγκαιότητα της υιοθέτησης των εννοιών του σημασιολογικού ιστού στην τυπική συγγραφή υπηρεσιών και ιστότοπων. Στην παρούσα φάση ενσωματώθηκε μόνο ένα μέρος των διαθέσιμων προτύπων. Παρακάτω θα αναλυθούν μερικές μελλοντικές επεκτάσεις που μπορούν να αποδώσουν επιπλέον λειτουργικότητα και να οδηγήσουν σε μία πληρέστερη υλοποίηση. 7.1 SHACL Λεξιλόγιο περιορισμών μέσω σχημάτων Το πρότυπο SHACL [44] αποτελεί ένα περιγραφικό λεξιλόγιο με το οποία μπορεί να ελεγθεί ένας RDF γράφος ως προς ένα σύνολο κανόνων ή σχημάτων. Με τη χρήση του SHACL εκφράζονται με συστηματικό τρόπο περιορισμοί που πρέπει να ικανοποιούνται για τα δεδομένα που περιγράφει ο γράφος μας. Στην παρούσα υλοποίηση χρησιμοποιήθηκαν σαφής περιορισμοί όπως ο τύπος της επιστρεφόμενης κλάσης ώστε το αποτέλεσμα να είναι το επιθυμητό και διαχειρίσιμο αναλόγως. Από την άλλη, έγιναν κάποιες απλοποιήσεις και στην προσπάθεια να αξιοποιηθεί μεγαλύτερη γκάμα επιλογών δεν ορίστηκαν επιστρεφόμενοι τύποι σε άλλες ιδιότητες του μοντέλου μας. Το SHACL έρχεται να συμπληρώσει ακριβώς αυτό το κενό και να δώσει τα εργαλεία για την περιγραφή σε ανώτερο επίπεδο αυτών των περιορισμών. Τέτοιοι περιορισμοί μπορεί να είναι ο τύπος των δεδομένων ή το σύνολο τιμών που μπορεί να δεχθεί. Για παράδειγμα, με την παρούσα υλοποίηση μπορεί να δηλωθεί ότι η τιμή είναι αριθμός κινητής υποδιαστολής αλλά δε γίνεται να οριστεί ότι δεν περιέχει αρνητικούς αριθμούς. Το λεξιλόγιο HYDRA και ένα κομμάτι του schema.org αποτελούν σημαντικό κομμάτι της υλοποίησης. Σε αυτά θα μπορούσε να προστεθεί και το λεξιλόγιο SHACL ώστε να αποσαφηνιστούν περαιτέρω τα δεδομένα. Υπενθυμίζεται εδώ ότι μπορεί να χρησιμοποιηθεί όλο το φάσμα των λεξιλογίων για την περιγραφή των δεδομένων. Όμως όροι από τα λεξιλόγια που περιγράφονται παραπάνω αποτελούν κομμάτι ενσωματωμένο μέσα στον κώδικα, ώστε να επιτευχθεί η ζητούμενη αυτοματοποίηση. 7.2 Linked Data Fragments Η αυτόματη εξεύρεση APIs παρέχει δεδομένα στον client μέσα από την τυπική επικοινωνία στα πλαίσια του HTTP με POST/GET και τα ορίσματά τους, είτε αυτά είναι δεδομένα είτε URIs. Υπάρχουν όμως και τα συνδεδεμένα δεδομένα (Linked Data) [45] τα οποία βρίσκονται αποθηκευμένα σε γράφους και η πρόσβαση σε αυτά πραγματοποιείται μονάχα από SPARQL endpoints. Χρειάζεται εν ολίγοις η παροχή της δυνατότητας στον πελάτη να πραγματοποιεί SPARQL ερωτήματα. Αυτό θα δώσει 83

84 πρόσβαση σε σετ δεδομένων με αναλυτική πληροφορία όπως είναι η DΒpedia [46] (σημασιολογική έκδοση της Wikipedia) ή σετ δεδομένων από το DataHub [47]. Η ενσωμάτωση της SPARQL δυνητικά θα επιτρέψει στον πελάτη να παρακάμψει τον front-end server (API-Resolver) και να απευθυνθεί στον Jena/Fuseki που έχει όλη την απαραίτητα πληροφορία. Αυτή η διαδικασία απαιτεί βέβαια την επανασχεδίαση του πελάτη ώστε να μην χαθεί κομμάτι του αλγορίθμου αντιστοίχησης. Αυτό το τελευταίο κομμάτι αποθαρρύνεται και περιγράφεται εδώ μόνο για λόγους αναφοράς. Η πραγματοποίηση της επίλυσης και αντιστοιχίας ορθότερο είναι να πραγματοποιείται από ένα μηχάνημα το οποίο έχει περισσότερους υπολογιστικούς πόρους από όσους θα είχε έναν πιθανός πελάτης. 7.3 ConceptNet Το ConceptNet [48] [49] είναι ένα σημασιολογικό δίκτυο δεδομένων. Αποτελείται από τις γνωστές προτάσεις RDF που αναλύθηκαν στην Ενότητα Το ConceptNet αποτελεί μία βάση γνώσης (Knowledge Base) και στόχο έχει να περιγράψει στον υπολογιστή το κοινό πλαίσιο επικοινωνίας που χρησιμοποιούν οι άνθρωποι. Αυτό το πετυχαίνει με τη χρήση ορισμών λέξεων, όπως και με κοινότυπες προτάσεις που μπορεί να τις περιέχουν. Με βάση αυτά τα δεδομένα δημιουργούνται διανύσματα με βάρη. Ο αλγόριθμος πίσω από το ConceptNet είναι σε θέση να πραγματοποιήσει συσχετίσεις και να εξετάσει τη συνάφεια των περιγραφόμενων λέξεων. Με αυτή τη διαδικασία εξάγεται πληροφορία η οποία μπορεί να αξιοποιηθεί από τον υπολογιστή. Με τη χρήση του ConceptNet εισάγεται το στοιχείο της τεχνητής νοημοσύνης στα πλαίσια της αυτόματης εξεύρεσης υπηρεσιών. Αναλύοντας μια σειρά από περιγραφές φυσικής γλώσσας θα μπορούσαν να πραγματοποιηθούν οι αντιστοιχίες σε όρους λεξιλογίων και έπειτα στα προσφερόμενα APIs. Το σενάριο αυτό βέβαια είναι αρκετά πολύπλοκο σε επίπεδο υλοποίησης. Δεν πρέπει να ξεχνά κανείς ότι προϋπόθεση πάντα είναι η σταθερή και απροβλημάτιστη λειτουργία της μέχρι τώρα μετάβασης. 7.4 Επίλογος Η ενσωμάτωση του σημασιολογικού ιστού πραγματοποιείται σταθερά αν και απαιτούνται πολλά ακόμη βήματα προς αυτή την κατεύθυνση. Η επέκταση όμως του σημασιολογικού ιστού σε θεωρητικό επίπεδο συνεχίζεται με γρηγορότερους ρυθμούς. Αναμένεται λοιπόν ότι νέα πρότυπα θα εμφανιστούν όσο δημοφιλέστερες γίνονται οι τεχνολογίες που εξετάστηκαν, επομένως πρέπει να παρακολουθείται στενά αυτή τη μετάβαση στο WEB

85 Παράρτημα A Στα πλαίσια της ολοκληρωμένης παρουσίασης των δυνατοτήτων ολόκληρης της αλυσίδας παραγωγής διαδικτυακών υπηρεσιών, δημιουργήθηκε μια ιστοσελίδα με σκοπό να παρέχει άμεσα στον προγραμματιστή μια συνολική εικόνα. Η ιστοσελίδα αυτή γνωστή και ως playground ή kitchen sink, παρουσιάζεται παρακάτω και είναι διαθέσιμη στη διεύθυνση: Αποτελείται από τρεις διακριτές καρτέλες, κάθε μία με ξεχωριστή λειτουργικότητα. Όλες όμως παρουσιάζουν τον εκάστοτε γράφο με τέσσερις πιθανούς τρόπους ώστε να γίνεται ευκολότερη η κατανόηση των διαδικασιών. Παρουσίαση Γράφου Κειμενογράφος Text Editor Ο κειμενογράφος επιτρέπει την άμεση επεξεργασία ενός γράφου εκφρασμένου σε JSON- LD σύνταξη. Παρέχεται η δυνατότητα αναζήτησης εντός του γράφου καθώς και η αποθήκευσή του τοπικά. 85

86 Οπτικοποίηση γράφου Ο γράφος οπτικοποιείται με τη μορφή κόμβων οι οποίοι επεκτείνονται όταν επιλεχθούν από το χρήστη. Η παρούσα αναπαράσταση παρουσιάζει την ιεραρχία των κόμβων με τον πλέον κατανοητό τρόπο. 86

87 Παρουσίαση κλάσεων σε μορφή πίνακα Ο πίνακας αποδίδει μια αναλυτική και συνεκτική παρουσίαση. Κάθε κλάση αποτελεί μια γραμμή η οποία επεκτείνεται και παρουσιάζει δύο άλλους πίνακες. Ο πρώτος περιέχει τις ιδιότητες της κλάσης και ο δεύτερος τις επιτρεπόμενες ενέργειες. 87

88 Αυτόματη δημιουργία κλάσεων Οι μέθοδοι HTTP και οι ενέργειες που είναι διαθέσιμες στον επιλεγμένο γράφο παρέχονται αυτόματα. Δημιουργείται ένα στιγμιότυπο από κάθε κλάση ώστε να πραγματοποιηθούν οι αντίστοιχες ενέργειες. Παράλληλα δίνεται και μια μικρή περιγραφή του αντίστοιχου κώδικα που θα έπρεπε να χρησιμοποιηθεί. 88