Σύστηµα Διαχείρισης Περιεχοµένου για τον Σηµασιολογικό Ιστό βασισµένο στο Αρχιτεκτονικό Στυλ REST

Transcript

1 ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΣΧΟΛΗ ΘΕΤΙΚΩΝ ΕΠΙΣΤΗΜΩΝ - ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ Σύστηµα Διαχείρισης Περιεχοµένου για τον Σηµασιολογικό Ιστό βασισµένο στο Αρχιτεκτονικό Στυλ REST Διπλωµατική Εργασία του Άγγελου Άρµεν (ΑΕΜ: 1198) Επιβλέπων Καθηγητής: Νίκος Βασιλειάδης ΘΕΣΣΑΛΟΝΙΚΗ ΟΚΤΩΒΡΙΟΣ i-

2

3 Πρόλογος Ο Παγκόσµιος Ιστός έχει εξελιχθεί σε ένα πελώριο και αχανές σύστηµα διασυνδεµένων πόρων ποικίλων ειδών και είναι πλέον στην καθηµερινότητα όλων µας. Το 2000 o Roy Fielding περιέγραψε το αρχιτεκτονικό στυλ του Ιστού που ονόµασε REST (REpresentational State Transfer), ένα σύνολο από αρχές που σύµφωνα µε τους υποστηρικτές του REST έπαιξαν βασικό ρόλο στην επιτυχία και την κλιµακωσιµότητα του Ιστού. Ο Σηµασιολογικός Ιστός ξεκίνησε ως ένα όραµα για το µέλλον του τρέχοντος Ιστού, όπου θα υπάρχουν πληροφορίες σε µορφή κατανοητή και απο τις µηχανές, κάτι που δεν συµβαίνει σήµερα, αφού τα έγγραφα προορίζονται κυρίως για ανάγνωση από τους ανθρώπους. Ο ιστός αυτός θα είναι µια επέκταση του τρέχοντος, και η ανάπτυξη των τεχνολογιών που θα τον κάνουν πραγµατικότητα βρίσκεται σε εξέλιξη και αποτελεί ένα εκτενές πεδίο έρευνας. Στόχος της διπλωµατικής εργασίας είναι η κατασκευή ενός συστήµατος διαχείρισης περιεχοµένου (Content Management System, CMS) που θα ακολουθεί τις αρχές του REST και θα κάνει εύκολη την δηµοσίευση περιεχοµένου για τον Σηµασιολογικό Ιστό, παράλληλα µε αυτό που προορίζεται για τους ανθρώπους χρήστες. Η εκπόνηση της εργασίας έγινε στο εργαστήριο Γλωσσών Προγραµµατισµού και Τεχνολογίας Λογισµικού (Programming Languages and Software Engineering Laboratory PLaSE Laboratory) του Τµήµατος Πληροφορικής του Α.Π.Θ., σε συνεργασία µε την οµάδα Λογικού Προγραµµατισµού και Ευφυών Συστηµάτων (Logic Programming and Intelligent Systems Group LPIS Group). Θα ήθελα να ευχαριστήσω την οικογένειά µου και τους φίλους µου για τη στήριξή τους καθ όλη τη διάρκεια εκπόνησης της διπλωµατικής µου εργασίας! Άγγελος Άρµεν 6 Οκτωβρίου i-

4 -ii-

5 Περιεχόµενα ΠΡΟΛΟΓΟΣ... I ΠΕΡΙΕΧΟΜΕΝΑ...III 1 ΕΙΣΑΓΩΓΗ ΠΑΓΚΟΣΜΙΟΣ ΙΣΤΟΣ Η ΑΡΧΙΤΕΚΤΟΝΙΚΗ ΤΟΥ ΠΑΓΚΟΣΜΙΟΥ ΙΣΤΟΥ ΤΟ ΑΡΧΙΤΕΚΤΟΝΙΚΟ ΣΤΥΛ REST Αρχές Πόροι στο REST Ο Παγκόσµιος Ιστός ως «RESTful» σύστηµα ΣΗΜΑΣΙΟΛOΓΙΚΟΣ ΙΣΤΟΣ Η Στοίβα του Σηµασιολoγικού Ιστού RDF RDFS OWL ΑΠΑΙΤΗΣΕΙΣ ΧΕΙΡΙΣΜΟΣ REST αρχιτεκτονική Χειρισµός πληροφοριακών πόρων «Χειρισµός» µη πληροφοριακών πόρων Χειρισµός ανά τύπο / κλάση Φόρµες επεξεργασίας πόρων ΣΥΣΤΑΤΙΚΑ Ανεξαρτησία διεπαφής συστατικών της υλοποίησης Αρθρωτή και επεκτάσιµη αρχιτεκτονική Χειρισµός των ρυθµίσεων και των συστατικών του συστήµατος µέσω της διεπαφής Ιστού Διαµοιρασµός συστατικών του συστήµατος iii-

6 3.2.5 Σύστηµα εκδόσεων συστατικών Προστασία πόρων του συστήµατος Έλεγχος πρόσβασης ΣΧΕΔΙΑΣΗ MODULES Οι δυο όψεις του συστήµατος System module Μορφή των modules Οντολογία πληροφοριακών πόρων Πληροφοριακοί πόροι περιγραφής Βοηθητικοί πόροι: To µοντέλο Πολλαπλών Χρήσεων Χειρισµός συστατικών µέσω της διεπαφής Ιστού: το µοντέλο Ελέγχου ΓΕΝΙΚΗ ΟΝΤΟΛΟΓΙΑ ΤΟΥ ΣΥΣΤΗΜΑΤΟΣ Modules Application ΥΠΟΜΟΝΤΕΛΑ ΧΕΙΡΙΣΜΟΣ Χειριστές Χειρισµός ανά τύπο / κλάση Χερισµός και υποµοντέλα CONTROL ANNOTATION PROPERTIES Ο αλγόριθµος εύρεσης της τιµής µιας Control Annotation Property Άλλες control annotation properties ΤΟ ΠΛΑΙΣΙΟ ΕΞΑΡΤΗΣΕΙΣ ΜΕΤΑΦΟΡΑ ΕΡΓΑΛΕΙΑ JENA Το API της Jena Το Ontology API της Jena OntResource RESTLET iv-

7 5.2.1 Βασικά χαρακτηριστικά Σύντοµο tutorial στο Restlet ΥΛΟΠΟΙΗΣΗ ΠΑΚΕΤΑ ΚΑΙ ΒΑΣΙΚΕΣ ΚΛΑΣΕΙΣ Λογική οργάνωση των πακέτων ΓΕΝΙΚΟ ΠΑΚΕΤΟ Application Module Model Submodel ΠΑΚΕΤΟ ΤΟΥ RESTLET Δοµή καταλόγων Application Module Model Submodel ΠΑΚΕΤΟ ΤΗΣ JENA ModelManager RDBModelManager ControlAnnotationProperty ΠΑΚΕΤΟ RESTLET ΚΑΙ JENA ApplicationUtils SemanticModelTransferrer Archiver ModelUtils ResourceUtils Επισκόπηση της αρχιτεκτονικής της υλοποίησης PiSquaredRestletApplication RootRestlet BaseResource BaseRedirector ΕΠΙΔΕΙΞΗ v-

8 7.1 ΕΓΚΑΤΑΣΤΑΣΗ Ρυθµίσεις ΕΚΤΕΛΕΣΗ Πλοήγηση µε τον Browser Ανάκτηση πληροφοριακού πόρου Ανάκτηση περιγραφής Επεξεργασία περιγραφής Επεξεργασία πληροφοριακού πόρου Διαγραφή πόρων ΣΥΜΠΕΡΑΣΜΑΤΑ ΚΑΙ ΜΕΛΛΟΝΤΙΚΗ ΕΡΓΑΣΙΑ...93 ΒΙΒΛΙΟΓΡΑΦΙΑ vi-

9 1 Εισαγωγή Ο Παγκόσµιος Ιστός, που εφευρέθηκε το 1989 στο CERN από τον φυσικό Sir Tim Burners-Lee έχει εξελιχθεί σε ένα πελώριο και αχανές σύστηµα διασυνδεόµενων πόρων ποικίλων ειδών και είναι πλέον στην καθηµερινότητα όλων µας. Η πληροφορία στον Ιστό κατανέµεται σε πόρους που ταυτοποιούνται από καθολικούς ταυτοποιητές, τα URIs. Πληροφοριακοί πόροι είναι αυτοί των οποίων τα ουσιώδη χαρακτηριστικά µπορούν να ενθυλακωθούν σ' ένα µήνυµα, τ' οποίο αποτελεί µια αναπαράσταση του πόρου. Μέσω του URI ενός πόρου, ένας χρήστης µπορεί ν' ανακτήσει την αναπαράσταση του πόρου αυτού. Το 2000 o Roy Fielding, ένας από τους πρωτεργάτες του πρωτοκόλλου HTTP, περιέγραψε στην διπλωµατική του εργασία το αρχιτεκτονικό στυλ του Ιστού που ονόµασε REST (REpresentational State Transfer), ένα σύνολο από αρχές που σύµφωνα µε τους υποστηρικτές του REST έπαιξαν βασικό ρόλο στην επιτυχία και την κλιµακωσιµότητα του Ιστού. Κύριο στοιχείο της αρχιτεκτονικής είναι οι πόροι, στους οποίους εκτελούµε ένα περιορισµένο σύνολο από µεθόδους, που στον Ιστό είναι οι µέθοδοι HTTP. Ο Σηµασιολογικός Ιστός ξεκίνησε ως ένα όραµα για το µέλλον του τρέχοντος Ιστού, όπου θα υπάρχουν αναπαράστασεις σε µορφή κατανοητή και από τις µηχανές, κάτι που δε συµβαίνει σήµερα, αφού οι ιστοσελίδες προορίζονται κυρίως για ανάγνωση από τους ανθρώπους. Ο ιστός αυτός θα είναι µια επέκταση του τρέχοντος, και η ανάπτυξη των τεχνολογιών που θα τον κάνουν πραγµατικότητα βρίσκεται σε εξέλιξη και αποτελεί ένα εκτενές πεδίο έρευνας. Υπάρχουν πολλά συστήµατα διαχείρισης περιεχοµένου(content Management Systems, CMS) για τον Ιστό, που διευκολύνουν τη δηµοσίευση και τον χειρισµό περιεχοµένου απευθυνόµενο όµως κυρίως σε ανθρώπους αναγνώστες. Στόχος της διπλωµατικής αυτής εργασίας είναι η κατασκευή ενός CMS που θα ακολουθεί τις αρχές του REST και θα κάνει εύκολη την δηµοσίευση περιεχοµένου για τον Σηµασιολογικό Ιστό, παράλληλα µε αυτό που προορίζεται για τους ανθρώπους αναγνώστες. -1-

10 Ακολουθούν λίγα λόγια για το περιεχόµενο των επόµενων κεφαλαίων: Δεύτερο κεφάλαιο: Παγκόσµιος Ιστός Το δεύτερο κεφάλαιο αναφέρεται στην αρχιτεκτονική του Ιστού, στο αρχιτεκτονικό στυλ RESTκαι στα πλεονεκτήµατα του και έπειτα στον Σηµασιολογικό Ιστό και τις τεχνολογίες του. Τρίτο κεφάλαιο: Απαιτήσεις Γίνεται ανάλυση των απαιτήσεων του συστήµατος διαχείρισης περιεχοµένου που θα κατασκευαστεί. Οι απαιτήσεις αυτές διακρίνονται σε αυτές που αφορούν τον χειρισµό των πόρων και αυτές που αφορούν τα συστατικά του συστήµατος. Τέταρτο κεφάλαιο: Σχεδίαση Γίνεται η αφηρηµένη σχεδίαση του συστήµατος που πληροί τις απαιτήσεις, χωρίς αναφορά σε κάποια συγκεκριµένη υλοποίηση. Πέµπτο κεφάλαιο: Εργαλεία Περιγράφονται τα εργαλεία που χρησιµοποιήθηκαν για την υλοποίηση του συστήµατος. Αυτά είναι τα πλαίσια (frameworks) Restlet καιjena. Έκτο κεφάλαιο: Υλοποίηση Περιγράφεται η δοµή της υλοποίησης του συστήµατος και οι σηµαντικότερες κλάσεις από κάθε πακέτο (package). Έβδοµο κεφάλαιο: Επίδειξη Παρέχονται οδηγίες για την εγκατάσταση του συστήµατος και γίνεται επίδειξη των δυνατοτήτων του µέσω της περιγραφής µιας δοκιµαστικής εκτέλεσης του, συνοδευόµενη από screenshots. Όγδοο κεφάλαιο: Συµπεράσµατα και Μελλοντική Εργασία Γίνεται µια σύντοµη ανασκόπηση του τι υλοποιήθηκε και τι αποτελεί µελλοντική εργασία, καθώς και µια µικρή αναφορά στα προβλήµατα και στις δυσκολίες που αντιµετωπίστηκαν. -2-

11 2 Παγκόσµιος Ιστός Ο Παγκόσµιος Ιστός (World Wide Web) είναι ένα σύστηµα διασυνδεόµενων εγγράφων υπερκειµένου (ιστοσελίδες) προσβάσιµων µέσω του Διαδικτύου κάνοντας χρήση ειδικών προγραµµάτων, των φυλλοµετρητών (web browsers). Εφευρέθηκε από τον Sir Tim Bernens-Lee, φυσικό του CERN στην Ελβετία. Ο ίδιος ίδρυσε και διευθύνει το W3C (World Wide Web Consortium, Κοινοπραξία Παγκοσµίου Ιστού), που είναι ο κύριος οργανισµός που αναπτύσσει πρότυπα για τον Παγκόσµιο Ιστό (τα λεγόµενα web standards). To W3C είναι µια κοινοπραξία των πανεπιστηµίων MIT και Keio και του ERCIM (European Research Consortium for Informatics and Mathematics). 2.1 Η αρχιτεκτονική του Παγκόσµιου Ιστού Τα αντικείµενα πληροφορίας στον Ιστό ονοµάζονται πόροι. Κάθε πόρος ταυτοποιείται µοναδικά από ένα καθολικό αναγνωριστικό που ονοµάζεται URI (Uniform Resource Identifier). Δεν έχει τόση σηµασία η σύνταξη ενός URI αλλά το γεγονός ότι έχει καθολική εµβέλεια. Μια αρχή για τα URI είναι ότι πρέπει να είναι αδιαφανή (opaque): ο χρήστης δεν πρέπει να υποθέτει τίποτα για τον τύπο του πόρου από τη σύνταξη του URI 1. Δεν υπάρχει περιορισµός στο τι µπορεί να ταυτοποιείται από ένα URI. Ένας πόρος είναι µια νοητή οντότητα, κάτι σαν ένα Πλατωνικό ιδανικό 2. Στον Ιστό όµως οι πόροι συνήθως ταυτοποιούν έγγραφα (ιστοσελίδες, εικόνες κλπ.). Τέτοιου είδους πόροι ονοµάζονται πληροφοριακοί πόροι (θα τους αναφέρουµε απλά ως ΠΠ): Ένας πληροφοριακός πόρος είναι ένας πόρος που ταυτοποιείται από ένα URI και του οποίου τα ουσιώδη χαρακτηριστικά µπορούν να διαβιβαστούν σ ένα µήνυµα 3. Για παράδειγµα, ένας φοιτητής ή ένα κτίριο είναι πόροι, αλλά κανένα µήνυµα δεν µπορεί να ενθυλακώσει σε µια ακολουθία από bits τα πάντα για έναν φοιτητή, κάθε 1 παρ όλα αυτά η αρχή δεν ισχύει για το κοµµάτι του URI µετά το «?», που είναι γνωστό ως query string (

12 τέτοιο µήνυµα δεν θα είναι παρά µια προσέγγιση, επειδή η ουσία ενός τέτοιου πόρου δεν είναι η πληροφορία. Αυτοί οι πόροι θα αναφέρονται ως µη πληροφοριακοί ή απλά µη ΠΠ. Αναπαράσταση Μια αναπαράσταση είναι δεδοµένα που κωδικοποιούν πληροφορία για την κατάσταση ενός πόρου. Οι πράκτορες (κατάλληλο λογισµικό όπως π.χ. οι φυλλοµετρητές) χρησιµοποιούν τα URI για να προσπελάσουν τον ταυτοποιούµενο πόρο, κάτι που ονοµάζεται αποαναφορά (dereferencing) του πόρου. Η προσπέλαση µπορεί να είναι: Ανάκτηση µιας αναπαράστασης του πόρου (π.χ. µε χρήση της HTTP µεθόδου GET). Τροποποίηση ή προσθήκη µιας αναπαράστασης (π.χ. µε χρήση των µεθόδων POST, PUT) Διαγραφή µιας αναπαράστασης (π.χ. µε χρήση της µεθόδου DELETE) Η Εικόνα 1 δείχνει τη σχέση µεταξύ προσδιοριστή, πόρου και αναπαράστασης, για τον φανταστικό πόρο «Δελτίο καιρού της Oaxaca». Εικόνα 1 Σχέση µεταξύ προσδιοριστή, πόρου και αναπαράστασης. Πηγή: Διαπραγµάτευση περιεχοµένου Η διαπραγµάτευση περιεχοµένου (content negotiation) αναφέρεται στην πρακτική του να παρέχονται πολλαπλές αναπαραστάσεις µέσω του ίδιου URI. Διαπραγµάτευση -4-

13 µεταξύ του αιτούµενου πράκτορα και του εξυπηρέτη καθορίζει ποια αναπαράσταση «σερβίρεται». 2.2 Το αρχιτεκτονικό στυλ REST To Representational State Tranfer (REST) είναι ένα αρχιτεκτονικό στυλ για κατανεµηµένα συστήµατα υπερµέσων (hypermedia), όπως ο Παγκόσµιος Ιστός. Οι όροι «Representational State Transfer» και «REST» παρουσιάστηκαν το 2000 στη διδακτορική διατριβή του Roy Fielding (Fielding, 2000). To REST αναφέρεται σ' ένα σύνολο αρχών αρχιτεκτονικής δικτύου που περιγράφουν πώς οι πόροι ορίζονται και διευθυνσιοδοτούνται. Συστήµατα που ακολουθούν τις αρχές του REST συνήθως αναφέρονται ως «RESTful» Αρχές 4 Οι υποστηρικτές του REST υποστηρίζουν ότι η κλίµακα και ανάπτυξη του Παγκόσµιου Ιστού είναι άµεσο αποτέλεσµα µερικών βασικών σχεδιαστικών αρχών: Η κατάσταση (state) και η λειτουργικότητα της εφαρµογής διαιρούνται σε πόρους. Κάθε πόρος είναι µοναδικά διευθυνσιοδοτούµενος χρησιµοποιώντας µια καθολική σύνταξη για χρήση σε συνδέσµους υπερµέσων (hypermedia links). Όλοι οι πόροι µοιράζονται µια οµοιόµορφη διεπαφή για τη µεταφορά κατάστασης µεταξύ του πελάτη και του πόρου, η οποία αποτελείται από o Ένα περιορισµένο σύνολο καλά ορισµένων λειτουργιών (well-defined operations) o Ένα περιορισµένο σύνολο από τύπους περιεχοµένου (content types), προαιρετικά υποστήριζοντας κώδικα on demand (code on demand). Ένα πρωτόκολλο το οποίο είναι o Πελάτη-Εξυπηρέτη (Client-server) o Άνευ κατάστασης (Stateless) o Αποθηκεύσιµο σε κρυφές µνήµες (Cacheable)

14 o Διαστρωµατωµένο (Layered) Σύµφωνα µε τον Fielding (Fielding 2000, 5.3.1), ο διαχωρισµός των ασχολιών του πελάτη και του εξυπηρέτη απλοποιεί την υλοποίηση των συστατικών, µειώνει την πολυπλοκότητα των διασυνδετών, βελτιώνει την αποτελεσµατικότητα των ρυθµίσεων απόδοσης (performance tuning), και αυξάνει τη δυνατότητα κλιµάκωσης (scalability) των αµιγών (pure) συστατικών εξυπηρέτη. Οι περιορισµοί των διαστρωµατωµένων συστηµάτων επιτρέπουν ενδιάµεσους -πληρεξούσιους εξυπηρέτες, πύλες και φράγµατα ασφαλείας- να εισαχθούν σε διάφορα σηµεία στην επικοινωνία χωρίς αλλαγή των διεπαφών των συστατικών, επιτρέποντας τους έτσι να βοηθούν στην µετάθεση της επικοινωνίας ή να βελτιώνουν την απόδοση µέσω µεγάλης κλίµακας διαµοιραζόµενης αποθήκευσης σε κρυφές µνήµες (caching). Το REST καθιστά εφικτή την ενδιάµεση επεξεργασία µε το να περιορίζει τα µηνύµατα να είναι αυτοεξηγούµενα: η αλληλεπίδραση είναι άνευ κατάστασης µεταξύ των αιτήσεων, οι πρότυπες µέθοδοι και τύποι πολυµέσων χρησιµοποιούνται για να δείξουν την σηµασιολογία και να ανταλλάξουν πληροφορία, και οι αποκρίσεις άµεσα αναγράφουν τη δυνατότητα ν' αποθηκευτούν σε κρυφή µνήµη (cacheability) Πόροι στο REST Κεντρική έννοια στο REST είναι οι πόροι, στους οποίους µπορεί να γίνει αναφορά µε χρήση ενός καθολικού ταυτοποιητή (π.χ. ένα URI). Για να χειριστούν αυτούς τους πόρους, τα συστατικά του δικτύου (πελάτες και εξυπηρέτες) επικοινωνούν µέσω µιας πρότυπης διεπαφής (στον Ιστό, το HTTP) και ανταλλάσσουν αναπαραστάσεις αυτών των πόρων (τα έγγραφα που µεταφέρουν την πληροφορία). Για παράδειγµα, ένας πόρος ο οποίος είναι ένας κύκλος µπορεί να δεχτεί και να επιστρέψει µια αναπαράσταση που ορίζει ένα κέντρο και µια ακτίνα, σε µορφή SVG, αλλά µπορεί επίσης και να δεχτεί και να επιστρέψει µια αναπαράσταση που ορίζει τρία διακριτά σηµεία πάνω στη καµπύλη ως µια λίστα διαχωρισµένη από κόµµα. Οποιοσδήποτε αριθµός διασυνδετών (π.χ. πελάτες, εξυπηρέτες, κρυφές µνήµες, σήραγγες κλπ.) µπορούν να µεσολαβήσουν στην αίτηση, µα καθένας το κάνει χωρίς να βλέπει πέρα από την δικιά του αίτηση (αυτό που αναφέραµε πριν ως «διαστρωµάτωση», layering). Έτσι µια εφαρµογή µπορεί ν' αλληλεπιδράσει µε έναν πόρο ξέροντας δυο πράγµατα: τον ταυτοποιητή του πόρου και την ενέργεια που απαιτείται -δεν χρειάζεται να ξέρει αν υπάρχουν κρυφές µνήµες, πληρεξούσιοι -6-

15 εξυπηρέτες, πύλες, φράγµατα ασφαλείας, σύραγγες ή οτιδήποτε άλλο µεταξύ της εφαρµογής και του εξυπηρέτη που κρατάει πραγµατικά την πληροφορία. Η εφαρµογή χρειάζεται παρ' όλα αυτά, να κατανοεί τη µορφή της πληροφορίας (αναπαράστασης) που επιστράφηκε, η οποία είναι συνήθως ένα έγγραφο HTML ή XML, αν και µπορεί να είναι µια εικόνα ή άλλο περιεχόµενο Ο Παγκόσµιος Ιστός ως «RESTful» σύστηµα Ο Παγκόσµιος Ιστός είναι το κύριο παράδειγµα µιας «RESTful» σχεδίασης, καθώς σε µεγάλο βαθµό συµµορφώνεται στις αρχές του REST: Πρωτόκολλο: Ο Ιστός χρησιµοποιεί το πρωτόκολλο HTTP. Το HTTP είναι ένα πρωτόκολλο πελάτη-εξυπηρέτη, και, όταν χρησιµοποιείται «RESTfully» είναι άνευ κατάστασης: κάθε µήνυµα περιέχει όλη την πληροφορία που είναι απαραίτητη για την κατανόηση µιας αίτησης, σε συνδυασµό µε την κατάσταση στον πόρο. Έτσι ο εξυπηρέτης δε χρειάζεται να θυµάται καµιά κατάσταση επικοινωνίας µεταξύ των µηνυµάτων. Ο περιορισµός της άνευ κατάστασης µπορεί να παραβιαστεί µε τη χρήση cookies για την διατήρηση των συνόδων (sessions). Ο Fielding(Fielding, 2000, ) επισηµαίνει το ρίσκο της διαρροής προσωπικών δεδοµένων και τις επιπλοκές στην ασφάλεια που εγείρονται από την χρήση των cookies, και τη σύγχυση και τα σφάλµατα που µπορούν να προκύψουν από τη χρήση cookies και του κουµπιού «Πίσω» ενός φυλλοµετρητή. Επίσης, το HTTP παρέχει µηχανισµούς για τον έλεγχο του caching και επιτρέπει µια συνοµιλία µεταξύ φυλλοµετρητή και κρυφής µνήµης στον ιστό (web cache) να πραγµατοποιηθεί µε τους ίδιους µηχανισµούς όπως µεταξύ ενός φυλλοµετρητή και ενός εξυπηρέτη Ιστού. Κανένα στρώµα δεν µπορεί να προσπελάσει συνοµιλία πέρα από αυτή στην οποία είναι άµεσα εµπλεκόµενο (διαστρωµάτωση). Οµοιόµορφη διεπαφή: Το HTTP έχει µια οµοιόµορφη διεπαφή για τη προσπέλαση πόρων, που αποτελείται από τα URIs, τις µεθόδους HTTP, τα status codes, τα headers και το περιεχόµενο που διακρίνεται από έναν τύπο MIME. o Οι µέθοδοι HTTP είναι ένα περιορισµένο σύνολο καλά ορισµένων λειτουργιών. Οι σηµαντικότερες µέθοδοι είναι οι POST, GET, PUT και DELETE, που συχνά συνδέονται µε τις λειτουργίες CREATE, READ, UPDATE, DELETE (CRUD) στις βάσεις δεδοµένων. -7-

16 o Οι τύποι MIME είναι ένα περιορισµένο σύνολο από τύπους περιεχοµένου (content types). o Κώδικας on demand: H HTML µπορεί να συµπεριλάβει κώδικα JavaScript και Java Applets για να υποστηρίξει κώδικα on demand. 2.3 Σηµασιολoγικός Ιστός Ο Σηµασιολογικός Ιστός είναι µια αναδυόµενη επέκταση του Παγκοσµίου Ιστού στον οποίο η σηµασιολογία της πληροφορίας και των υπηρεσιών ορίζεται σαφώς, κάνοντας δυνατό για τον ιστό να κατανοεί και να ικανοποιεί τις αιτήσεις για περιεχόµενο και των ανθρώπων και των µηχανών. (Berners-Lee, Hendler & Lassila, 2001) Στον τρέχοντα ιστό τα έγγραφα προορίζονται κυρίως για ανάγνωση από τους ανθρώπους. Αυτό κάνει δύσκολο για έναν υπολογιστή να εξάγει πληροφορία από µια ιστοσελίδα που περιέχει φυσική γλώσσα και µάλιστα αναµεµιγµένη µε κώδικα παρουσίασης. Αντί του εγχειρήµατος να φτιάξουµε µηχανές που να κατανοούν τη φυσική γλώσσα των εγγράφων του ιστού, στον Σηµασιολογικό Ιστό θα δηµοσιεύονται έγγραφα σε µορφή κατανοητή από τις µηχανές και προορισµένα για ανάγνωση απ' αυτές. Ο Σηµασιολoγικός Ιστός ξεκίνησε ως ένα όραµα για το µέλλον του τρέχοντος Ιστού. O Tim Berners-Lee αρχικά εξέφρασε το όραµα του Σηµασιολoγικού Ιστού ως έχει: (Burners-Lee & Fischetti, 1999) Έχω ένα όνειρο για τον Ιστό [στον οποίο οι υπολογιστές] γίνονται ικανοί να αναλύουν όλα τα δεδοµένα στον Ιστό το περιεχόµενο, τους υπερσυνδέσµους, τις συναλλαγές µεταξύ ανθρώπων και υπολογιστών. Ένας «Σηµασιολογικός Ιστός», που θα το κάνει αυτό δυνατό, δεν έχει ακόµα ξεπροβάλλει, αλλά όταν θα το κάνει, οι καθηµερινοί µηχανισµοί του εµπορίου, της γραφειοκρατίας και οι καθηµερινές ζωές µας θα χειρίζονται από µηχανές οµιλούµενες σε µηχανές. Οι «νοήµονες πράκτορες» που οι άνθρωποι διαλαλούσαν για αιώνες τελικά θα πραγµατωθούν. Η ανάπτυξη των τεχνολογιών που θα κάνουν τον Σ.Ι. πραγµατικότητα βρίσκεται σε εξέλιξη και αποτελεί ένα εκτενές πεδίο έρευνας, στο οποίο ηγείται το W3C και πρωταγωνιστικό ρόλο παίζει ο Tim Burners-Lee. -8-

17 2.3.1 Η Στοίβα του Σηµασιολoγικού Ιστού Τα πρότυπα, τα εργαλεία και οι γλώσσες που χρησιµοποιούνται (ή θα χρησιµοποιούνται) στον Σ.Ι. απεικονίζονται στη Στοίβα του Σηµασιολoγικού Ιστού (Εικόνα 2), η οποία ουσιαστικά απεικονίζει την αρχιτεκτονική του Σ.Ι. Κάθε στρώµα στη στοίβα εκµεταλλεύεται και χρησιµοποιεί τις δυνατότητες των κατωτέρων στρωµάτων. Εικόνα 2 Η Στοίβα του Σηµασιολoγικού Ιστού. Οι τεχνολογίες στη βάση της στοίβας χρησιµοποιούνται ήδη στον τρέχοντα Ιστό, αυτές στη µέση έχουν προτυποποιηθεί και έχουν γίνει αποδεκτές ενώ δεν είναι ακόµα ξεκάθαρο πώς θα υλοποιηθούν τα ανώτερα στρώµατα. Όλα τα στρώµατα της στοίβας πρέπει να υλοποιηθούν για την πλήρη εκπλήρωση του οράµατος του Σ.Ι. 5 Τεχνολογίες του Ιστού υπερκειµένου Οι τεχνολογίες στο πάτο της στοίβας χρησιµοποιούνται ήδη κατά κόρον στο κλασικό Ιστό και παρέχουν τη βάση για τον σηµασιολογικό. URI: παρέχει έναν καθολικό τρόπο για την µοναδική ταυτοποίηση των πόρων. Unicode: κωδικοποίηση που αναπαριστά κείµενο σε πολλαπλές γλώσσες. XML: η πανταχού παρούσα γλώσσα σήµανσης, που παρέχει µια επιφανειακή σύνταξη για δοµηµένα έγγραφα αλλά δεν επιβάλλει σηµασιολογικούς περιορισµούς στην σηµασία αυτών των εγγράφων. XML Schema: µια γλώσσα που επιβάλλει περιορισµούς στη δοµή των εγγράφων XML και επίσης επεκτείνει την XML µε τύπους δεδοµένων (datatypes). XML Namespaces: παρέχουν έναν τρόπο για τη χρήση ετικετών σήµανσης από πολλαπλές πηγές στο ίδιο έγγραφο αποφεύγοντας την σύγκρουση ονοµάτων

18 Προτυποποιηµένες τεχνολογίες του Σηµασιολoγικού Ιστού Τα µεσαία στρώµατα περιέχουν τεχνολογίες που έχουν προτυποποιηθεί και χρησιµοποιούνται για την δηµιουργία εφαρµογών Σ.Ι.: Resource Description Framework (RDF): ένα µοντέλο δεδοµένων για πόρους και τις σχέσεις µεταξύ τους. Παρέχει µια απλή σηµασιολογία για το µοντέλο αυτό, και τα µοντέλα αυτά µπορούν να αναπαρασταθούν σε µια σύνταξη XML (την RDF/XML). RDF Schema (RDFS): είναι ένα λεξιλόγιο για την περιγραφή ιδιοτήτων και κλάσεων πόρων RDF, µε µια σηµασιολογία για ιεραρχίες γενίκευσης τέτοιων ιδιοτήτων και κλάσεων. Web Ontology Language (OWL): επεκτείνει το RDFS προσθέτοντας λεξιλόγιο για τη περιγραφή ιδιοτήτων και κλάσεων: µεταξύ άλλων, σχέσεις µεταξύ κλάσεων (π.χ. disjointness, κλάσεις ξένες µεταξύ τους), πληθικότητα ιδιοτήτων, ισοδυναµία, περισσότερους τύπους ιδιοτήτων, χαρακτηριστικά ιδιοτήτων (π.χ. συµµετρία) και απαριθµηµένες κλάσεις. SPARQL: µια γλώσσα ερωτηµάτων (query language) για το RDF. Μπορεί να χρησιµοποιηθεί για την ερώτηση οποιωνδήποτε δεδοµένων βασισµένων στο RDF (δηλαδή και δηλώσεις RDFS και OWL). Μια τέτοια γλώσσα ερωτηµάτων είναι απαραίτητη για την ανάκτηση πληροφοριών από εφαρµογές Σ.Ι. Απραγµατοποίητες τεχνολογίες Σηµασιολoγικού Ιστού Τα ανώτερα στρώµατα περιλαµβάνουν τεχνολογίες που είτε δεν έχουν πραγµατοποιηθεί ακόµα είτε περιέχουν απλά ιδέες που πρέπει να υλοποιηθούν ώστε να πραγµατωθεί ο Σ.Ι. RIF ή SWRL: θα φέρουν υποστήριξη κανόνων. Αυτό είναι σηµαντικό για την περιγραφή σχέσεων που δεν µπορούν να περιγραφούν άµεσα µε τη χρήση περιγραφικής λογικής στην OWL. Κρυπτογραφία: είναι σηµαντική για να διασφαλίζουµε και να επαληθεύουµε ότι οι δηλώσεις προέρχονται από εµπιστευόµενη πηγή. Αυτό µπορεί να επιτευχθεί µε την χρήση κατάλληλων ψηφιακών υπογραφών για δηλώσεις RDF. Εµπιστοσύνη: η εµπιστοσύνη στις παραχθείσες δηλώσεις θα υποστηρίζεται από την (α) επαλήθευση ότι οι προτάσεις προέρχονται από εµπιστευόµενες πηγές και (β) στηριζόµενοι στη τυπική λογική κατά την παραγωγή νέας πληροφορίας. -10-

19 2.3.2 RDF To Resource Description Framework (RDF) είναι µια οικογένεια από προδιαγραφές που αρχικά σχεδιάστηκαν ως ένα µοντέλο δεδοµένων για µεταδεδοµένα, που πλέον χρησιµοποιείται ως µια γενική µέθοδος µοντελοποίησης πληροφορίας µέσω µιας ποικιλίας από φορµά σύνταξης. 6 Το µοντέλο δεδοµένων RDF βασίζεται στην ιδέα του να κάνουµε δηλώσεις για πόρους στην µορφή εκφράσεων υποκείµενο-κατηγόρηµα-αντικείµενο, που ονοµάζονται τριπλέτες στην ορολογία του RDF. Το υποκείµενο υποδηλώνει τον πόρο ενώ το κατηγόρηµα υποδηλώνει χαρακτηριστικά γνωρίσµατα του πόρου και εκφράζει µια σχέση µεταξύ του υποκειµένου και του αντικειµένου. Για παράδειγµα, ένας τρόπος για ν' αναπαραστήσουµε την πρόταση «Ο Anakin Skywalker είναι ο πατέρας του Luke Skywalker»είναι η τριπλέτα της Εικόνας 3: Το RDF είναι ένα αφηρηµένο µοντέλο µε πολλά φορµά σειριοποίησης και έτσι ο συγκεκριµένος τρόπος που κωδικοποιείται ένας πόρος ποικίλει από φορµά σε φορµά. Φορµά σειριοποίησης Δυο κοινά φορµά σειριοποίησης είναι σε χρήση. Το πρώτο είναι ένα XML φορµά που ονοµάζεται απλά RDF (ή RDF/XML) και έχει MIME τύπο application/rdf+xml. Η προηγούµενη τριπλέτα θα µπορούσε να κωδικοποιηθεί σε RDF/XML ως εξής: <rdf:rdf xmlns:rdf=" xmlns:rel=" <rdf:description rdf:about=" <rel:fatherof Εικόνα 3 Παράδειγµα τριπλέτας RDF. Πηγή: rdf:resource="

20 </rdf:description> </rdf:rdf> Το W3C έχει επίσης εισαγάγει το Notation-3 (ή απλά N3) ως µια µη XML σειριοποίηση µοντέλων RDF σχεδιασµένη να είναι ευκολότερο να γραφτεί µε το χέρι και σε κάποιες περιπτώσεις ευκολότερη στην κατανόηση. Επειδή βασίζεται σε µια σηµειογραφία βασισµένη σε στηλοθέτες (tabular notation) κάνει τις κωδικοποιηµένες τριπλέτες πιο εύκολα αναγνωρίσιµες σε σύγκριση µε τη σειριοποίηση σε XML. Η προηγούµενη τριπλέτα θα µπορούσε να κωδικοποιηθεί σε Ν3 ως sw: rel: < sw:anakinskywalker rel:fatherof sw:lukeskywalker RDFS Το RDFS ή RDF Schema είναι µια επεκτάσιµη γλώσσα αναπαράστασης γνώσης που παρέχει βασικά στοιχεία για την περιγραφή οντολογιών, που ονοµάζονται και λεξιλόγια RDF. Τα βασικά συστατικά του RDFS περιέχονται και στην πιο εξελιγµένη γλώσσα οντολογιών OWL. Μεταξύ άλλων ορίζονται οι δοµές: rdfs:class: µας επιτρέπει να ορίζουµε έναν πόρο ως µια κλάση άλλων πόρων. Με τη χρήση της ιδιότητας rdf:type δηλώνουµε ότι ένας πόρος ανήκει σε µια κλάση. Για παράδειγµα, µπορούµε να δηλώσουµε ότι ο Luke Skywalker είναι ένα ιππότης Jedi ως εξής: sw:lukeskywalker rdf:type sw:jediknight rdfs:subclassof: µας επιτρέπει να κατασκευάζουµε ιεραρχίες κλάσεων. Για παράδειγµα µπορούµε να δηλώσουµε ότι κάθε Protocol droid, όπως ο C- 3PO, είναι ένα droid, ως εξής: sw:protocoldroid rdf:subclassof sw:droid rdfs:subpropertyof: ιεραρχίες ιδιοτήτων µπορούν να κατασκευαστούν από µία ή περισσότερες δηλώσεις ότι µια ιδιότητα είναι υποιδιότητα µιας ή περισσοτέρων ιδιοτήτων. Για παράδειγµα, αν η ιδιότητα sw:servesmaster οριστεί υποϊδιότητα της sw:hasmaster, δεδοµένης της δήλωσης sw:c3po sw:servesmaster sw:anakinskywalker, µπορεί να συµπεραθεί ότι sw:c3po sw:hasmaster sw:anakinskywalker. -12-

21 rdfs:domain: δηλώνει για µια ιδιότητα, rdf:property, τη κλάση του υποκειµένου σε µια τριπλέτα µε την ιδιότητα αυτή στη θέση του κατηγορήµατος. rdfs:range: δηλώνει για µια ιδιότητα τη κλάση ή τον τύπο δεδοµένων του αντικειµένου σε µια τριπλέτα µε την ιδιότητα αυτή στη θέση του κατηγορήµατος. Για παράδειγµα µε τις παρακάτω δηλώσεις εκφράζουµε ότι η ιδιότητα «µαθητευόµενος του ιππότη Jedi» έχει πεδίο ορισµού τους µαθητευόµενους ιππότες Jedi (ονόµατι Jedi Padawans) και πεδίο τιµών τους ιππότες Jedi: sw:apprenticeofjediknight rdfs:domain sw:jedipadawan sw:apprenticeofjediknight rdfs:range sw:jediknight Έτσι όταν δούµε τη τριπλέτα sw:anakinskywalker sw:apprenticeofjediknight sw:obiwankenobi µπορούµε να συµπεραίνουµε (infer) ότι ο Anakin Skywalker είναιένας µαθητευόµενος ιππότης Jedi ενώ ο Obi-Wan Kenobi είναι ένας ιππότης Jedi OWL Η Web Ontology Language (OWL) είναι µια οικογένεια από γλώσσες αναπαράστασης γνώσης για τη συγγραφή οντολογιών 7. Είναι και αυτή σύσταση του W3C. Η οικογένεια γλωσσών βασίζεται σε δυο σηµασιολογίες: Η σηµασιολογία της OWL Lite και της OWL DL βασίζεται στις Περιγραφικές Λογικές (Description Logics), που έχουν ελκυστικές και καλά κατανοητές υπολογιστικές ιδιότητες, ενώ η OWL Full χρησιµοποιεί ένα πρωτότυπο σηµασιολογικό µοντέλο που σκοπεύει να παρέχει συµβατότητα µε το RDF Schema. Οι οντολογίες OWL συνήθως σειριοποιούνται σε σύνταξη RDF/XML. Οι τρεις υπογλώσσες της OWL 8 Η OWL παρέχει τρεις υπογλώσσες που αυξάνουν σταδιακά σε εκφραστικότητα: H OWL Lite υποστηρίζει τους χρήστες που χρειάζονται κυρίως µια ιεραρχία ταξινόµησης και απλούς περιορισµούς. Για παράδειγµα, ενώ υποστηρίζει

22 περιορισµούς πληθικότητας (cardinality), επιτρέπει µόνο τιµές πληθικότητας 0 και 1. Η OWL Lite έχει χαµηλότερη τυπική πολυπλοκότητα από την OWL DL. Η OWL DL υποστηρίζει τους χρήστες που θέλουν την µέγιστη εκφραστικότητα διατηρώντας την υπολογιστική πληρότητα (όλα τα συµπεράσµατα είναι εγγυηµένα υπολογίσιµα) και αποφασισιµότητα (decidability, όλοι οι υπολογισµοί θα τελιώσουν σε πεπερασµένο χρόνο). Η OWL DL περιέχει όλες τις δοµές της γλώσσας OWL, αλλά µπορούν να χρησιµοποιηθούν µόνο υπό κάποιους περιορισµούς (για παράδειγµα, ενώ µια κλάση µπορεί να είναι υποκλάση πολλών κλάσεων, µια κλάση δεν µπορεί να είναι στιγµιότυπο µια άλλης κλάσης) Η OWL DL ονοµάζεται έτσι λόγω της αντιστοιχίας της µε τις περιγραφικές λογικές, ένα πεδίο έρευνας που έχει µελετήσει τη λογική που σχηµατίζει τα τυπικά θεµέλια της OWL. Η OWL Full προορίζεται για χρήστες που θέλουν τη µέγιστη εκφραστικότητα και τη συντακτική ελευθερία του RDF χωρίς υπολογιστικές εγγυήσεις. Για παράδειγµα, στην OWL Full µια κλάση µπορεί να µεταχειριστεί ταυτόχρονα ως µια συλλογή από άτοµα και σαν άτοµο. Η OWL Full επιτρέπει σε µια οντολογία να επεκτείνει τη σηµασία του προκαθορισµένου λεξιλογίου (RDF ή OWL). Είναι απίθανο κάποιο λογισµικό εξαγωγής συµπερασµάτων (reasoning) να είναι ικανό να υποστηρίξει πλήρη εξαγωγή συµπερασµάτων για κάθε χαρακτηριστικό της OWL Full. Κάθε µια από τις υπογλώσσες αυτές είναι µια επέκταση του απλούστερου προκατόχου της, και στο τι µπορεί να εκφραστεί έγκυρα και σε τι µπορεί να γίνει έγκυρη εξαγωγή συµπερασµάτων. Ισχύουν οι παρακάτω σχέσεις, αλλά όχι οι αντίστροφες τους: Κάθε έγκυρη οντολογία OWL Lite είναι µια νόµιµη oντολογία OWL DL. Κάθε έγκυρη οντολογία OWL DL είναι µια νόµιµη oντολογία OWL Full. Κάθε έγκυρη συµπέρασµα της OWL Lite είναι ένα έγκυρο συµπέρασµα της OWL DL. Κάθε έγκυρη συµπέρασµα της OWL DL είναι ένα έγκυρο συµπέρασµα της OWL Full. Σύντοµη περιγραφή της OWL DL Η OWL Lite χρησιµοποιεί µόνο κάποια από τα χαρακτηριστικά της OWL και έχει περισσότερους περιορισµούς στη χρήση τους απ' ό, τι η OWL DL και η OWL Full. Δεν θ' αναφερθούµε στους περιορισµούς της OWL Lite αλλά απευθείας στα -14-

23 χαρακτηριστικά της OWL DL, επειδή είναι αυτή που τελικά επιλέχθηκε για το σύστηµα. Χαρακτηριστικά σχετικά µε το RDF Schema Η OWL περιλαµβάνει τα παρακάτω χαρακτηριστικά σχετικά µε το RDFS: owl:class: ορίζει µια οµάδα από άτοµα που ανήκουν µαζί επειδή µοιράζονται κάποιες ιδιότητες. Οι κλάσεις όπως αναφέραµε οργανώνονται σε µια ιεραρχία µε τη χρήση της ιδιότητας rdfs:subclassof. Υπάρχει µια ενσωµατωµένη πιο γενική κλάση ονόµατι owl:thing που είναι η κλάση όλων των ατόµων και είναι υπερκλάση όλων των των κλάσεων OWL. Υπάρχει επίσης µια ενσωµατωµένη πιο συγκεκριµένη κλάση ονόµατι owl:nothing που είναι η κλάση που δεν έχει στιγµιότυπα και είναι υποκλάση όλων των κλάσεων OWL. owl:individual: τα άτοµα είναι στιγµιότυπα των κλάσεων, και ιδιότητες µπορούν να χρησιµοποιηθούν για συσχετίσεις µεταξύ τους. owl:objectproperty, owl:datatypeproperty: Η OWL κάνει διάκριση µεταξύ των ιδιοτήτων που παίρνουν ένα στιγµιότυπο µιας κλάσης ως αντικείµενο και µεταξύ αυτών που παίρνουν µια τιµή από έναν τύπο δεδοµένων. Οι owl:objectproperty και owl:datatypeproperty είναι υποκλάσεις της RDF κλάσης rdf:property. rdfs:subproperty, rdfs:domain, rdfs:range: οι προαναφερθείσες αυτές δοµές του RDF Schema για τις ιδιότητες, περιλαµβάνονται και στην OWL. Ισότητα και ανισότητα owl:equivalentclass: Δυο κλάσεις µπορεί να δηλωθούν ισοδύναµες. Ισοδύναµες κλάσεις έχουν τα ίδια στιγµιότυπα. owl:equivalentproperty: Δυο ιδιότητες επίσης µπορεί να δηλωθούν ισοδύναµες. owl:sameas: Δυο άτοµα µπορεί να δηλωθεί ότι είναι το ίδιο, έτσι µπορούµε να έχουµε πολλά διαφορετικά ονόµατα για το ίδιο άτοµο. Παράδειγµα η δήλωση sw:anakinskywalker owl:sameas sw:darthvader. owl:differentfrom: παροµοίως ένα άτοµο µπορεί να δηλωθεί διάφορο από άλλα άτοµα. Έτσι αν µια ιδιότητα δηλωθεί συναρτησιακή (functional, ακολουθεί παρακάτω) και για ένα άτοµο έχει αντικείµενα δυο άτοµα που είναι -15-

24 µεταξύ τους διάφορα, θα έχουµε αντίφαση. Αν όµως δεν είναι άµεσα δηλωµένα διάφορα, ένας reasoner θα υποθέσει ότι πρόκειται για το ίδιο άτοµο! owl:alldifferent: ένας αριθµός από άτοµα µπορεί να δηλωθούν αµοιβαίως διάφορα σε µια δήλωση AllDifferent. Χαρακτηριστικά ιδιοτήτων owl:inverseof: Μια ιδιότητα µπορεί να δηλωθεί ως η αντίστροφη µιας άλλης. Για παράδειγµα, η προαναφερθείσα sw:hasmaster µπορεί να οριστεί ως η αντίστροφη της sw:masterof, έτσι µπορεί να βγει το συµπέρασµα ότι sw:anakinskywalker sw:masterof sw:c3po, δεδοµένου ότι sw:c3po sw:hasmaster sw:anakinskywalker. owl:transitiveproperty:μια ιδιότητα µπορεί να δηλωθεί µεταβατική. owl:symmetricproperty:οι ιδιότητες µπορούν να οριστούν συµµετρικές. Για παράδειγµα, αν η ιδιότητα rel:friendof είναι συµµετρική, sw:lukeskywalker rel:friendof sw:hansolo συνεπάγεται και sw:hansolo rel:friendof sw:lukeskywalker. owl:functionalproperty: Οι ιδιότητες µπορούν να δηλωθούν ότι έχουν µοναδική τιµή για ένα άτοµο (µπορεί να µην έχουν και καµία τιµή). Η owl:functionalproperty είναι µια συντόµευση του να δηλώσουµε ότι η µέγιστη πληθικότητα της ιδιότητας είναι 1 και η ελάχιστη 0. owl:inversefunctionalproperty: αν µια ιδιότητα δηλωθεί inverse functional σηµαίνει ότι η αντίστροφή της είναι functional. Περιορισµοί ιδιοτήτων owl:allvaluesfrom: O περιορισµός (restriction) owl:allvaluesfrom δηλώνεται σε µια ιδιότητα, σε σχέση µε µια κλάση. Σηµαίνει ότι η ιδιότητα αυτή της κλάσης Α παίρνει όλες τις τιµές της από κλάση Β. Έτσι αν δούµε µια δήλωση της ιδιότητας αυτής µε αντικείµενο ένα στιγµιότυπο της κλάσης Β, συµπεραίνουµε ότι το υποκείµενο ανήκει στη κλάση Α. owl:somevaluesfrom: Και αυτός ο περιορισµός δηλώνεται σε µια ιδιότητα, σε σχέση µε µια κλάση Α. Απαιτεί για την ιδιότητα αυτή, τα στιγµιότυπα της κλάσης Α να έχουν µια τουλάχιστον τιµή από µια κλάση Β. Για παράδειγµα, για να προαχθεί ένας ιππότης Jedi (JediKnight) σε αφέντη Jedi (JediMaster) πρέπει να έχει εκπαιδεύσει τουλάχιστον έναν ιππότη Jedi. -16-

25 Δηλαδή απαιτείται κάθε στιγµιότυπο της κλάσης sw:jedimaster να έχει τουλάχιστον µια τιµή από την κλάση sw:jediknight, για την ιδιότητα sw:trained. owl:hasvalue:για µια κλάση µπορεί να απαιτείται µια ιδιότητα να έχει ένα συγκεκριµένο άτοµο ως τιµή. Για παράδειγµα, µπορούµε να απαιτήσουµε οι ιππότες Jedi να υπηρετούν την Φωτεινή Πλευρά της Δύναµης, δηλώνοντας τον περιορισµό owl:hasvalue sw:lightsideoftheforce για την ιδιότητα sw:servessideofforce, στη κλάση sw:jediknight. Περιορισµένη πληθικότητα owl:mincardinality: η πληθικότητα δηλώνεται σε µια ιδιότητα σε σχέση µια συγκεκριµένη κλάση. Αν δηλώσουµε ότι η ιδιότητα sw:hasmaster έχει ελάχιστη πληθικότητα 1 για την κλάση sw:droid, σηµαίνει ότι ένα Droid πρέπει να έχει τουλάχιστον έναν αφέντη. Μια owl:mincardinality 0 για µια ιδιότητα και µια κλάση σηµαίνει ότι η ιδιότητα αυτή είναι προαιρετική για τη κλάση αυτή. owl:maxcardinality: δηλώνει το µέγιστο πλήθος τιµών που µπορεί να πάρει µια ιδιότητα για µια κλάση. Για παράδειγµα, µπορούµε να δηλώσουµε ότι ένας αφέντης Sith έχει µέχρι έναν µαθητευόµενο Sith. owl:cardinality: Παρέχεται ως ευκολία όταν είναι χρήσιµο να δηλώσουµε ότι µια ιδιότητα για µια κλάση έχει ταυτόχρονα mincardinality n και maxcardinality n ή ταυτόχρονα mincardinality n and maxcardinality n, δηλαδή όταν θέλουµε να δηλώσουµε τον ακριβή αριθµό τιµών που παίρνει µια ιδιότητα για µια κλάση. Boolean συνδυασµοί κλάσεων Η OWL DL (και η OWL Full) επιτρέπει αυθαίρετους συνδυασµούς κλάσεων και περιορισµών: owl:unionof, owl:complementof, και owl:intersectionof για να δηλώνουµε µια κλάση ως τη ένωση άλλων δυο, την τοµή άλλων δυο ή το συµπλήρωµα µιας άλλης αντίστοιχα. Απαριθµήσιµες κλάσεις H owl:oneof µας επιτρέπει να περιγράφουµε κλάσεις απαριθµώντας τ' αντικείµενα που αποτελούν τη κλάση. Τα µέλη της κλάσης είναι αποκλειστικά το σύνολο των απαριθµηµένων ατόµων: ούτε περισσότερα ούτε λιγότερα. Για παράδειγµα, µπορούµε -17-

26 να δηλώσουµε ότι η κλάση sw:sith των Siths αποτελείται από τον sw:darthvader και τον sw:darthsidious 9. Ξένες κλάσεις Η owl:disjointwith µας επιτρέπει να δηλώσουµε κλάσεις να είναι ξένες µεταξύ τους. Για παράδειγµα, η κλάση sw:jediknight των ιπποτών Jedi µπορεί να δηλωθεί ως ξένη προς την sw:sith, την κλάση των Siths. Έτσι ένα άτοµο δεν θα µπορεί να δηλώνεται ως Jedi και Sith ταυτόχρονα. Τύποι δεδοµένων Η OWL χρησιµοποιεί τους περισσότερους απο τους ενσωµατωµένους τύπους δεδοµένων (datatypes) του XML Schema. Αναφορές στους τύπους αυτούς γίνονται µε το URI reference του κάθε τύπου, στο namespace Οι παρακάτω τύποι δεδοµένων συνιστώνται για χρήση µε την OWL: xsd:string xsd:normalizedstring xsd:boolean xsd:decimal xsd:float xsd:double xsd:integer xsd:nonnegativeinteger xsd:positiveinteger xsd:nonpositiveinteger xsd:negativeinteger xsd:long xsd:int xsd:short xsd:byte xsd:unsignedlong xsd:unsignedint xsd:unsignedshort xsd:unsignedbyte xsd:hexbinary xsd:base64binary xsd:datetime xsd:time xsd:date xsd:gyearmonth xsd:gyear xsd:gmonthday xsd:gday xsd:gmonth xsd:anyuri xsd:token xsd:language xsd:nmtoken xsd:name xsd:ncname Οι παραπάνω τύποι δεδοµένων συν το rdfs:literal, αποτελούν τους ενσωµατωµένους τύπους δεδοµένων της OWL. Annotation Properties Η OWL DL επιτρέπει επισηµειώσεις (annotations) σε κλάσεις, ιδιότητες και headers οντολογιών αλλά µόνο υπό τους εξής περιορισµούς 10. Τα σύνολα των object properties, datatype properties, annotation properties και ontology properties είναι αµοιβαίως αποκλειόµενα. Για παράδειγµα, µια 9 στα πλαίσια της αυθεντικής τριλογίας του Star Wars :)

27 owl:datatypeproperty δεν µπορεί να είναι ταυτόχρονα και owl:annotationproperty. Οι annotation properties πρέπει να έχουν µια άµεση δηλωµένη τριπλέτα της µορφής: AnnotationPropertyID rdf:type owl:annotationproperty Οι annotation properties δεν πρέπει να χρησιµοποιούνται σε αξιώµατα ιδιοτήτων. Έτσι δεν µπορούµε να ορίσουµε υποϊδιότητες µιας annotation property. Το αντικείµενο µιας annotation property πρέπει να είναι ένα literal δεδοµένων, ένα URI reference ή ένα άτοµο. Υπάρχουν πέντε προκαθορισµένες annotation properties στη OWL, οι owl:versioninfo, rdfs:label, rdfs:comment, rdfs:seealso και rdfs:isdefinedby. Header οντολογίας Ένα έγγραφο που περιγράφει µια οντολογία συνήθως περιέχει πληροφορία και για την ίδια την οντολογία. Μια οντολογία είναι ένας πόρος οπότε µπορεί να περιγραφεί µε χρήση ιδιοτήτων από άλλα namespaces. Οι δηλώσεις που αποτελούν τον header της οντολογίας συνήθως βρίσκεται κοντά στην αρχή του εγγράφου RDF/XML. Η γραµµή <owl:ontology rdf:about=""> δηλώνει ότι το µπλοκ περιγράφει τη τρέχουσα οντολογία. Πιο συγκεκριµένα, δηλώνει ότι το τρέχον URI βάσης ταυτοποιεί ένα στιγµιότυπο της κλάσης owl:ontology. Ένα header οντολογίας µπορεί να δείχνει ως έχει: <owl:ontology rdf:about=""> <owl:versioninfo>v /02/26 12:56:51 mdean</owl:versioninfo> <rdfs:comment>an example ontology</rdfs:comment> <owl:imports rdf:resource=" </owl:ontology> Εισαγωγή οντολογίας Μια δήλωση owl:imports αναφέρεται σε µια άλλη οντολογία OWL που περιέχει ορισµούς των οποίων η σηµασία θεωρείται κοµµάτι της σηµασίας της εισάγουσας οντολογίας. Κάθε αναφορά αποτελείται από ένα URI που καθορίζει από που θα εισαχθεί η οντολογία. Η owl:imports είναι µια µεταβατική ιδιότητα µε τη κλάση -19-

28 owl:ontology στο ΠΟ (πεδίο ορισµού) και στο ΠΤ (πεδίο τιµων) της: αν η οντολογία A εισάγει τη Β και η Β εισάγει τη Γ, τότε η Α εισάγει και την Β και τη Γ. Πληροφορίες έκδοσης owl:versioninfo:είναι µια owl:annotationproperty που γενικά έχει ως αντικείµενο ένα string που δίνει πληροφορίες για αυτήν την έκδοση. Αν και συνήθως χρησιµοποιείται σε οντολογίες, µπορεί να χρησιµοποιηθεί σε κάθε δοµή OWL, π.χ. σε µια κλάση. owl:priorversion:είναι µια owl:ontology και ταυτοποιεί µια προηγούµενη έκδοση της οντολογίας. Μπορεί να χρησιµοποιηθεί από ένα λογισµικό για την οργάνωση των οντολογιών µε βάση την έκδοση. οwl:backwardcompatiblewith: ταυτοποιεί µια προηγούµενη έκδοση της οντολογίας και δηλώνει ότι είναι προς τα πίσω συµβατή µε αυτήν. owl:incompatiblewith: ταυτοποιεί µια προηγούµενη έκδοση της οντολογίας και δηλώνει ότι δεν είναι προς τα πίσω συµβατή µε αυτήν. -20-

29 3 Απαιτήσεις Ο στόχος της πτυχιακής εργασίας είναι η σχεδίαση και υλοποίηση ενός συστήµατος διαχείρισης περιεχοµένου για χρήση στον Σηµασιολoγικό Ιστό. Ένα σύστηµα διαχείρισης περιεχοµένου (content management system, CMS) είναι ένα εργαλείο που επιτρέπει σε ένα σύνολο (κεντραρισµένου) τεχνικού και (αποκεντραρισµένου) µη τεχνικού προσωπικού να δηµιουργεί, επεξεργάζεται, διαχειρίζεται και τελικά να δηµοσιεύει (σ έναν αριθµό από φορµά) µια ποικιλία περιεχοµένου (όπως κείµενο, γραφικά, βίντεο, έγγραφα κλπ.), ενώ είναι περιορισµένο από ένα κεντραρισµένο σύνολο από κανόνες, διαδικασίες και ροές εργασίας που εξασφαλίζουν συνεκτικό, ελεγµένο περιεχόµενο Χειρισµός REST αρχιτεκτονική Βασικό χαρακτηριστικό του συστήµατος θα είναι ότι θ ακολουθεί το αρχιτεκτονικό στυλ REST, δηλαδή θα είναι «RESTful»: Η φαινοµενική κατάσταση και η λειτουργικότητα του συστήµατος θα διαιρούνται σε πόρους. Κάθε πόρος θα είναι µοναδικά ταυτοποιούµενος από ένα URI. Ο χειρισµός των πόρων θα γίνεται µέσω του πρωτοκόλλου HTTP το οποίο ορίζει µια οµοιόµορφη διεπαφή η οπoία αποτελείται από ένα περιορισµένο σύνολο καλά ορισµένων λειτουργιών (well-defined operations), από τις οποίες οι απολύτως απαραίτητες είναι οι GET, POST, PUT και DELETE. 12 ένα περιορισµένο σύνολο τύπων περιεχοµένου, τους τύπους MIME

30 3.1.2 Χειρισµός πληροφοριακών πόρων Tο πρώτο είδος πόρων που θέλουµε το σύστηµα να χειρίζεται είναι οι πληροφοριακοί. Ο χειρισµός αυτών θα πρέπει να γίνεται µε έναν «RESTful» τρόπο, οπότε να αποκρίνεται στις αιτήσεις HTTP µε τον εξής τρόπο: GET URI : θα επιστρέφεται µια αναπαράσταση του ΠΠ µε αυτό το URI. Ένας πόρος µπορεί να έχει πολλές αναπαραστάσεις, οπότε θα πρέπει να υποστηρίζεται Content Negotiation. POST URI <entity> : Αποδοχή και αποθήκευση της υποβεβληµένης αναπαραστάσης entity, αν είναι σε σωστή µορφή, ως ένα νέο κοµµάτι του ΠΠ αυτού. POST URI <entity> : Αν υπάρχει ήδη πόρος µε αυτό το URI, αντικατάσταση της τρέχουσας πληροφορίας µε αυτήν που περιέχεται στην entity. Αν δεν υπάρχει, δηµιουργία του. DELETE URI: Διαγραφή όλων των αναπαραστάσεων του πόρου από το σύστηµα «Χειρισµός» µη πληροφοριακών πόρων Προφανώς δεν µπορούµε να «χειριστούµε» µη πληροφοριακούς πόρους. Αντ αυτού όµως µπορούµε να χειριστούµε περιγραφές τους. Αυτή είναι µια από τις βασικές ιδέες του συστήµατος. Δεν χειριζόµαστε ούτε εγγραφές ούτε αντικείµενα, αλλά πληροφοριακούς πόρους περιγραφής, για µη ΠΠ. Οι περιγραφές αυτές πρέπει να παρέχονται τόσο σε µορφή κατανοητή από τους ανθρώπους (π.χ. XHTML) όσο σε µορφή κατανοητή από µηχανές, δηλαδή σε RDF. Θα µπορούσαµε να διατηρούµε ξεχωριστά τις περιγραφές των µη πληροφοριακών πόρων µεταξύ τους, αλλά εισάγοντας τις σε µια οντολογία OWL µπορούµε να έχουµε όλα τα πλεονεκτήµατα της χρήσης οντολογίων, όπως το reasoning. Μια οντολογία είναι και αυτή ένας πληροφοριακός πόρος. Έτσι στο URI της οντολογίας θ ανακτούµε µια αναπαράσταση όλης της οντολογίας, ενώ στo URI ενός πόρου περιγραφής θ ανακτούµε την αναπαράσταση της περιγραφής ενός άλλου, περιγραφόµενου πόρου, δηλαδή τις δηλώσεις που έχουν εκείνον τον πόρο ως υποκείµενο τους. -22-

31 Με τη χρήση οντολογιών εκτός από απλά περιγραφές πόρων, µπορούµε να έχουµε περιγραφές κλάσεων και ιδιοτήτων. Όλες τις περιγραφές µη πληροφοριακών πόρων θα τις χειριζόµαστε µε τον ίδιο «RESTful» τρόπο όπως τους υπόλοιπους ΠΠ. Όπως όµως υπάρχουν περιγραφές για µη ΠΠ µπορούν να υπάρχουν και περιγραφές για ΠΠ! Παράδειγµα ιδιοτήτων σε τέτοιες περιγραφές είναι ο συντάκτης µιας ιστοσελίδας, η ηµεροµηνία δηµοσίευσης της κλπ. Μια τέτοια περιγραφή περιέχει ουσιαστικά µεταπληροφορία για τον ΠΠ, ενώ η περιγραφή ενός µη ΠΠ περιέχει δεδοµένα γι αυτόν. Επίσης όπως υπάρχουν κλάσεις για µη ΠΠ υπάρχουν και για ΠΠ, για παράδειγµα Ιστοσελίδα, Εικόνα κλπ Χειρισµός ανά τύπο / κλάση Θα πρέπει να δίνεται η δυνατότητα ο χειρισµός των πόρων της ίδιας κλάσης να γίνεται µε τον ίδιο τρόπο, ώστε να αποφεύγουµε να ορίζουµε τρόπο χειρισµού για κάθε πόρο ξεχωριστά Φόρµες επεξεργασίας πόρων Συνήθως ένας χρήστης διαχειρίζεται την πληροφορία ενός πληροφοριακού συστήµατος Ιστού µέσω φορµών ιστού (web forms), αντί να ετοιµάσει χειροκίνητα την αναπαράσταση ενός πόρου και να εκτελέσει ενέργειες POST/PUT. Έτσι θα πρέπει να υπάρχουν ΠΠ που θ αποτελούν φόρµες για την δηµιουργία και επεξεργασία άλλων πόρων. 3.2 Συστατικά Ανεξαρτησία διεπαφής συστατικών της υλοποίησης O χρήστης θα διαχειρίζεται το νοητό µοντέλο του συστήµατος εκτελώντας µεθόδους HTTP στους πόρους από τους οποίους αυτό αποτελείται. Αυτή είναι η εξωτερική άποψη του συστήµατος µας, η διεπαφή του. Εσωτερικά µπορούµε να δοµήσουµε το σύστηµα µας όπως θέλουµε. Η διεπαφή του συστήµατος δεν θα πρέπει να εξαρτάται από τη συγκεκριµένη γλώσσα προγραµµατισµού και πλατφόρµα στην µεριά του εξυπηρέτη. Θα πρέπει επίσης να είναι δυνατόν η όλη λειτουργικότητα του συστήµατος να µπορεί να µεταφερθεί σε µια άλλη πλατφόρµα χωρίς αλλαγή της διεπαφής. -23-

32 3.2.2 Αρθρωτή και επεκτάσιµη αρχιτεκτονική Μια λειτουργική µονάδα (module) είναι ένα αυτο-περιεχόµενο συστατικό ενός συστήµατος, που έχει µια καλά ορισµένη διεπαφή προς τα άλλα συστατικά. Κάτι είναι αρθρωτό (modular) όταν περιέχει ή χρησιµοποιεί modules που µπορούν να ανταλλαχθούν ως µονάδες χωρίς αποσυναρµολόγηση του module 13. Το σύστηµα µας θα πρέπει να είναι αρθρωτό και επεκτάσιµο. Θα πρέπει να οριστούν τα συστατικά του και να επιτρέπεται ο διαµοιρασµός τους Χειρισµός των ρυθµίσεων και των συστατικών του συστήµατος µέσω της διεπαφής Ιστού Η ρύθµιση πολλών συστηµάτων διαχείρισης περιεχοµένου γίνεται συνήθως µε χρήση αρχείων ρυθµίσεων και απαιτούν πολλές φορές πρόσβαση (π.χ. µε FTP) στον εξυπηρέτη και τη διακοπή και επανεκκίνηση του συστήµατος. Με παρόµοιο τρόπο γίνεται συνήθως και η προσθήκη νέων συστατικών ή τροποποίηση των υπαρχόντων. Το σύστηµα µας θα πρέπει να καθιστά δυνατή την επεξεργασία των ρυθµίσεων και των συστατικών µέσω της διεπαφής Ιστού µε τον ίδιο «RESTful» τρόπο, µέσω ΠΠ ελέγχου. Επειδή τέτοιοι πόροι µπορεί να µην είναι δυνατόν να είναι πάντα ανεξάρτητοι της υλοποίησης, θα πρέπει τουλάχιστον να είναι σαφώς διαχωρισµένοι από τους υπόλοιπους Διαµοιρασµός συστατικών του συστήµατος Θα πρέπει να υπάρχει ένα τρόπος διαµοιρασµού του συστήµατος και των συστατικών του, για εγκατάσταση ή αναβάθµιση. Όπως πάντα, µπορούµε να το πετύχουµε µε τον ίδιο «RESTful» τρόπο. Θα πρέπει να υπάρχουν: Πόροι πακέτων συστατικών: Αυτοί µπορεί να υπάρχουν σε διάφορες τοποθεσίες απ όπου µπορεί ν ανακτηθεί µια αναπαράσταση τους. Είναι αναγκαστικά εξαρτώµενοι από την υλοποίηση. Φυσικά θα πρέπει να υπάρχουν πακέτα µιας ολόκληρης εφαρµογής. Πόροι ελέγχου συστατικών: Αντί ο χρήστης να κατεβάσει τα πακέτα συστατικών, να σταµατήσει το σύστηµα και να εγκαταστήσει τα συστατικά στο σύστηµα αρχείων του εξυπηρέτη, µπορούν να υπάρχουν πόροι ελέγχου των συστατικών, ώστε µε µια αίτηση POST ή PUT στον πόρο ελέγχου να

33 τροποποιείται το εσωτερικό συστατικό. Προφανώς και αυτοί είναι εξαρτώµενοι από την υλοποίηση. Θα πρέπει να υπάρχει και ένας πόρος ελέγχου ολόκληρης της εφαρµογής, έτσι ώστε είναι δυνατή η εξαγωγή αντιγράφων ασφαλείας (backup) ενός συστήµατος, η επαναφορά του (restoration) και η αναβάθµιση του µέσω της διεπαφής ιστού Σύστηµα εκδόσεων συστατικών Για τον διαµοιρασµό των συστατικών θα πρέπει να υπάρχει ένα σύστηµα εκδόσεων, ώστε να ξέρουµε τι εκδόσεις υπάρχουν εγκατεστηµένες στο σύστηµα µας και αν ένα πακέτο συστατικού περιέχει µια νεότερη έκδοση από αυτή που έχουµε. Αυτό µπορεί να επιτρέψει και αυτοµατοποιηµένη αναβάθµιση Προστασία πόρων του συστήµατος Πόροι και συστατικά (οπότε και πόροι ελέγχου συστατικών) απαραίτητα για τη λειτουργία του συστήµατος θα πρέπει να προστατεύονται από διαγραφή και τροποποίηση. Παράλληλα θα πρέπει να δίνεται στον χρήστη η δυνατότητα να υπερβεί (override) ρυθµίσεις. Επίσης, επειδή ο Σηµασιολογικός Ιστός είναι ένα ανοιχτό σύστηµα όπου οποιοσδήποτε µπορεί να κάνει δηλώσεις για οτιδήποτε, θα πρέπει να επιτρέπεται η προσθήκη επιπλέον δηλώσεων για πόρους του συστήµατος, όσο όµως δεν αναιρούν τη συνέπεια της οντολογίας Έλεγχος πρόσβασης Η ύπαρξη µηχανισµών πιστοποίησης (authentication) και εξουσιοδότησης (authorization) χρηστών και γενικά ελέγχου πρόσβασης (access control) είναι απαραίτητη σε κάθε εφαρµογή ιστού. Επειδή όµως ο έλεγχος πρόσβασης είναι ένα µεγάλο κοµµάτι από µόνος του, δεν θα συµπεριληφθεί στις απαιτήσεις αυτής της πτυχιακής εργασίας. -25-

34 4 Σχεδίαση Στο κεφάλαιο αυτό θα σχεδιάσουµε ένα σύστηµα που πληροί τις απαιτήσεις του προηγούµενου κεφαλαίου χωρίς όµως να αναφερθούµε σε κάποια συγκεκριµένη υλοποίηση. Το σύστηµα θα ονοµαστεί π 2 (πι τετράγωνο), από τους πληροφοριακούς πόρους: πληροφοριακοί πόροι = ππ = π Modules Θ' αρχίσουµε την σχεδίαση κάπως «ανάποδα», προσπαθώντας να αποφασίσουµε για τη µορφή των αυτοπεριεχόµενων συστατικών του συστήµατος. Θα ονοµάσουµε την µονάδα διαµοιρασµού συστατικών του συστήµατος, module Οι δυο όψεις του συστήµατος Θα πρέπει να κατανοήσουµε ότι η εξωτερική διεπαφή του συστήµατος είναι αυτή που διαιρείται σε πόρους, ενώ η εσωτερική σε συστατικά. Δεν υπάρχει απαραίτητα ένα προς ένα αντιστοιχία µεταξύ των εσωτερικών συστατικών και των εξωτερικών πόρων. Ένα module θ αποτελείται από ένα σύνολο από εσωτερικά συστατικά τα οποία θα παρέχουν ένα σύνολο από συσχετιζόµενους πόρους στην διεπαφή. Μια εφαρµογή θ αποτελείται από τέτοια modules, που ο χρήστης θα διαχειρίζεται µέσω των πόρων ελέγχου τους. Θα πρέπει να είναι σε θέση να προσθέτει modules, ν αφαιρεί και να τ' αναβαθµίζει. Οπότε θα πρέπει να υπάρχουν αντίστοιχα και πακέτα modules System module Για οµοιοµορφία, όλοι οι πόροι του ίδιου του συστήµατος θα περιλαµβάνονται σ ένα module, το System module. Και φυσικά θα πρέπει να προστατεύονται κατάλληλα Μορφή των modules Η µονάδα ανταλλαγής γνώσης στον Σηµασιολογικό Ιστό είναι η οντολογία. Μια οντολογία µπορεί να εισάγει (import) άλλες οντολογίες. Έτσι θα ήταν φυσικό η µονάδα ανταλλαγής συστατικών του συστήµατος, το module, να περιλαµβάνει µία οντολογία -26-

35 που περιγράφει ένα πεδίο γνώσης, η οποία µπορεί να εισάγει άλλες. Στο URI της οντολογίας πρέπει ν ανακτάται µια αναπαράσταση της οντολογίας. Ένα πεδίο γνώσης µπορεί να περιλαµβάνει πληροφοριακούς πόρους και µη πληροφοριακούς. Οι πληροφοριακοί πόροι που αναφέρεται στην οντολογία µπορεί να είναι είτε τοπικοί στο namespace που ορίζει η οντολογία, που είναι το URI της οντολογίας ακολουθούµενο από µια # εξωτερικοί σε εξωτερικό namespace. Όλους τους µη ΠΠ που θα διαχειριζόµαστε και θέλουµε να είναι στην «κυριότητα» µας θα τους αναθέτουµε ένα URI reference εντός του namespace της οντολογίας. Οι πληροφοριακοί πόροι µπορεί να είναι και αυτοί τοπικοί, δηλαδή οι αναπαραστάσεις τους κρατούνται και παρέχονται τοπικά και προφανώς έχουν URI στο domain όπου είναι εγκατεστηµένο το σύστηµα εξωτερικοί, των οποίων κρατούνται µόνο περιγραφές, όπως συµβαίνει δηλαδή και µε τους µη ΠΠ Για να διατηρείται η ανεξαρτησία των modules µεταξύ τους θα πρέπει να αναθέσουµε σε κάθε module ένα ξεχωριστό namespace στο domain όπου βρίσκεται µια εγκατάσταση του συστήµατος. Έτσι θ αποφεύγονται συγκρούσεις στα ονόµατα των πόρων. Εντός του namespace αυτού θα βρίσκονται οι ΠΠ του module. Η οντολογία του module είναι και αυτή ένας ΠΠ άρα θα βρίσκεται και αυτή εκεί, εποµένως οι τοπικοί ΠΠ θα έχουν URI της µορφής: < module full namespace > ενώ οι «τοπικοί» µη ΠΠ: < module full namespace > al_name> Βλέπουµε ότι έχουµε δυο «είδη» namespace για ένα module, ένα για τους ΠΠ, τ οποίο θα το ονοµάσουµε «slash namespace» ενώ ένα για τους µη ΠΠ, τ οποίο θα το ονοµάσουµε «sharp namespace». Για οµοιοµορφία, αν απαιτήσουµε η οντολογία κάθε module να έχει τοπικό όνοµα model, έχουµε: -27-

36 < slash namespace > < sharp namespace > για µη ΠΠ για ΠΠ Οντολογία πληροφοριακών πόρων Συζητάµε για πληροφοριακούς πόρους, αλλά δεν υπάρχει κάποια προκαθορισµένη κλάση «πληροφοριακός πόρος» στην OWL, οπότε θα ορίσουµε δικιά µας. Έτσι θα ξεκινήσουµε την πρώτη οντολογία που θα διανέµεται µε το σύστηµα αλλά δε θ ανήκει σε κάποιο συγκεκριµένο module, απεναντίας κάθε οντολογία module που θέλει να ορίζει ΠΠ θα πρέπει να αναφέρεται στη συγκεκριµένη κλάση ΠΠ που θα ορίσουµε (είτε εισάγοντας την οντολογία της είτε όχι). Επειδή το σύστηµα ονοµάστηκε π 2 και αγοράστηκε το domain pisquared.org για να κρατούνται εκεί οι οντολογίες του συστήµατος, θα δώσουµε στην οντολογία πληροφοριακών πόρων το URI Εκεί ορίζουµε την κλάση InformationResource. Από εδώ και πέρα θα αναφερόµαστε σε πόρους της οντολογίας ΠΠ µε το πρόθεµα ir:, δηλαδή θα λέµε ir:informationresource αντί για Πληροφοριακοί πόροι περιγραφής Αυτήν την στιγµή µπορούµε να προσπελάσουµε έναν ΠΠ και την οντολογία όπου βρίσκεται ένας µη ΠΠ. Δεν έχουµε πει όµως για τους ΠΠ περιγραφής τους. Θα µπορούσαµε να τους εισάγουµε στην οντολογία και αυτούς, ως ΠΠ, αλλά παρατηρούµε ότι οι πόροι περιγραφής δεν ανήκουν στο ίδιο πεδίο γνώσης µε αυτούς που περιγράφουν. Για παράδειγµα, σε µια οντολογία εφηµερίδας µε κλάσεις µη ΠΠ όπως Διευθυντής, Συντάκτης και κλάσεις ΠΠ όπως Άρθρο, δεν έχουν θέση πόροι περιγραφών των Συντακτών, περιγραφών των Άρθρων. Είναι κάτι που επινοήθηκε για να προσπελαύνουµε µια συγκεκριµένη περιγραφή αντί για ολόκληρη την οντολογία. Θα µπορούσαµε να καταχωρούµε τους πόρους αυτούς σε µια δεύτερη οντολογία, αλλά δεν υπάρχει λόγος να το κάνουµε, αφού δεν χρειαζόµαστε reasoning για τους ΠΠ περιγραφής. -28-

37 Θα µπορούσαµε επίσης να ορίσουµε µια ιδιότητα «περιγραφή» µε πεδίο µια κλάση «Περιγραφή». Η προσέγγιση αυτή πάσχει από τα εξής προβλήµατα: Στην OWL DL οι ιδιότητες εφαρµόζονται µόνο σε αντικείµενα και όχι σε κλάσεις και ιδιότητες. Έτσι δεν µπορούµε να ορίσουµε ΠΠ περιγραφών για κλάσεις, ιδιότητες και για πόρους της γλώσσας. Μια ιδιότητα «περιγραφή» ειδικά για χρήση στο σύστηµα µας, είναι πρόσθετο βάρος σε ένα ξένο σύστηµα που χρησιµοποιεί τις οντολογίες µας και δεν το νοιάζουν οι ΠΠ περιγραφής. Είναι κάτι εκτός του πεδίου γνώσης και επηρεάζει την διαδικασία του reasoning χωρίς λόγο. Τελικά καταλήγουµε στη χρήση Annotation Properties, που λύνουν τα προηγούµενα προβλήµατα: εφαρµόζονται σε όλους τους πόρους και αγνοούνται από τον reasoner. Προς το παρόν δεν θα συζητήσουµε πού ορίζεται αυτή η ιδιότητα, αλλά θα επανέλθουµε στο θέµα αργότερα Βοηθητικοί πόροι: To µοντέλο Πολλαπλών Χρήσεων Θέλουµε να υπάρχουν πόροι φορµών και άλλοι βοηθητικοί πόροι όπως σελίδες αναζήτησης, κατάλογοι πόρων, σελίδες καλωσορίσµατος κ.α. Οι πόροι αυτοί προφανώς δεν ανήκουν στο πεδίο γνώσης της οντολογίας και γι αυτόν τον λόγο δεν θα καταχωρούνται στην οντολογία. Θα διατηρούµε µια ξεχωριστή οντολογία γι αυτούς, επειδή χρειαζόµαστε reasoning: για παράδειγµα, µπορεί να θέλουµε να συµπεραίνεται ότι µια φόρµα πόρου που επεξεργάζεται έναν πόρο είναι µια φόρµα. Επειδή δεν θέλουµε η επιλογή ονοµάτων ΠΠ στην οντολογία αυτή να επηρεάζει την επιλογή ονοµάτων στην κύρια οντολογία, θα έχουµε ξεχωριστά namespace γι αυτήν. Έτσι έχουµε δυο κοµµάτια του module µε 2 namespaces το καθένα (ένα slash, ένα sharp), ΠΠ εντός του slash namespace συµπεριλαµβανοµένου του ΠΠ της οντολογίας. Θα ονοµάσουµε αυτά τα κοµµάτια µοντέλα (models): το πρώτο Domain model (µοντέλο του Πεδίου) και το δεύτερο Utility model ( µοντέλο Πολλαπλών Χρήσεων ) Χειρισµός συστατικών µέσω της διεπαφής Ιστού: το µοντέλο Ελέγχου Μια ακόµα απαίτηση µας είναι να µπορούµε να επεξεργαστούµε εσωτερικά συστατικά του συστήµατος µ έναν «RESTful» τρόπο µέσω ΠΠ «ελέγχου». -29-

38 Ο ΠΠ ελέγχου ενός module ή αυτός για όλη την εφαρµογή, δεν ανήκει ούτε στο µοντέλο του πεδίου ούτε είναι βοηθητικός και επιπλέον εξαρτάται από την υλοποίηση. Με την ίδια λογική όπως πριν θεωρούµε ένα ακόµα µοντέλο για ένα module, το µοντέλο Ελέγχου, όπου θα περιλαµβάνονται οι πόροι αυτοί. Επειδή αρχίζουµε ν' ασχολούµαστε µε τα συστατικά του συστήµατος θα χρειαστούµε µια οντολογία που να τα περιγράφει, την οποία θα χρησιµοποιεί το µοντέλο Ελέγχου. 4.2 Γενική οντολογία του Συστήµατος Κατασκευάζουµε την στην οποία θ αναφερόµαστε ως οντολογία του Συστήµατος ή απλά system και θα χρησιµοποιούµε το πρόθεµα system:. Η system θα εισάγει την ir. Πριν προχωρήσουµε ορίζουµε εδώ την annotation property system:description ως την ιδιότητα περιγραφής που καταλήξαµε νωρίτερα Modules Ας αρχίσουµε µε την κατασκευαστική µονάδα του συστήµατος, τα modules. Ένα module είναι το συστατικό που έχουµε εγκατεστηµένο. Μπορεί, ανάλογα µε την υλοποίηση, να είναι π.χ. ένας φάκελος ή ένα αρχείο. Δεν θα ορίσουµε κάποιον πόρο που να ταυτοποιεί το εσωτερικό συστατικό. Έπειτα έχουµε τον πόρο ελέγχου ενός module. Ορίζουµε τη υποκλάση της ir:informationresource system:modulecontrolresource ως τη κλάση των πόρων ελέγχου modules. Κάθε τέτοιος πόρος αντιστοιχεί σ' ένα module. Για το διαµοιρασµό όµως των modules, θα πρέπει να έχουµε πόρους που δεν αντιστοιχούν σε εσωτερικό συστατικό αλλά έχουν την ίδια αναπαράσταση µε έναν πόρο ελέγχου, µε την διαφορά ότι παραµένουν στατικοί, ενώ ο πόρος ελέγχου αλλάζει. Υποβάλλοντας την αναπαράσταση ενός τέτοιου νεότερου πακέτου module σ έναν ΠΠ έλεγχου του αντίστοιχου module θα πετυχαίνουµε την αναβάθµιση του. Ορίζουµε λοιπόν τη κλάση system:modulearchive ως µια υποκλάση της ir:informationresource. Πώς ξέρουµε όµως ποιανού module είναι πακέτο ένα system:modulearchive ή ΠΠ ελέγχου ένα ModuleControlResource; Θα πρέπει να φτιάξουµε µια «αφηρηµένη» κλάση module, που ταυτοποιεί την «έννοια» ενός module και όχι κάποια συγκεκριµένη έκδοση ή πακέτο. Αυτή η κλάση θα είναι η system:module, και θα είναι το ΠΤ -30-

39 (πεδίο τιµών) των object properties system:modulearchiveofmodule και system:controlresourceofmodule. Για να ξέρουµε από δυο πακέτα ποιο είναι το νεότερο, θα πρέπει να υποστηρίξουµε εκδόσεις. Η OWL ορίζει την owl:versioninfo αλλά αυτή δεν ορίζεται ως datatype αλλά ως annotation property. Γι' αυτό θα ορίσουµε την system:versionnumber ως µια datatype property µε ΠΤ (πεδίο τιµών) xsd:float, ώστε να µπορούµε να κάνουµε συγκρίσεις εκδόσεων και να µπορούµε να την θέσουµε ως απαιτούµενη ιδιότητα (cardinality 1) για την system:modulearchive. Δεν χρειάζεται να κάνουµε το ίδιο για την system:modulecontrolresource επειδή ο αριθµός έκδοσης µπορεί να αποθηκευτεί και εντός του module Application Οι απαιτήσεις µας ορίζουν την ύπαρξη ενός ΠΠ ελέγχου για ολόκληρη την εφαρµογή. Η κλάση system:applicationcontrolresource θα είναι η κλάση των πόρων αυτών. Όπως και για τα Modules θα έχουµε για τους πόρους πακέτων µιας ολόκληρης εφαρµογής τη κλάση system:applicationarchive. Ο σκοπός της ύπαρξης πακέτων system:applicationarchive είναι για τήρηση αντιγράφων ασφαλείας µιας εφαρµογής ή για την µεταφορά και επαναφορά της, όχι για τον διαµοιρασµό πακέτων τυποποιηµένων συστατικών όπως τα modules. Γι' αυτόν το λόγο δεν θα ορίσουµε κάποια κλάση «Application» ως κλάση συγκεκριµένων εφαρµογών των οποίων είναι πακέτο ένα «ApplicationArchive», ούτε ιδιότητα «versionnumber». Ονοµάσαµε την οντολογία γενική επειδή δεν εξαρτάται από µια συγκεκριµένη υλοποίηση. Οι απαιτήσεις µας ορίζουν ότι η διεπαφή πρέπει να παραµείνει όσο το δυνατόν ανεξάρτητη της υλοποίησης. Είναι όµως απίθανο να έχουµε κοινές αναπαραστάσεις πακέτων ανεξάρτητες από την υλοποίηση, κυρίως επειδή αυτά περιέχουν κώδικα µιας συγκεκριµένης γλώσσας προγραµµατισµού. Ορίζουµε λοιπόν την κλάση system:platform ως τη κλάση των πλατφόρµων που υλοποιείται το σύστηµα. Δεν είναι ανάγκη να είναι µια συγκεκριµένη γλώσσα προγραµµατισµού ή ένα εργαλείο, αλλά µπορεί να είναι ένας συνδυασµός. Για παράδειγµα µια πλατφόρµα θα µπορούσε να είναι η «example:phpinapache» και να υλοποιείται σε γλώσσα PHP και µόνο εντός ενός Apache HTTP server. -31-

40 Κάθε πλατφόρµα πρέπει να ορίζει µια ακόµη οντολογία όπου θα ορίζονται υποκλάσεις των κλάσεων που αναφέραµε, ειδικά για την πλατφόρµα αυτήν. Ορίζουµε την Object Property control:platform µε ΠΟ τις προαναφερθείσες κλάσεις πακέτων και ΠΠ ελέγχου και ΠΤ την control:platform. Απαιτούµε η ιδιότητα αυτή να έχει πληθικότητα (cardinality) 1 γι' αυτές. Τελικά η οντολογία του µοντέλου Ελέγχου ενός module θα εισάγει την ειδική οντολογία του Συστήµατος της συγκεκριµένης πλατφόρµας όπου το module είναι υλοποιηµένο. Στην ειδική οντολογία θα ορίζεται και το στιγµιότυπο της control:platform που ταυτοποιεί την αντίστοιχη πλατφόρµα. 4.3 Υποµοντέλα Μέχρι τώρα θεωρήσαµε ότι παίρνουµε τυποποιηµένα πακέτα modules, τα «εγκαθιστούµε» και τα χρησιµοποιούµε, οπότε και τα τροποποιούµε. Αν εισάγουµε δικές µας δηλώσεις στην οντολογία ενός µοντέλου ενός module, έπειτα δε θα ξέρουµε ποια δήλωση προήλθε από πού: από εµάς ή αν προϋπήρχε. Επίσης κατά την «αναβάθµιση» δεν θα ξέρουµε ποιες δηλώσεις να σβήσουµε για να αντικαταστήσουµε µε τις δηλώσεις της νέας οντολογίας. Έχουµε δυο τρόπους να «ξεχωρίζουµε» δηλώσεις. Ο ένας είναι µε τη χρήση reification. Αυτό όµως απαιτεί να έχουµε τετραπλάσιο αριθµό δηλώσεων, οπότε απορρίπτεται! Ο δεύτερος τρόπος είναι να διατηρούµε τις δηλώσεις σε ξεχωριστές οντολογίες. Οπότε λοιπόν θα εισάγουµε την πρότυπη (standard) οντολογία σε µια νέα οντολογία, την επεκταµένη (extended). Σε µια αναβάθµιση θ' αντικαθιστούµε µόνο την πρότυπη οντολογία. Επειδή ένα µοντέλο ενός module δεν είναι µόνο η οντολογία του, θα πρέπει να διατηρούµε και τις αναπαραστάσεις των ΠΠ του πρότυπου µοντέλου ανέπαφες. Όσο για τα namespaces, οι νέοι πόροι του επεκταµένου µοντέλου πρέπει να βρίσκονται σε namespace διαφορετικό από αυτό του πρότυπου: Αν στο µέλλον η πρότυπη οντολογία χρησιµοποιήσει ένα URI που χρησιµοποιείται ήδη στο επεκταµένο µοντέλο θα έχουµε σύγκρουση ταυτοποιητών. Για να καλύψουµε τις απαιτήσεις αυτές καταλήγουµε στην έννοια του υποµοντέλου (submodel). Κάθε πακέτο module θα περιέχει πρότυπα υποµοντέλα και κατά την εγκατάσταση του θα δηµιουργούνται οι επεκτάσεις (extensions) τους, ένα υποµοντέλοεπέκταση (extension submodel) για κάθε πρότυπο υποµοντέλο. Θα ορίζουµε sharp και -32-

41 slash namespaces για όλα τα υποµοντέλα. Στην Εικόνα 4 βλέπουµε τη δοµή ενός επεκταµένου πρότυπου module. Δεν είναι ανάγκη όµως όλα τα µοντέλα να έχουν εγκατασταθεί από ένα πρότυπο πακέτο. Θα πρέπει να δίνεται η δυνατότητα ύπαρξης modules όπου ο διαχειριστής έχει πλήρη έλεγχο, και από αυτά να µπορούν να παραχθούν πρότυπα πακέτα για διαµοιρασµό. Αυτό το είδος module θα τ' ονοµάσουµε ιδιόκτητο (own) module. Κάθε µοντέλο ενός ιδιόκτητου module θ' αποτελείται από ένα µόνο υποµοντέλο, το ιδιόκτητο υποµοντέλο. Εικόνα 4 Η δοµή ενός επεκταµένου πρότυπου module. Οι πράσινοι κύλινδροι αντιπροσωπεύουν τις οντολογίες των υποµοντέλων. 4.4 Χειρισµός Έχουµε πει για το αποτέλεσµα των µεθόδων HTTP στους πόρους αλλά δεν έχουµε πει τίποτα για το πώς υλοποιείται ο χειρισµός τους. Από την µία δεν πρέπει να δείχνουµε λεπτοµέρειες υλοποίησης στον έξω κόσµο, από την άλλη θέλουµε να έχουµε έναν τρόπο να διαχειριζόµαστε το πώς γίνεται ο χειρισµός ενός πόρου Χειριστές Ανεξάρτητα από την υλοποίηση, µπορούµε χωρίς βλάβη της γενικότητας να υποθέσουµε ότι µπορεί να υπάρξει ένας πόρος ελέγχου για ένα συστατικό «χειριστή», που χειρίζεται αιτήσεις HTTP. Για παράδειγµα, στην Java EE υπάρχει η έννοια των -33-

42 Servlets, αντικείµενων που επεξεργάζονται µια αίτηση. Για έναν τέτοιο χειριστή µπορεί να υπάρξει ένας ΠΠ ελέγχου όπου στο URI θ ανακτούµε την αναπαράσταση του, στην περίπτωση του Servlet τον κώδικα Java 14, και να υποβάλλουµε νέες αναπαραστάσεις. Έτσι ορίζουµε την κλάση system:handler ως την κλάση όλων των χειριστών όλων των πλατφορµών και αφού την προσθέσουµε στο ΠΟ της system:platform, απαιτούµε για τα αντικείµενα της η ιδιότητα system:platform να έχει πληθικότητα 1. Κάθε ειδική οντολογία θα ορίζει αντίστοιχη υποκλάση της, ειδικά για την πλατφόρµα όπου αναφέρεται. Έχοντας τον χειριστή και έναν ΠΠ ελέγχου για ν' αναφερθούµε θα πρέπει να «συνδέσουµε» έναν πόρο µε τον χειριστή του. Όπως ακριβώς συνδέσαµε τον ΠΠ περιγραφής µε τον πόρο που περιγράφει µε την system:description, ορίζουµε την annotation property system:handler. Επειδή όµως και η περιγραφή είναι ένας ΠΠ, ορίζουµε και την system:descriptionhandler ως τον χειριστή της περιγραφής ενός πόρου. Οι µη ΠΠ θα έχουν οπότε µόνο description handler ενώ οι ΠΠ και από τους δυο (ας θυµηθούµε και πάλι όµως ότι η OWL DL δεν µπορεί να θέσει περιορισµούς στις annotation properties: το σύστηµα µας είναι αυτό που θα πρέπει να µην αφήνει system:handler σ' έναν µη ΠΠ) Χειρισµός ανά τύπο / κλάση Στο σηµείο αυτό αναθέτουµε έναν χειριστή ανά πόρο. Κάτι τέτοιο είναι πολύ κουραστικό. Θα µπορούσαµε να έχουµε τις system:handler, system:descriptionhandler ως object properties και να θέτουµε ένα περιορισµό hasvalue στην τιµή της ιδιότητας αυτής για τα στιγµιότυπα µιας κλάσης, ώστε όλα τα στιγµιότυπα της να έχουν έναν συγκεκριµένο χειριστή. Αυτή η προσέγγιση έχει όµως τα εξής προβλήµατα: Ο ορισµός µιας κλάση πόρων (π.χ. «Φοιτητής») δεν πρέπει να περιλαµβάνει τον χειριστή των περιγραφών της! (Ο ορισµός ενός οποιουδήποτε φοιτητή δεν περιλαµβάνει το να έχει τον τάδε χειριστή περιγραφής στο σύστηµα µας.). 14 µόνο αν τον κάνουµε µε κάποιον τρόπο διαθέσιµο, συνήθως σ εναν Servlet Container υπάρχουν µόνο τα εκτελέσιµα αρχεία των κλάσεων,.class και όχι ο κώδικας,.java. Σε περίπτωση αλλαγής κώδικα θ απαιτηθεί επαναµεταγλώττιση και επανεκκίνιση της εφαρµογής. -34-

43 Ένας πόρος µπορεί ν' ανήκει σε πολλές κλάσεις! Δεν είναι σωστό να περιορίσουµε τις κλάσεις αυτές λόγω διαφορετικών χειριστών. Αφήνουµε τις ιδιότητες χειριστών ως έχει και ορίζουµε την annotation property system:controlclass όπου θα έχει τιµή το URI (literal µε datatype xsd:anyuri) της βασικής του κλάσης, ή κλάσης ελέγχου. Δεν µπορούµε να βάλουµε τιµή την ίδια τη κλάση επειδή η OWL DL δεν επιτρέπει κλάσεις ως αντικείµενο µιας annotation property 15. Έπειτα ορίζουµε την annotation property system:instancehandler, την οποία θα τη βάζουµε στην κλάση ελέγχου. Έτσι, το σύστηµα µπορεί να χρησιµοποιήσει τον instance handler της κλάσης ελέγχου ενός πόρου, αν δεν ορίζεται handler γι' αυτόν. Αν δεν ορίζεται system:controlclassθα εννοείται η owl:thing. Αν δεν υπάρχει system:instancehandler στην κλάση ελέγχου θα κοιτάµε την owl:thing 16. Αυτό σηµαίνει ότι πρέπει να ορίζουµε πάντα instance handler για την owl:thing σε µια οντολογία. Η OWL DL όµως δεν επιτρέπει δηλώσεις για την owl:thing. Για να ξεπεράσουµε την αδυναµία αυτή, θα συνοδεύσουµε την οντολογία µας µε ένα υποστηρικτικό (support) µοντέλο όχι OWL αλλά RDFS. Εκεί µπορούµε να κάνουµε την παραπάνω δήλωση. Οπότε αν το σύστηµα δε βρει system:instancehandler στην κλάση ελέγχου ή αν δεν υπάρχει system:controlclass θα βλέπει στο υποστηρικτικό µοντέλο. Έτσι τελικά πετυχαίνουµε χειρισµό ανά κλάση. Η Εικόνα 5 δείχνει τη δοµή ενός επεκταµένου πρότυπου module, µε τα υποστηρικτικά µοντέλα αυτή τη φορά. Για να πετύχουµε χειρισµό ανά τύπο για τις κλάσεις και για τις ιδιότητες, αρκεί να ορίσουµε την system:instancehandler για τις owl:class και owl:datatypeproperty, owl:objectproperty ή owl:annotationproperty αντίστοιχα στο υποστηρικτικό µοντέλο θα µπορούσαµε αντίστοιχα να ορίσουµε µια ιδιότητα system:controlsuperclass και να κοιτάµε τον system:instancehandler αυτής, αλλά δεν υπάρχει λόγος να περιπλέξουµε τόσο πολύ τα πράγµατα. -35-

44 Εικόνα 5 Η τελική δοµή ενός επεκταµένου πρότυπου module. Οι µικροί πράσινοι κύλινδροι αντιπροσωπεύουν τα υποστηρικτικά µοντέλα των υποµοντέλων Χερισµός και υποµοντέλα Όταν υπάρχει ορισµένη η ιδιότητα system:handler για έναν πόρο στη πρότυπη οντολογία και στην επέκταση της, είναι προφανές ότι θα πρέπει να αγνοήσουµε την δεύτερη τιµή. Το ίδιο συµβαίνει και για την ιδιότητα system:description, ένας πόρος πρέπει να έχει µέχρι έναν πόρο περιγραφής και στο υποµοντέλο όπου ορίζεται και πρέπει να υπάρχει µία µόνο τιµή για την ιδιότητα description στο υποµοντέλο αυτό. Οι απαιτήσεις των annotation properties αυτών και άλλων που θα ορίσουµε στην συνέχεια µας οδηγούν να ορίσουµε την έννοια των Control Annotation Properties. 4.5 Control Annotation Properties Χρειαζόµαστε ιδιότητες για τον έλεγχο των πόρων, µε τα εξής χαρακτηριστικά: Αγνόηση τους από τον reasoner: γι' αυτό και τις ορίζουµε ως annotation properties. Δυνατότητα κλειδώµατος της τιµής κάποιων ιδιοτήτων στο πρότυπο µοντέλο αλλά και δυνατότητα υπέρβασης (overriding) της προϋπάρχουσας τιµής για κάποιες άλλες. Δηλαδή µια ιδιότητα µπορεί να είναι υπερβάσιµη (overridable) ή όχι. Αυτό δεν επιτυγχάνεται από την ίδια την OWL επειδή είναι µια γλώσσα µονότονης συλλογιστικής, οπότε πρέπει να υλοποιηθεί προγραµµατιστικά. -36-

45 Ύπαρξη µιας το πολύ τιµής για την ιδιότητα σε κάθε υποµοντέλο. Αν αγνοούσαµε τις πολλαπλές τιµές θα παίρναµε τυχαία κάθε φορά µία και θα είχαµε διαφορετική συµπεριφορά κάθε φορά. Δεν το θέλουµε αυτό οπότε πρέπει πάντα να διατηρείται µία το πολύ τιµή σε κάθε υποµοντέλο και να σβήνονται τυχόν επιπλέον. Έλεγχος τιµής και πεδίου ορισµού: Επειδή έχουµε annotation properties, αυτό πρέπει να υλοποιηθεί προγραµµατιστικά. Για παράδειγµα, πρέπει να γίνεται έλεγχος ότι η τιµή της system:description είναι ένας ΠΠ εντός του namespace του υποµοντέλου. Οι έλεγχοι αυτοί θα πρέπει να γίνονται για τον συγκεκριµένο όρο όπου αναφερόµαστε προγραµµατιστικά, γιατί µπορεί η ιδιότητα να µην εφαρµόζεται σε όλους τους πόρους του ίδιου τύπου αλλά να έχει και άλλες απαιτήσεις. Κληρονοµικότητα: µια ιδιότητα µπορεί να «κληρονοµεί» την τιµή της από την κλάση ή τον τύπο. Τέτοιες ιδιότητες είναι οι system:handler και system:descriptionhandler. Αυτές είναι κληρονοµήσιµες από τον τύπο αλλά και κληρονοµήσιµες από την κλάση. Ιδιότητες ελέγχου για κλάσεις και ιδιότητες που θέλουµε να κληρονοµούν τη τιµή τους από τις owl:class και owl:datatypeproperty κλπ. αντίστοιχα, θα είναι απλά κληρονοµήσιµες από τον τύπο. Επειδή και η system:handler και η system:instancehandler είναι στην ουσία η ίδια νοητή ιδιότητα ελέγχου, θα αναφερόµαστε στην (νοητή) ιδιότητα ελέγχου ως handler ενώ στις πραγµατικές OWL annotation properties system:handler και system:instancehandler αντίστοιχα. Η πρώτη θα είναι η ιδιότητα στιγµιοτύπου (instance property) ενώ η δεύτερη η ιδιότητα τύπου (type property) της νοητής ιδιότητας ελέγχου. Προκαθορισµένη τιµή: Κάποιες ιδιότητες ελέγχου όπως η description δεν είναι κληρονοµήσιµες. Αυτές πρέπει να έχουν µια προκαθορισµένη τιµή, ώστε να χρησιµοποιήσουµε αυτή σε περίπτωση έλλειψης τιµής. Αυτό είναι ιδιαίτερα χρήσιµο για τον έλεγχο των πόρων σε εισαγόµενες οντολογίες. Θα ήταν κουραστικό να ορίζουµε την τιµή κάθε πόρου ξεχωριστά. Η προκαθορισµένη τιµή θα πρέπει να είναι δυνατόν να παράγεται για τον συγκεκριµένο πόρο κάθε φορά. Παράδειγµα τέτοιας ιδιότητας η description. Ο πόρος µε τοπικό όνοµα Description στο πρότυπο namespace του µοντέλου πολλαπλών χρήσεων -37-

46 του module του Συστήµατος, θα είναι ένας ειδικός πόρος όπου το URI του ακολουθούµενο από ένα query string της µορφής?module=modulename&model=modelname&uri=uri θα ταυτοποιεί πάντα τη περιγραφή του πόρου µε URI URI στο µοντέλο modelname του module modulename. Αυτή θα είναι λοιπόν η προκαθορισµένη τιµή της description που θα παραχθεί για τον πόρο αυτό. Τελικά υπάρχει η ανάγκη να έχουµε τιµές για τις κληρονοµήσιµες ιδιότητες για ολόκληρη την εφαρµογή. Αυτό µας απαλλάσει από τον κόπο να δηλώνουµε τις ίδιες τιµές σε κάθε υποµοντέλο κάθε module. Οι ιδιότητες που παίρνουν όρισµα πόρους πρέπει να παίρνουν όρισµα πόρους µόνο από τα πρότυπα υποµοντέλα του module του συστήµατος, επειδή είναι το µόνο που είναι παρόν σε κάθε εγκατάσταση. Οι τιµές αυτές θα δηλώνονται στο υποστηρικτικό µοντέλο της εφαρµογής (application supporting model) Ο αλγόριθµος εύρεσης της τιµής µιας Control Annotation Property Ο αλγόριθµος εύρεσης της τιµής µιας CAP ενός πόρου σ ένα µοντέλο, αναζητεί τη τιµή της σε τρία επίπεδα: Στο επίπεδο του στιγµιοτύπου, αναζητεί τη τιµή που είναι προσκολληµένη στο ίδιο το στιγµιότυπο, της OWL ιδιότητας στιγµιοτύπου. Αν δεν υπάρχει τιµή στο επίπεδο αυτό για µια µη κληροµήσιµη ιδιότητα επιστρέφεται η προκαθορισµένη. Στο επίπεδο της κλάσης, αν δεν βρεθεί στο επίπεδο του στιγµιοτύπου και η ιδιότητα είναι κληρονοµήσιµη από την κλάση και τον τύπο, και φυσικά όταν ο πορος µας είναι ένα άτοµο. Αναζητείται η τιµή της OWL ιδιότητας τύπου της κλάσης χειρισµού. Η προκαθορισµένη τιµή της CAP controlclass είναι η OWL:Thing, οπότε αν δεν υπάρχει δηλωµένη τιµή ή η δηλωµένη τιµή είναι OWL:Thing, πάµε στο επόµενο επίπεδο. Στο επίπεδο του τύπου, αν δε βρεθεί στα προηγούµενα επίπεδα και είναι κληρονοµήσιµη από τον τύπο. Εδώ αναζητείται η τιµή της OWL ιδιότητας τύπου στο υποστηρικτικό µοντέλο αυτή τη φορά. Αν δεν υπάρχει ούτε εκεί τιµή επιστρέφεται αυτή στο υποστηρικτικό µοντέλο ολόκληρης της εφαρµογής. -38-

47 Επειδή όµως συνήθως υπάρχουν δυο υποµοντέλα, κάθε φορά προηγείται η τιµή που ορίζεται από την υπερβασιµότητα ή όχι της CAP: Σε ένα επίπεδο, αν υπάρχει τιµή στο ένα υποµοντέλο και δεν υπάρχει στο άλλο, επιστρέφεται η υπάρχουσα. Αν όµως υπάρχουν τιµές και στα δυο υποµοντέλα, αν η CAP είναι υπερβάσιµη προηγείται η τιµή στο υποµοντέλο επέκτασης, αντιθέτως προηγείται η τιµή στο πρότυπο µοντέλο. Δηλαδή δεν προτιµούνται πάντα οι τιµές στο πρότυπο, αλλά µόνο αν υπάρχει τιµή στο ίδιο επίπεδο και η CAP είναι µη υπερβάσιµη Άλλες control annotation properties descriptioneditor & editor Δεν ορίσαµε ακόµα κάποια κλάση φορµών για χρήση στο µοντέλο πολλαπλών χρήσεων. Αυτή θα είναι η system:descriptioneditor για έναν συντάκτη περιγραφής και η system:editor για έναν συντάκτη πληροφοριακού πόρου (και της περιγραφής του, προαιρετικά). Σε αυτό το σηµείο θα εισάγουµε την οντολογία του συστήµατος στην πρότυπη οντολογία του µοντέλο πολλαπλών χρήσεων, για να γίνεται χρήση των κλάσεων αυτών. Για να συνδέσουµε τους πόρους µε τους συντάκτες τους θα ορίσουµε τις control annotation properties descriptioneditor και editor ως κληρονοµήσιµες από τον τύπο, κληρονοµήσιµες από τη κλάση και υπερβάσιµες: θα µπορούµε δηλαδή να ορίζουµε διαφορετικούς συντάκτες στα υποµοντέλα-επεκτάσεις. classextensiondescriptions Υπάρχει ένα πρόβληµα µε τη προσέγγιση χειρισµού µας: Πως θα γίνεται η δηµιουργία νέου πόρου; Έστω ότι ο χειριστής µπορεί να χειριστεί αιτήσεις PUT για νέο πόρο, αλλά πως θ' αποφασίσουµε ποιος θα είναι ο χειριστής, αν δεν υπάρχει πόρος να πάρουµε τη τιµή της CAP handler; Επίσης, ένας ΠΠ έχει δύο συσχετιζόµενους πόρους, τον ίδιο τον ΠΠ και τον ΠΠ περιγραφής του. Θα υποβάλλουµε δυο αναπαραστάσεις ξεχωριστά; Για να λύσουµε αυτά τα προβλήµατα θα εισάγουµε τους ΠΠ περιγραφής επέκτασης κλάσης. Αυτοί ταυτοποιούν όλες τις περιγραφές των στιγµιοτύπων µιας κλάσης. Σε µια αίτηση GET θα επιστρέφονται οι αντίστοιχες τριπλέτες RDF. Σε µια POST οι τριπλέτες RDF της υποβληθείσας οντότητας θα προστίθενται στις υπάρχουσες. Έτσι µπορούµε ταυτόχρονα να προσθέσουµε δηλώσεις για όλα τα στιγµιότυπα της κλάσης. Αν κάποια υποκείµενα δηλώσεων στην οντότητα δεν περιέχονται στα στιγµιότυπα της κλάσης, δηµιουργούνται ως νέα -39-

48 στιγµιότυπα. Σε κάθε περίπτωση τότε προστίθενται δηλώσεις rdf:type και system:controlclass µε αντικείµενο τη κλάση αυτή. Δηλαδή ο χρήστης ορίζει την κλάση ελέγχου του νέου πόρου µε το να υποβάλλει την αναπαράσταση της περιγραφής του νέου πόρου στον ΠΠ περιγραφής επέκτασης της κλάσης αυτής. Για ΠΠ, οι αναπαραστάσεις τους µπορούν να προστεθούν αργότερα µε αιτήσεις PUT στους πόρους αυτούς, όταν υπάρχει ήδη η περιγραφή τους αποθηκευµένη. Σε µια PUT οι δηλώσεις της υποβληθείσας οντότητας θ' αντικαθιστούν τις υπάρχουσες. Αν η κλάση περιέχει εισαγόµενους πόρους, οι εισαγόµενες δηλώσεις πρέπει να περιλαµβάνονται στην υποβληθείσα οντότητα, επειδή δεν µπορούν να τροποποιηθούν. Επίσης, αν από τις δηλώσεις για έναν ΠΠ λείπει ένας MIME τύπος που ήταν δηλωµένος πριν και υπάρχουν αναπαραστάσεις του, αυτές πρέπει να διαγραφούν. Σε µια DELETE θα διαγράφονται όλες οι περιγραφές των στιγµιοτύπων της κλάσης. Για µια κλάση ΠΠ θα πρέπει επιπλέον να διαγράφονται και οι αναπαραστάσεις των περιγραφόµενων πόρων. Αν η κλάση περιέχει εισαγόµενους πόρους, µια αίτηση DELETE θ' αποτυγχάνει. Τελικά η CAP classextensiondescriptions θα ορίζει τον ΠΠ περιγραφής επέκτασης µιας κλάσης. Αν δεν δηλώνεται, η προκαθορισµένη τιµή θα είναι η <system_module_std_util_ns>/classextensiondescriptions?modu le=<modulename>&model=<modelname>&uri=<uri>, όπου <system_module_std_util_ns> το namespace του πρότυπου υποµοντέλου πολλαπλών χρήσεων του module του συστήµατος, δηλαδή παρόµοια µε την προκαθορισµένη τιµή της description. classcontrolextensiondescriptions H CAP classcontrolextensiondescriptions είναι παρόµοια µε την classextensiondescriptions µόνο που ταυτοποιεί τις περιγραφές τον πόρων που έχουν αυτή τη κλάση ως τη κλάση ελέγχου τους. Η προκαθορισµένη τιµή είναι αντίστοιχα <system_module_std_util_ns>/classcontrolextensiondescriptio ns?module=<modulename>&model=<modelname>&uri=<uri>. -40-

49 icon Η CAP icon θα ορίζει το εικονίδιο ενός πόρου, όπως θα φαίνεται σε διάφορα µέρη του συστήµατος (συµπεριλαµβανοµένου του Browser, όπως θα δούµε παρακάτω). Θα παίρνει τιµές από τη κλάση system:resourceicon, που είναι υποκλάση της ir:image, και θα είναι κληρονοµήσιµη από τη κλάση και τον τύπο. 4.6 Το πλαίσιο Τα modules δεν µπορούν να υπάρχουν από µόνα τους χωρίς έναν «κοντέινερ» (container) που θα τα περιέχει και θα τους προσφέρει απαιτούµενες βιβλιοθήκες και άλλους (υπολογιστικούς) πόρους. Το πλαίσιο αυτό θα περιλαµβάνει το βασικό εκτελέσιµο της εφαρµογής, τις οντολογίες του συστήµατος (ir, system και ειδική system) και το υποστηρικτικό µοντέλο ολόκληρης της εφαρµογής. Πρέπει να υπάρχει ένας ΠΠ ελέγχου του πλαισίου ώστε να είναι δυνατή η αναβάθµιση του µέσω της διεπαφής Ιστού, και αντίστοιχα να υπάρχουν πακέτα του πλαισίου. Οπότε ορίζουµε τις κλάσεις system:frameworkcontrolresource και system:frameworkarchive. Για τα πακέτα θα ορίζεται η system:versionnumber που θα είναι ο αριθµός έκδοσης του πλαισίου. Το µόνο στιγµιότυπο της system:frameworkcontrolresource σε µια εγκατάσταση θα είναι ο πόρος µε τοπικό όνοµα framework στο πρότυπο υποµοντέλο του µοντέλου Ελέγχου του module του Συστήµατος, και θα ελέγχει το πλαίσιο της συγκεκριµένης εγκατάστασης. Στην Εικόνα 6 φαίνεται η τελική αρχιτεκτονική µιας εφαρµογής π 2 µε το πλαίσιο και τα διάφορα modules. -41-

50 Εικόνα 6 Η αρχιτεκτονική µιας εφαρµογής π Εξαρτήσεις Ένα υποµοντέλο µπορεί να αναφέρεται σε πόρους ενός άλλου υποµοντέλου του ίδιου ή άλλου module. Για παράδειγµα µπορεί να χρησιµοποιείται ένας handler από ένα άλλο module. Οπότε έχουµε µια εξάρτηση µεταξύ modules. Η εξάρτηση αυτή είναι µεταξύ ενός πακέτου module και µιας έκδοσης ενός νοητού module. Δηλαδή ένα πακέτο module µε εξάρτηση για να εγκατασταθεί και να λειτουργήσει σωστά χρειάζεται να υπάρχει στο σύστηµα εγκατάσταση της απαιτούµενης ή νεότερης έκδοσης του απαιτούµενου module. -42-

51 Την εξάρτηση αυτή θα την κωδικοποιήσουµε στην OWL µε τη κλάση system:moduledependency που έχει απαιτούµενες ιδιότητες την object property system:targetmodule (µε ΠΟ την system:module) και την datatype property system:targetversionnumber (µε ΠΟ xsd:float) που δηλώνει την απαιτούµενη έκδοση του target module. Μια εξάρτηση είναι ανεξάρτητη της πλατφόρµας όπου υλοποιούνται τα modules και θα δηλώνεται µε την object property system:hasmoduledepedency µε ΠΟ την system:modulearchive και ΠΤ την system:moduledependency. Εξάρτηση όµως µπορεί να υπάρχει µεταξύ ενός πακέτου module και του ίδιου του πλαισίου. Ένα module µπορεί να απαιτεί µια έκδοση του πλαισίου από την οποία και µετά µόνο είναι δυνατό να εγκατασταθεί και λειτουργήσει σωστά. Αυτή η εξάρτηση θα δηλώνεται µε την datatype property system:requiredframeworkversionnumber, που παίρνει µέχρι µια τιµή για τα στιγµιότυπα της system:modulearchive. 4.8 Μεταφορά Οι πόροι βρίσκονται στα namespaces των υποµοντέλων. Αν όµως το module µπει σ ένα πακέτο και εγκατασταθεί κάπου αλλού, τα namespaces αυτά δε θα ισχύουν πλέον. Γι' αυτό πριν την εγκατάσταση σ' ένα άλλο µέρος ο χρήστης θα πρέπει να µπορεί να ορίζει τα namespaces των υποµοντέλων. Σε ποια όµως namespaces θα βρίσκονται οι πόροι εντός του πακέτου; Η λύση είναι να βρίσκονται σε προσωρινά (temporary) namespaces. Θα υπάρχουν τρία είδη προσωρινών namespaces, µε δυο υποείδη το καθένα: το temporary slash namespace για τοπικούς ΠΠ και το temporary sharp namespace για τους τοπικούς µη ΠΠ. Προφανώς οι εξωτερικοί πόροι δεν χρειάζεται να περάσουν σε προσωρινό namespace! Προσωρινό namespace του υποµοντέλου (submodel temporary namespace): Θα είναι το Όλοι οι τοπικοί ΠΠ του υποµοντέλου θα βρίσκονται σ' αυτό, και οι τοπικοί µη ΠΠ του στο sharp namespace Προσωρινό namespace για εξaρτήσεις εντός του module (submodel for intramodular dependencies): Όταν αναφερόµαστε σε πόρους άλλων υποµοντέλων του module. Το slash namespace θα είναι το

52 ενώ το sharp το odel#, όπου <submodel_name> το όνοµα του υποµοντέλου ( «domain», «util», «control» ). Προσωρινό namespace για εξaρτήσεις µεταξύ modules (submodel for intermodular dependencies): Όταν αναφερόµαστε σε πόρους υποµοντέλων άλλων modules. Το slash namespace θα είναι το <submodel_name>/ενώ το sharp namespace το <submodel_name>/model#, όπου <moduleuri>το (URI encoded) URI του άλλου module. Κατά το «φόρτωµα» οπότε ενός νέου module και κατά το «ξεφόρτωµα» (ή «πακετάρισµα») ενός υπάρχοντος module θα γίνεται προσαρµογή των namespaces από και προς τα προσωρινά namespaces αντίστοιχα, µε µια διαδικασία µετονοµασίας τον πόρων του στις οντολογίες του και στα υποστηρικτικά µοντέλα. Μεταφορά µιας ολόκληρης εφαρµογής συνεπάγεται την παραπάνω διαδικασία για όλα τα εγκατεστηµένα modules. -44-

53 5 Εργαλεία 5.1 Jena Το Jena Semantic Web Framework (Carroll et al, 2004) είναι ένα πλαίσιο Java για κατασκευή εφαρµογών Σηµασιολογικού Ιστού 17. Προσφέρει ένα προγραµµατιστικό περιβάλλον για RDF, RDFS και OWL, SPARQ και περιλαµβάνει µια µηχανή εξαγωγής συµπερασµάτων βασισµένη σε κανόνες. Η Jena είναι ανοιχτού κώδικα και αναπτύχθηκε από το πρόγραµµα Σηµασιολογικού Ιστού των εργαστηρίων της HP. Το πλαίσιο της Jena περιλαµβάνει: Ένα RDF API Ανάγνωση και εγγραφή RDF in RDF/XML, N3 και N-Triples Ένα OWL API Επίµονη ή στην µνήµη αποθήκευση Μηχανή ερωτηµάτων SPARQL Το API της Jena Η Jena έχει κλάσεις έχει κλάσεις που αναπαριστούν γράφους, πόρους, ιδιότητες και literals. Οι διεπαφές που αναπαριστούν πόρους, ιδιότητες και literals ονοµάζονται Resource, Property και Literal αντίστοιχα. Στην Jena, ένας γράφος ονοµάζεται µοντέλο και αναπαρίσταται από τη διεπαφή Model. Ακολουθεί ένα πρώτο παράδειγµα χρήσης του API: // κάποιοι ορισµοί static String personuri = " static String fullname = "John Smith" // δηµιουργία ενός άδειου µοντέλου Model model = ModelFactory.createDefaultModel();

54 // δηµιουργία πόρου Resource johnsmith = model.createresource(personuri) // προσθήκη ιδιότητας johnsmith.addproperty(vcard.fn, fullname); Η ιδιότητα παρέχεται από µια «σταθερή» κλάση VCARD που κρατάει αντικείµενα που αναπαριστούν όλους τους ορισµούς στο σχήµα της VCARD. Η Jena παρέχει σταθερές κλάσεις για γνωστά σχήµατα όπως των RDF, RDF schema και της OWL. Δηλώσεις Κάθε µοντέλο RDF αναπαρίσταται από ένα σύνολο από δηλωσεις, έτσι κάθε κλήση της addproperty προσθέτει µια ακόµη δήλωση στο µοντέλο. Η διεπαφή µοντέλου της Jena ορίζει µια µέθοδο liststatements() που επιστρέφει έναν StmtIterator, έναν υποτύπο του Iterator της Java, πάνω σε όλες τις δηλώσεις του µοντέλου. Ο StmtIterator έχει µια µέθοδο nextstatement() που επιστρέφει την επόµενη δήλωση ως ένα Statement, µια διεπαφή που παρέχει µεθόδους πρόσβασης στο υποκείµενο, στο κατηγόρηµα και στο αντικείµενο µιας δήλωσης. Ακολουθεί παράδειγµα χρήσης της liststatements(): // λίσταρε όλες τις δηλώσεις του µοντέλου model StmtIterator iter = model.liststatements(); // εκτύπωσε το υποκείµενο, το κατηγόρηµα και το αντικείµενο κάθε // δήλωσης while (iter.hasnext()) { Statement stmt = iter.nextstatement(); // πάρε την επόµενη δήλωση Resource subject = stmt.getsubject(); // πάρε το υποκείµενο Property predicate = stmt.getpredicate(); // πάρε το κατηγόρηµα RDFNode object = stmt.getobject(); // πάρε το αντικείµενο System.out.print(subject.toString()); System.out.print(" " + predicate.tostring() + " "); if (object instanceof Resource) System.out.print(object.toString()); else // το αντικείµενο είναι ένα literal System.out.print(" \"" + object.tostring() + "\""); System.out.println("."); } -46-

55 Επειδή το αντικείµενο µιας δήλωσης µπορεί να είναι είτε ένας πόρος είτε ένα literal, η getobject() επιστρέφει ένα αντικείµενου τύπου RDFNode, που είναι κοινή υπερκλάση των Resource και Literal. Εγγραφή και ανάγνωση RDF Η Jena έχει µεθόδους ανάγνωσης και εγγραφής RDF σε XML, N-Triples ή N3 από ροές εισόδου και σε ροές εξόδου αντίστοιχα, µε τις µεθόδους Model.read() και Model.write(). Πλοήγηση σ' ένα µοντέλο Δοσµένου του URI ενός πόρου, το αντικείµενο του πόρου µπορεί να ανακτηθεί από ένα µοντέλο µε τη χρήση της µεθόδου Model.getResource(String uri), που επιστρέφει ένα αντικείµενο της Resource αν υπάρχει στο µοντέλο, αλλιώς δηµιουργεί ένα νέο. Για παράδειγµα: // ανάκτησε την vcard του John Smith από το µοντέλο Resource vcard = model.getresource(johnsmithuri); Η διεπαφή Resource ορίζει έναν αριθµό από µεθόδους για την ανάκτηση των ιδιοτήτων ενός πόρου. Η Resource.getProperty(Property p) επιστρέφει µια ιδιότητα του πόρου. Η µέθοδος δεν ακολουθεί τη σύµβαση της Java για µεθόδους ανάκτησης ( getx ) επειδή επιστρέφει ένα Statement και όχι µια Property όµως θα αναµέναµε. Επιστρέφοντας ολόκληρη τη δήλωση επιτρέπουµε στην εφαρµογή ν' ανακτήσει τη τιµή της ιδιότητας µε χρήση µιας από τις µεθόδους ανάκτησης που επιστρέφουν το αντικείµενο της δήλωσης, για παράδειγµα: // ανάκτηση της ιδιότητας N Resource name = (Resource) vcard.getproperty(vcard.n).getobject(); Γενικά το αντικείµενο µιας δήλωσης µπορεί να είναι ένας πόρος ή ένα literal, έτσι ο κώδικας της εφαρµογής, ξέροντας ότι η τιµή πρέπει να είναι ένας πόρος, κάνει cast το επιστρεφόµενο αντικείµενο. Πιο απλά µπορούµε να γράψουµε: // retrieve the value of the FN property Resource name = vcard.getproperty(vcard.n).getresource(); ενώ για τη literal τιµή µιας ιδιότητας: // ανάκτηση της ιδιότητας FN String fullname = vcard.getproperty(vcard.fn).getstring(); Αν µια ιδιότητα έχει πολλές τιµές για έναν πόρο, κάνουµε χρήση της listproperties(), που επιστρέφει StmtIterator: -47-

56 // λίσταρε τα nicknames StmtIterator iter = vcard.listproperties(vcard.nickname); while (iter.hasnext()) System.out.println(iter.nextStatement().getObject().toString()); Ρωτώντας ένα µοντέλο Πέρα από τη µέθοδο Model.listStatements() υπάρχει η Model.listSubjects(), που επιστρέφει Iterator πάνω σε όλους τους πόρους που είναι υποκείµενα δηλώσεων. Η Model.listSubjectsWithProperty(Property p, RDFNode o) επιστρέφει έναν Iterator πάνω σε όλους τους πόρους που έχουν ιδιότητα p µε τιµή o. Υπάρχει η πρωταρχική µέθοδος ερώτησης model.liststatements(selector s), που επιστρέφει έναν Iterator πάνω σε όλες τις δηλώσεις του µοντέλου που «επιλέγονται» από τον Selector s, µια ειδικά σχεδιασµένη διεπαφή. Παράδειγµα χρήσης ενός Selector είναι το εξής: // επέλεξε την ιδιότητα VCARD.FN property της οποίας η τιµή τελειώνει // σε «Smith» StmtIterator iter = model.liststatements( new SimpleSelector(null, VCARD.FN, (RDFNode) null) { public boolean selects(statement s) { return s.getstring().endswith("smith"); } ); } Πράξεις σε µοντέλα Περιέχονται 3 λειτουργίες για την διαχείριση µοντέλων στο σύνολο τους. Αυτές είναι οι τυπικές πράξεις συνόλων της ένωσης, της τοµής και της διαφοράς και υλοποιούνται από τις µεθόδους Model.union(Model model), Model.intersection(Model model), και Model.difference(Model model) αντίστοιχα. -48-

57 Containers Η Jena περιέχει µεθόδους για τον χειρισµό containers του RDF (BAG,ALT,SEQ) αλλά δε θα τις δούµε γιατί δε θα χρησιµοποιηθούν στην υλοποίηση. Literals και τύποι δεδοµένων Τα RDF literals δεν είναι απλά strings, αλλά µπορεί να έχουν και µια ετικέτα γλώσσας που υποδεικνύουν τη γλώσσα του literal. Για παράδειγµα, για να εισάγουµε µια rdfs:label στα γαλλικά, γράφουµε: r.addproperty(rdfs.label, model.createliteral("chat", "en")); Οι διεπαφές της Jena υποστηρίζουν επίσης literals µε τύπο δεδοµένων. Η δηµιουργία τους γίνεται µε την µέθοδο Model.createTypedLiteral() Το Ontology API της Jena Όπως είδαµε, υπάρχουν διάφορες γλώσσες οντολογιών διαθέσιµες για την αναπαράσταση πληροφορίας οντολογιών στον Σηµασιολογικό Ιστό. Κυµαίνονται από την πιο εκφραστική, OWL Full, στη πιο αδύναµη, RDFS. Μέσα από το Ontology API, η Jena στοχεύει να παρέχει µια συνεπή προγραµµατιστική διεπαφή για την ανάπτυξη εφαρµογών οντολογιών,ανεξάρτητα από τη γλώσσα οντολογιών που χρησιµοποιείται, δηλαδή το API είναι ουδέτερο σε σχέση µε τη γλώσσα. Για την αναπαράσταση των διαφορών µεταξύ των ποικίλων αναπαραστάσεων, κάθε γλώσσα έχει ένα προφίλ, που λιστάρει τις επιτρεπόµενες δοµές και τα ονόµατα των κλάσεων και των ιδιοτήτων. Το προφίλ συνδέεται µε ένα µοντέλο οντολογίας, που είναι µια επεκταµένη εκδοχή της κλάσης Model της Jena. Ενώ η τελευταία επιτρέπει πρόσβαση στις δηλώσεις µιας συλλογής δεδοµένων RDF, η OntModel το επεκτείνει προσθέτοντας υποστήριξη για κλάσεις, ιδιότητες και άτοµα. Όταν δουλεύουµε µε µια οντολογία στην Jena, όλη η πληροφορία κατάστασης εξακολουθεί να είναι κωδικοποιηµένη σε τριπλέτες RDF (Statements). Το ontology API δεν αλλάζει την RDF αναπαράσταση των οντολογιών, απλά προσθέτει ένα σύνολο από κλάσεις και µεθόδους για την πιο εύκολη µεταχείριση των δηλώσεων RDF. Οντολογίες και reasoning Ένας από τους κύριους λόγους για την κατασκευή εφαρµογών βασισµένων σε οντολογίες είναι η χρήση ενός reasoner για να εξάγονται πρόσθετες αλήθειες για τις οντότητες που µοντελοποιούµε. Υπάρχουν πολλά στυλ αυτόµατου reasoning και πάρα πολλοί διαφορετικοί αλγόριθµοι. Η Jena υποστηρίζει ποικίλους reasoners µέσα από το -49-

58 inference API. Ένα κοινό χαρακτηριστικό των reasoners της Jena είναι ότι δηµιουργούν ένα νέο µοντέλο RDF που φαίνεται να περιέχει τις τριπλέτες που εισάχθηκαν στο βασικό µοντέλο, και χρησιµοποιείται µε τον ίδιο ακριβώς τρόπο όπως τ' άλλα µοντέλα. Αυτό φαίνεται στην Εικόνα 7: Εικόνα 7 Οι δηλώσεις που βλέπονται από ένα OntModel. Ο γράφος (Graph) είναι µια εσωτερική διεπαφή της Jena που υποστηρίζει τη σύνθεση συνόλων από τριπλέτες RDF. Οι εισαχθείσες δηλώσεις, που µπορεί να έχουν διαβαστεί από ένα έγγραφο οντολογίας, κρατούνται στο βασικό γράφο. Ο reasoner µπορεί να χρησιµοποιήσει τα περιεχόµενα του βασικού γράφου και τους σηµασιολογικούς κανόνες µιας γλώσσας για να δείξει ένα πιο πλήρες σύνολο δηλώσεων. Αυτό παρέχεται επίσης από µια διεπαφή Graph, οπότε το µοντέλο δουλεύει µόνο µε την πιο έξω διεπαφή. Αυτή η κανονικότητα µας επιτρέπει να φτιάξουµε πολύ εύκολα µοντέλα οντολογιών µε ή χωρίς έναν reasoner. Αυτό επίσης σηµαίνει ότι ο βασικός γράφος µπορεί να είναι σε µια αποθήκη στη µνήµη ή σε µια αποθήκη υποστηριζόµενη από µια βάση δεδοµένων, χωρίς αυτό να επηρεάζει τη λειτουργία του µοντέλου οντολογίας. Πολυµορφισµός στο επίπεδο του RDF και Java Σε µια οντολογία µπορούµε να δηλώσουµε π.χ. ότι ένας πόρος είναι µια owl:class και έπειτα ότι είναι και ένα owl:restriction. Αυτό είναι απολύτως σωστό, επειδή η owl:restrictionείναι υποκλάση της owl:class, αλλά ποια κλάση θα χρησιµοποιηθεί στη µοντελοποίηση σε Java, η OntClass ή η Restriction; Ακόµα χειρότερα, στην OWL Full µπορούµε να δηλώσουµε ότι ένας πόρος είναι κλάση και ιδιότητα ταυτόχρονα! -50-

59 Η Jena δέχεται αυτό το βασικό χαρακτηριστικό του πολυµορφισµού στο επίπεδο του RDF θεωρώντας ότι η Java αφαίρεση (OntClass, Restriction, DatatypeProperty, κλπ.) είναι απλά µια όψη του πόρου. Υπάρχει δηλαδή µια αντιστοιχία ένας-προς-πολλές µεταξύ ενός πόρου και των όψεων που µπορεί να παρουσιάσει. Για παράδειγµα, ένας πόρος µε τύπο owl:class µπορεί να παρουσιάσει την όψη OntClass. Η Jena παρέχει τη µεθοδο.as()για να αντιστοιχίζει αποτελεσµατικά ένα αντικείµενο RDF σε µια από τις διαθέσιµες του όψεις, οι οποίες ταυτοποιούνται από την Java κλάση της όψης. Για παράδειγµα, για να πάρουµε την όψη OntClass ενός πόρου, γράφουµε: Resource jediknightresource = mymodel.getresource( SW_NS + "JediKnight" ); OntClass jediknightclass = (OntClass) jediknightresource.as( OntClass.class ); Υπάρχει επίσης η boolean µέθοδος canas() που επιστρέφει true αν η δοσµένη όψη υποστηρίζεται για τον πόρο αυτό. Δηµιουργία µοντέλων οντολογιών Ένα µοντέλο οντολογίας είναι µια επέκταση του µοντέλου RDF της Jena και παρέχει δυνατότητες για χειρισµό οντολογιών. Τα µοντέλα οντολογιών δηµιουργούνται επίσης µέσω του ModelFactory. Ο πιο απλός τρόπος για την δηµιουργία ενός είναι: OntModel m = ModelFactory.createOntologyModel(); Αυτό θα δηµιουργήσει ένα µοντέλο οντολογίας µε τις προεπιλεγµένες ρυθµίσεις (OWL- Full, αποθήκευση στη µνήµη, RDFS inference). Για ένα µοντέλο χωρίς καθόλου reasoning θα γράφαµε: OntModel m = ModelFactory.createOntologyModel( OntModelSpec.OWL_MEM ); Πέρα από τις βασικές αυτές επιλογές, οι πολυπλοκότητες των ρυθµίσεων ενός µοντέλου ενθυλακώνονται σ ένα αντικείµενο-«συνταγή» που ονοµάζεται OntModelSpec. Αυτά τα χαρακτηριστικά επιτρέπουν πλήρη έλεγχο πάνω στις επιλογές ρυθµίσεων του µοντέλου, συµπεριλαµβανοµένων του προφίλ γλώσσας, του reasoner και του τρόπου χειρισµού που λαµβάνουν τα έγγραφα. Ένας αριθµός από «συνταγές» είναι προδηλωµένες ως σταθερές του OntModelSpec. Για τη δηµιουργία ενός µοντέλου µε δοσµένα τα χαρακτηριστικά, π.χ. τα προδηλωµένα OntModelSpec.OWL_MEM, καλούµε την ModelFactory ως έχει: OntModel m = ModelFactory.createOntologyModel( OntModelSpec.OWL_MEM ); -51-

60 Για τη δηµιουργία ενός προσαρµοσµένου (custom) µοντέλου, δηµιουργούµε ένα νέο από τον constructor και καλούµε τις διάφορες µεθόδους ανάθεσης τιµής για να θέσουµε τις κατάλληλες τιµές. Για παράδειγµα, για να µια τροποποιήσουµε µια υπάρχουσα «συνταγή»: OntModelSpec s = new OntModelSpec( OntModelSpec.OWL_MEM ); s.setdocumentmanager( mydocmgr ); OntModel m = ModelFactory.createOntologyModel( s ); Σύνθετα µοντέλα οντολογιών και επεξεργασία εισαγωγών Είδαµε ότι µια οντολογία OWL µπορεί να εισάγει µια άλλη. Η Jena βοηθάει αυτούς που αναπτύσσουν οντολογίες να δουλεύουν µε αρθρωτές οντολογίες µε το να χειρίζεται αυτόµατα τις δηλώσεις owl:imports στα µοντέλα οντολογιών. Η βασική ιδέα είναι ότι το βασικό µοντέλο ενός µοντέλου οντολογίας είναι στη πραγµατικότητα µια συλλογή από µοντέλα, ένα για κάθε εισαγόµενη οντολογία. Η Εικόνα8 δείχνει πως το µοντέλο οντολογίας κατασκευάζει µια συλλογή από εισαγόµενα µοντέλα: Εικόνα 8 Δοµή σύνθετων µοντέλων οντολογιών για τα imports. -52-

61 Φορτώνουµε ένα έγγραφο οντολογίας, από ένα αρχείο ή από τον Ιστό σ' ένα µοντέλο οντολογίας µε τον ίδιο τρόπο όπως ένα κανονικό µοντέλο, µε τις διάφορες παραλλαγές της µεθόδου read. Προκαθορισµένα όταν ένα µοντέλο οντολογίας διαβάζει ένα έγγραφο οντολογίας επίσης εντοπίζει και φορτώνει τις εισαγόµενες οντολογίες. Κάθε µία απ' αυτές κρατείται σε διαφορετικό γράφο, επειδή θέλουµε να κρατάµε την πηγαία οντολογία ξεχωριστά από τις εισαχθείσες. Όταν τροποποιούµε το µοντέλο, µόνο το βασικό µοντέλο τροποποιείται. Ο διαχειριστής εγγράφων οντολογιών Κάθε µοντέλο οντολογίας έχει έναν συσχετιζόµενο διαχειριστή εγγράφων που βοηθάει µε την επεξεργασία και τον χειρισµό σχετικά µε έγγραφα. Ένας OntDocumentManager µπορεί να τεθεί σ ένα αντικείµενο OntModelSpec µε τη µέθοδοsetdocumentmanager(). Ο κατασκευαστής µοντέλων Για να φτιάξει ο διαχειριστής εγγράφων την ένωση των εισαγόµενων µοντέλων (το «imports closure») πρέπει να υπάρχει κάποιος τρόπος δηµιουργίας νέων γράφων για την αποθήκευση των εισαγόµενων οντολογιών. Φόρτωση ενός µοντέλου σηµαίνει ότι χρειάζεται να προστεθεί ένας νέος γράφος. Η Jena ορίζει έναν κατασκευαστή µοντέλων, ModelMaker, που επιτρέπει διάφορα είδη αποθήκευσης µοντέλων (στη µνήµη, backed από αρχείο, σε µια ΒΔ κλπ.) να δηµιουργούνται on demand. Για την περίπτωση της βάσης δεδοµένων, αυτό µπορεί να περιλαµβάνει το πέρασµα του ονόµατος χρήστη, τον κωδικό και άλλες παραµέτρους της σύνδεσης. Στη περίπτωση µοντέλων οντολογιών, ένα OntModelSpec περιέχει δυο παραµέτρους κατασκευαστών µοντέλων, τον κατασκευαστή του βασικού µοντέλου και αυτόν των εισαγόµενων, που θέτονται µε τις setbasemodelmaker() και setimportsmodelmaker() αντίστοιχα OntResource Όλες οι κλάσεις στο API οντολογιών που αναπαριστούν τιµές οντολογίας έχουν την OntResource ως κοινή υπερκλάση. Αυτό κάνει την OntResource ένα καλό µέρος να µπει κοινή λειτουργικότητα για όλες αυτές τις κλάσεις, και την κάνει µια βολική κοινή τιµή επιστροφής για γενικές µεθόδους. Η Java διεπαφή OntResource επεκτείνει την διεπαφή Resource, έτσι κάθε γενική µέθοδος που δέχεται ένα Resource ή ένα RDFNode δέχεται επίσης και ένα OntResource. -53-

62 Η OntResource διαθέτει µεθόδους της µορφής add<property>, set<property>, list<property>, get<property>, has<property> και remove<property> όπου property µια από τις κοινές ιδιότητες που ορίζει η OWL: owl:versioninfo, owl:comment, owl:label, owl:seealso, owl:isdefinedby, owl:sameas. H OntResource ορίζει επίσης κάποιες γενικές µεθόδους πολλαπλών χρήσεων, όπως η getcardinality( Property p ), που επιστρέφει τον αριθµό των τιµών που έχει ένας πόρος για τη δοσµένη ιδιότητα p, και την remove(), που αφαιρεί από το µοντέλο κάθε δήλωση που έχει τον πόρο αυτό ως υποκείµενο ή ως αντικείµενο. Τελικά η OntResource παρέχει µεθόδους για το listing, την ανάκτηση και την ανάθεση του rdf:type ενός πόρου, που δείχνει µια κλάση (από τις πολλές) στην οποία ανήκει ο πόρος. Οι τιµές που επιστρέφει η listrdftypes()εξαρτώνται συνήθως περισσότερο από τον reasoner που είναι συνδεµένος στο µοντέλο. Υπόλοιπες κλάσεις To Ontology API περιέχει κλάσεις που αντιστοιχούν στις κύριες έννοιες της OWL (όπως η OntClass, οι ObjectProperty και DatatypeProperty κλπ) και την δυνατότητα εποπτείας (ελέγχου) και διαχείρισης των κύριων ιδιοτήτων αυτών των κλάσεων. Δεν θα κάνουµε εξαντλητική ανάλυση τους εδώ. 5.2 Restlet To Restlet 18 είναι ένα ανοιχτού κώδικα πλαίσιο ανάπτυξης «RESTful» εφαρµογών σε Java, της εταιρίας Noelios Consulting Βασικά χαρακτηριστικά Native υποστήριξη του REST Οι βασικές έννοιες του REST έχουν ισοδύναµες κλάσεις Java (για παράδειγµα UniformInterface, Resource, Representation, Connector). Κατάλληλο για εφαρµογές ιστού και στη µεριά του πελάτη και στη µεριά του εξυπηρέτη

63 Η υπηρεσία Tunneling επιτρέπει στους φυλλοµετρητές να αναθέτουν οποιαδήποτε HTTP µέθοδο µέσω ενός απλού HTTP POST. Η υπηρεσία είναι διαφανής για τις εφαρµογές Restlet. Πλήρης Εξυπηρέτης Ιστού «Σερβίρισµα» στατικών αρχείων παρόµοιο µε του Apache HTTP Server, µε αντιστοίχιση µεταδεδοµένων βασισµένη σε καταλήξεις αρχείων. Διαφανής διαπραγµάτευση περιεχοµένου (content negotiation) βασισµένη στις προτιµήσεις του πελάτη. Υπηρεσία αποκωδικοποίησης που αποκωδικοποιεί διάφανα συµπιεσµένες ή κωδικοποιηµένες αναπαραστάσεις εισόδου. Υπηρεσία logging που γράφει όλες τις προσβάσεις στις εφαρµογές µας σε ένα πρότυπο αρχείο Web log. Υποστήριξη ανακατεύθυνσης βασισµένη στο URI, παρόµοια µε του Apache Rewrite module. Διαθέσιµοι διασυνδέτες Περιλαµβάνονται διάφοροι διασυνδέτες για το HTTP και για άλλα πρωτόκολλα, αλλά στο σύστηµα µας απασχολεί µόνο το HTTP. Διαθέσιµες αναπαραστάσεις Ενσωµατωµένη υποστήριξη για αναπαραστάσεις XML Integration µε τη µηχανή templating FreeMarker Integration µε τη µηχανή templating Velocity κ.α. Ευέλικτη ρύθµιση Πλήρης ρύθµιση δυνατή σε Java µέσω του Restlet API Παρέχεται προσαρµογέας Servlet που µας επιτρέπει να deploy οποιαδήποτε εφαρµογή Restlet σε compliant containers όπως ο Tomcat, όταν η χρήση standalone διασυνδετών HTTP δεν είναι δυνατή. κ.α. Ασφάλεια Υποστηρίζονται διάφοροι τύποι authentication όπως HTTP Basic και Digest, αλλά δε θα µας απασχολήσουν επειδή η ασφάλεια δεν είναι στις απαιτήσεις της πρώτης έκδοσης του συστήµατος µας. -55-

64 Κλιµακωσιµότητα Πλήρως πολυνηµατική σχεδίαση µε στιγµιότυπα Resource ανά αίτηση για την µείωση προβληµάτων µε την ασφάλεια των νηµάτων (thread-safety), κατά την ανάπτυξη εφαρµογών. Εσκεµµένη αφαίρεση των συνόδων (sessions) HTTP, όπως ορίζει η απαίτηση άνευ κατάστασης του REST Σύντοµο tutorial στο Restlet Καταχώριση µια υλοποίησης Το πλαίσιο Restlet αποτελείται από δυο κύρια κοµµάτια. Καταρχήν υπάρχει το Restlet API, ένα ουδέτερο API που υποστηρίζει τις έννοιες του REST και facilitating τον χειρισµό των κλήσεων για εφαρµογές στην µεριά και του πελάτη και του εξυπηρέτη. Το API πρέπει να υποστηρίζεται από µια υλοποίηση του Restlet πριν να µπορέσει να χρησιµοποιηθεί αποτελεσµατικά. Πολλαπλές υλοποιήσεις µπορούν να υποστηριχθούν. Αυτή τη στιγµή η Noelios Restlet Engine (NRE) είναι διαθέσιµη και δρα ως υλοποίηση αναφοράς, και περιλαµβάνεται στη διανοµή του Restlet. Μια υλοποίηση περιλαµβάνεται σ' ένα αρχείο JAR (η NRE στο com.noelios.restlet.jar) και καταχωρείται αυτόµατα κατά την εκκίνιση του προγράµµατος. Στην Eικόνα 9 βλεπουµε την αρχιτεκτονική του Restlet: Εικόνα 9 Αρχιτεκτονική του πλαισίου Restlet. -56-

65 «Ακρόαση» των φυλλοµετρητών Το Restlet παρέχει και µεθόδους για την µεριά του πελάτη, αλλά εµάς µας ενδιαφέρει η µεριά του εξυπηρέτη. Εκεί το πλαίσιο µπορεί να «ακούει» σε αιτήσεις πελατών και να απαντάει σ' αυτές. Στο παράδειγµα που ακολουθεί γίνεται χρήση ενός από τους διασυνδέτες εξυπηρέτη HTTP της NRE και επιστρέφει µια απλή string αναπαράσταση «Hello World» ως απλό κείµενο. // Δηµιουργία ενός µινιµαλιστικού Restlet που επιστρέφει "Hello World" Restlet restlet = new Restlet() public void handle(request request, Response response) { response.setentity("hello World!", MediaType.TEXT_PLAIN); } }; // Δηµιουργία ενός εξυπηρέτη HTTP και ακρόαση στη θύρα 8182 new Server(Protocol.HTTP, 8182, restlet).start(); Η κλάση Restlet είναι παρόµοια µε την Servlet της Java EE και παρέχει σχετικά περιορισµένη βοήθεια στον χειρισµό κλήσεων στις «Restful» εφαρµογές. Θα δούµε παρακάτω πιο ειδικευµένες υποκλάσεις που κάνουν καλύτερη αφαίρεση και απλοποιούν τη διαδικασία χειρισµού. Αν τρέξουµε τον κώδικα θα δούµε στην διεύθυνση αλλά και σε οποιαδήποτε άλλη κάτω απ αυτήν το αποτέλεσµα. Συστατικά, εικονικά hosts και εφαρµογές Εκτός της υποστήριξης των πρότυπων στοιχείων της αρχιτεκτονικής του REST, Client και Server, το πλαίσιο Restlet παρέχει επίσης ένα σύνολο από κλάσεις που απλοποιούν τη φιλοξενία πολλαπλών εφαρµογών στην ίδια JVM. Στην Εικόνα 10 βλέπουµε τους τρεις τύπους Restlet που παρέχονται για να διαχειριστούµε αυτές τις πολύπλοκες περιπτώσεις. -57-

66 Εικόνα 10 Συστατικά, εικονικά hosts και εφαρµογέςπηγή: Τα Components (συστατικά) µπορούν να διαχειρίζονται πολλαπλά Virtual Hosts (εικονικά hosts) και Applications (εφαρµογές). Τα Virtual Hosts υποστηρίζουν ευέλικτη ρύθµιση όπου, για παράδειγµα, η ίδια διεύθυνση IP µοιράζεται µεταξύ πολλαπλών domain ονοµάτων, ή όπου το ίδιο όνοµα domain µοιράζεται σε πολλαπλά domains. Τελικά χρησιµοποιούµε Applications για να διαχειριστούµε ένα σύνολο από συσχετιζόµεναrestlets, Resources και Representations. Επιπροσθέτως οι Applications είναι εξαφαλισµένα µεταφέρσιµες και επαναρυθµιζόµενες πάνω από διαφορετικές Restlet υλοποιήσεις και σε διαφορετικά εικονικά hosts. Επίσης προσφέρουν σηµαντικές υπηρεσίες όπως logging της πρόσβασης, αυτόµατη αποκωδικοποίηση των οντοτήτων των αιτήσεων, ρυθµιζόµενη σελίδα κατάστασης κ.α. Για να επεξηγήσουµε αυτές τις κλάσεις, ας δούµε ένα απλό παράδειγµα. Εδώ δηµιουργούµε ένα Component και του προσθέτουµε έναν διασυνδέτη εξυπηρέτη HTTP που ακουέι στη θύρα Έπειτα δηµιουργούµε ένα απλό Restlet «ιχνηλάτισης» και το προσκολλάµε στο προκαθορισµένο VirtualHost του Component. Ο προκαθορισµένος host πιάνει κάθε αίτηση που δεν δροµολογήθηκε ήδη από έναν δηλωµένο VirtualHost. Σε επόµενο παράδειγµα θα εισάγουµε τη χρήση της κλάσης Application. // Δηµιουργία ενός νέου Restlet component και προσθήκη ενός διασυνδέτη // εξυπηρέτη HTTP σ' αυτόν Component component = new Component(); component.getservers().add(protocol.http, 8182); -58-

67 // Δηµιουργία ενός νέου Restlet ιχνηλάτησης Restlet restlet = new Restlet() public void handle(request request, Response response) { // Τύπωσε το ζητούµενο URI String message = "Resource URI : " + request.getresourceref() + '\n' + "Root URI : " + request.getrootref() + '\n' + "Routed part : " + request.getresourceref().getbaseref() + '\n' + "Remaining part: " + request.getresourceref().getremainingpart(); response.setentity(message, MediaType.TEXT_PLAIN); } }; // Έπειτα προσκόλλησε το στο local host component.getdefaulthost().attach("/trace", restlet); // Εκκίνησε το component! // Ο διασυνδέτης εξυπηρέτη HTTP ξεκινάει αυτόµατα. component.start(); Αν γράψουµε σ' έναν φυλλοµετρητή, θα πάρουµε: Resource URI : Root URI : Routed part : Remaining part: /abc/def?param=123 «Σερβίρισµα» στατικών αρχείων Για να «σερβίρουµε» στατικά αρχεία όπως στατικές ιστοσελίδες εντός ενός καταλόγου, µπορούµε απλά και εύκολα να χρησιµοποιήσουµε τη αφοσιωµένη κλάση Directory: // Δηµιουργία ενός component Component component = new Component(); component.getservers().add(protocol.http, 8182); component.getclients().add(protocol.file); // Δηµιουργία µιας application Application application = new Application() public Restlet createroot() { // όπου ROOT_URI το µονοπάτι του καταλόγου µας return new Directory(getContext(), ROOT_URI); -59-

68 }; } // Προσκόλλησε την application στο component και ξεκίνησε την component.getdefaulthost().attach("", application); component.start(); Αν θέλουµε να προσαρµόσουµε την αντιστοίχιση µεταξύ καταλήξεων αρχείων και των µεταδεδοµένων (τύπος MIME, γλώσσα ή κωδικοποίηση) µπορούµε να χρησιµοποιήσουµε την ιδιότητα metadataservice της Application. Περιφρούρηση πρόσβασης σε ευαίσθητους πόρους Το Restlet παρέχει µηχανισµούς ελέγχου της πρόσβασης στα Restlets αλλά δε θ' ασχοληθούµε µε αυτούς, αφού η ασφάλεια δεν είναι στις απαιτήσεις της πρώτης έκδοσης του συστήµατος µας. Επανεγγραφή URI και ανακατεύθυνση Το Restlet παρέχει υποστήριξη για «cool» URIs. Το πρώτο εργαλείο είναι ο Redirector, που επιτρέπει την επανεγγραφή ενός cool URI σ ένα άλλο URI. Στο παρακάτω απλό παράδειγµα, ανακατευθύνουµε τις αιτήσεις στο σχετικό URI /path/to/the/source στο /target: // Δηµιουργία ενός ro ot router (βλ. επόµενη παράγραφο) Router router = new Router(getContext()); // Δηµιουργία Redirector String target = "/target"; Redirector redirector = new Redirector(getContext(), target, Redirector.MODE_CLIENT_TEMPORARY); // Προσκόλληση του redirector στον router Route route = router.attach("/search", redirector); Δροµολογητές και ιεραρχικά URIs Εκτός του Redirector, έχουµε ένα ακόµα εργαλείο για διαχειριζόµαστε «cool» URIs, τους Routers. Είναι ειδικευµένα Restlets που µπορεί να έχουν άλλα Restlets (Finders και Filters για παράδειγµα) προσκολληµένα σ' αυτά που µπορούν αυτόµατα να ανακατευθύνουν κλήσεις βασισµένα σ' ένα URI template 19. Γενικά, θέτουµε έναν Router ως τη ρίζα της Application µας, όπως κάναµε και στο προηγούµενο παράδειγµα, όπου προσκολλήσαµε τον Redirector µε URI template το /search. Στο

69 σύστηµα µας τελικά δεν θα χρησιµοποιήσουµε Routers και θα δούµε αργότερα τον λόγο. Φτάνοντας στους πόρους-στόχους Μέχρι τώρα αναφέραµε τους µηχανισµούς δροµολόγησης και ανακατεύθυνσης, αλλά δεν δώσαµε σηµασία στη µέθοδο της αίτησης ούτε στις προτιµήσεις του πελάτη. Επίσης πως συνδέουµε τους Restlet χειριστές µας µε τα διάφορα συστήµατα από πίσω (backend); Μια αίτηση περιέχει ένα URI που ταυτοποιεί τον πόρο-στόχο που είναι το υποκείµενο της κλήσης. Η πληροφορία αυτή αποθηκεύεται στην ιδιότητα Request.resourceRef. Έτσι ο πρώτος στόχος όταν χειριζόµαστε µια αίτηση είναι να βρούµε τον πόρο-στόχο που είναι µέσα στο πλαίσιο... ένα στιγµιότυπο της κλάσης Resource ή πιο συγκεκριµένα µία από τις υποκλάσεις της. Για βοήθεια χρησιµοποιούµε έναν αφιερωµένο Finder, µια υποκλάση του Restlet, που παίρνει µια αναφορά σε µια κλάση Resource ως όρισµα κατασκευάζει ένα στιγµιότυπο της όταν έρχεται µια αίτηση. Τότε αυτόµατα προωθεί την κλήση στο µόλις δηµιουργηµένο στιγµιότυπο, στη πραγµατικότητα σε µια από τις µεθόδους handle*()(handleget, handledelete κλπ.). Η κλάση Router περιέχει µια µέθοδο attach() που παίρνει ως ορίσµατα µια URI template και µια κλάση Resource και δηµιουργεί διάφανα έναν Finder για µας. Για παράδειγµα, αναθέτουµε στην κλάση «UserResource.class» να χειρίζεται αιτήσεις που αφορούν «χρήστες» και είναι της µορφής /users/{user}, όπου το {user} δηλώνει στη URI template µας µια µεταβλητή user, ως εξής: // Προσκόλλησε έναν resource στον router router.attach("/users/{user}", UserResource.class); Ας κάνουµε µια επισκόπηση της κλάσης αυτής. Η κλάση προέρχεται από την org.restlet.resource.resource οπότε πρέπει να υπερβεί τον constructor τριών ορισµάτων. Αυτός θα αρχικοποιεί τις χρήσιµες ιδιότητες context, request and response στα στιγµιότυπα µας. Έπειτα χρησιµοποιούµε τη παράµετρο «user» που εξάγεται από την URI template /users/{user}και αποθηκεύουµε την τιµή της σε µια βολική µεταβλητή-µέλος. Σε αυτό το σηµείο, σε µια πλήρη εφαρµογή, θ' αναζητούσαµε το associated αντικείµενο «χρήστη». Τελικά δηλώνουµε ποιες παραλλαγές (variants) αναπαράστασης που θέλουµε να εκθέσουµε, στη περίπτωση µας µόνο απλό κείµενο. Αυτό θα χρησιµοποιηθεί κατά την εκτέλεση για να γίνει -61-

70 διαπραγµάτευση περιεχοµένου, έτσι ώστε να επιλεχθεί η προτιµώµενη παραλλαγή για κάθε χειριζόµενη αίτηση, όλα αυτάδιάφανα. public class UserResource extends Resource { String username; Object user; public UserResource(Context context, Request request, Response response) { super(context, request, response); this.username = (String) request.getattributes().get("user"); this.user = null; // κάποιο αντικείµενο «χρήστη» // εδώ προσθέτουµε τις παραλλαγές αναπαράστασης που θέλουµε να // εκθέσουµε getvariants().add(new Variant(MediaType.TEXT_PLAIN)); public Representation getrepresentation(variant variant) { Representation result = null; if (variant.getmediatype().equals(mediatype.text_plain)) { result = new StringRepresentation("Account of user \"" + this.username + "\""); } return result; } } Αυτός ο κώδικας χειρίζεται µόνο αιτήσεις GET. Αν θέλουµε να υποστηρίξουµε και άλλες µεθόδους, πρέπει να δηµιουργήσουµε µια µεθοδο «allowx()» και τις µεθόδους acceptrepresentation(representation), storerepresentation(representation) και removerepresentations() για τις µεθόδους HTTP POST, PUT και DELETE αντίστοιχα. -62-

71 6 Υλοποίηση Η υλοποίηση έγινε στην πλατφόρµα Restlet µε χρήση της βιβλιοθήκης Jena, γι' αυτό και στην ειδική οντολογία του συστήµατος δόθηκε το URI και στην πλατφόρµα το Θα χρησιµοποιούµε to πρόθεµα rjs: για ν' αναφερόµαστε στους πόρους της. Η υλοποίηση βασίστηκε στην έκδοση του Restlet 1.1 M5 που ήταν η πιο πρόσφατη τη στιγµή που άρχισε. Επειδή το Restlet µπορεί να τρέξει και αυτόνοµα ως εξυπηρέτης HTTP, δεν ενσωµατώθηκε σε κάποιον άλλον HTTP server και ούτε χρησιµοποιήθηκαν τεχνολογίες JAVA EE. 6.1 Πακέτα και βασικές κλάσεις Λογική οργάνωση των πακέτων H λογική που ακολουθήθηκε για τον διαµοιρασµό των κλάσεων σε πακέτα (Java packages) είναι η εξής: Η λειτουργικότητα που είναι ανεξάρτητη και από το Restlet και από την Jena θα πρέπει να αποµονωθεί σε ξεχωριστό πακέτο, ώστε να είναι δυνατόν να χρησιµοποιηθεί σε οποιαδήποτε άλλη υλοποίηση σε Java. Εκεί θα ορίζονται αφηρηµένες κλάσεις όπου θα πρέπει να επεκταθούν στην συγκεκριµένη υλοποίηση. Αυτό το πακέτο είναι το org.pisquared.system.generic. Η λειτουργικότητα που εξαρτάται µόνο από την Jena και αυτή που εξαρτάται µόνο από το Restlet θα µπει η καθεµία σε ξεχωριστό πακέτο. Αυτά είναι τα org.pisquared.modules.system.impl.jena και org.pisquared.modules.system.impl.restlet αντίστοιχα. Η λειτουργικότητα που εξαρτάται και από τα δυο περιλαµβάνεται στο πακέτο org.pisquared.modules.system.impl.restletjena. -63-

72 Τα προκαθορισµένα Ηandlers και Restlets περιλαµβάνονται στα πακέτα org.pisquared.modules.system.impl.restletjena.handlers και org.pisquared.modules.system.impl.restletjena.restlets αντίστοιχα. Το πάκετο org.pisquared.modules.system.vocabulary περιλαµβάνει κλάσεις λεξιλογίων για τις οντολογίες του συστήµατος, κατασκευασµένες µε το εργαλείο Schemagen της Jena. 6.2 Γενικό πακέτο Εδώ λοιπόν ορίζονται οι γενικές κλάσεις που µπορούν να χρησιµοποιηθούν σε κάθε υλοποίηση σε Java. Αυτές ορίστηκαν σε πλήρη αντιστοιχία µε τα συστατικά της σχεδίασης, του προηγούµενου κεφαλαίου: Application Αφηρηµένη κλάση που αναπαριστά µια ολόκληρη εφαρµογή π 2 υλοποίηση σε Java. σε οποιαδήποτε Ρυθµίσεις Καταρχήν µια εφαρµογή έχει κάποιες ρυθµίσεις (configuration) που πρέπει να φορτωθούν στο αντικείµενο Application. Ο τρόπος αποθήκευσης των ρυθµίσεων δεν ενδιαφέρει την αφηρηµένη κλάση, αλλά µια υποκλάση πρέπει να υλοποιεί την αφηρηµένη µέθοδο loadconfiguration(), η οποία πρέπει να φορτώνει τις ρυθµίσεις στις µεταβλητές-µέλη της κλάσης. Προς το παρόν η µόνη ρύθµιση είναι το rooturi, που είναι το URI-ρίζα της εφαρµογής. Modules Μια Application αποτελείται από Modules. Μια υποκλάση πρέπει να υλοποιεί τη µέθοδο loadmodules() που φορτώνει αντικείµενα της κλάσης Module (βλέπε παρακάτω) στο σύνολο modules. Ορίζονται οι µέθοδοι: Iterator listmodules():eπιστρέφει έναν iterator στα Modules της εφαρµογής. -64-

73 Module getmodule(string name): Επιστρέφει το Module µε όνοµα name. Module getsystemmodule(): Eπιστρέφει το module του συστήµατος. Ροές εισόδου/εξόδου σηµασιολογικών µοντέλων Μια υποκλάση της Application πρέπει να υλοποιεί την αφηρηµένη µέθοδο getimportinputstreams(), που επιστρέφει µια λίστα από ροές εισόδου (InputStream) των οντολογιών του συστήµατος (ir, system και ειδική system) και τις getsupportingmodelinputstream() και getsupportingmodeloutputstream(), που επιστρέφουν µια ροή εισόδου για ανάγνωση και µια εξόδου (OutputStream) για εγγραφή αντίστοιχα, του υποστηρικτικού µοντέλου ολόκληρης της εφαρµογής Module Αναπαριστά ένα module, τ' οποίο είναι το βασικό συστατικό του συστήµατος. Ένα module έχει ένα διακριτό όνοµα εντός της εγκατάστασης, name, που δίνεται ως παράµετρος στον constructor. Ρυθµίσεις Ένα module όπως και η εφαρµογή έχει κάποιες ρυθµίσεις που πρέπει να φορτωθούν από την υλοποίηση της loadconfiguration()µιας υποκλάσης: URI: Το URI του αφηρηµένου module του οποίου είναι εγκατάσταση το module αυτό. Ορίζεται µόνο για πρότυπα (standard) modules. kind: το είδος του module, δηλαδή το αν είναι ιδιόκτητο (own) ή επεκταµένο πρότυπο (standard extended). Η kind παίρνει τιµές απ' την απαρίθµηση Module.Kind {OWN, STANDARD_EXTENDED}. Ένα module θεωρείται ιδιόκτητο όταν δεν υπάρχει URI. initaction: η ενέργεια αρχικοποίησης του module που για την ώρα µπορεί να είναι είτε ΝΟΝΕ (καµία) είτε INSTALL (εγκατάσταση) για ένα πρότυπο module. Αν η InitAction είναι INSTALL θα πρέπει καταρχήν να γίνει επέκταση του, δηλαδή να δηµιουργηθούν µοντέλα επέκτασης για τα πρότυπα µοντέλα. Έπειτα πρέπει να φορτωθούν τα σηµασιολογικά µοντέλα του module. Οι πόροι των σηµασιολογικών µοντέλων θα πρέπει να προσαρµοστούν από τα προσωρινά namespaces στα δοσµένα στις ρυθµίσεις namespaces των υποµοντέλων του module. -65-

74 submodellocalnamespaces:map που περιέχει τα τοπικά namespaces όλων των υποµοντέλων του module, ανά είδος υποµοντέλου (ιδιόκτητο, πρότυπο, επέκταση), ανά τύπο µοντέλου (πεδίου, πολλαπλών χρήσεων, ελέγχου). Η δήλωση του είναι η εξής: protected Map<Model.Type, Map<Submodel.Kind, String>> submodellocalnamespaces; Μοντέλα Ένα module περιέχει τρία models. Καθένα από τα Models έχει έναν τύπο type από την απαρίθµηση Model.Type {DOMAIN, UTIL, CONTROL}, δηλαδή είναι τύπου πεδίου, πολλαπλών χρήσεων ή ελέγχου. Αναφορές στα Models αποθηκεύονται στις µεταβλητές-µέλη domainmodel, utilmodel, controlmodel καθώς και στο Map από Model.Type σε Model, models. Ορίζονται οι: Model getmodel(model.type modeltype): επιστέφει το Model τύπου modeltype. Model getdomainmodel(), getutilmodel(), getcontrolmodel(): επιστρέφει τα Models των αντίστοιχων τύπων. Iterator listmodels():επιστρέφει iterator στα Models. Model getmodelbylocalslashnamespace(string ns): Επιστέφει το Model που έχει τοπικό slash namespace ns. Υποµοντέλα Ένα Model αποτελείται από Submodels. Η προσπέλαση των Submodels ενός Model µπορεί να γίνει µέσω του αντικείµενου Model, αλλά για ευκολία ορίζονται στην Module και οι παρακάτω µέθοδοι: Iterator listsubmodels():επιστρέφει iterator σε όλα τα υποµοντέλα του module. Iterator liststandardsubmodels():επιστρέφει iterator µόνο στα πρότυπα υποµοντέλα, ή null αν το module είναι ιδιόκτητο. Iterator listbasesubmodels():επιστρέφει iterator µόνο στα βασικά υποµοντέλα. Αυτά είναι που µπορεί να τροποποιήσει ο χρήστης και είναι τα ιδιόκτητα υποµοντέλα για ένα ιδιόκτητο module και τα υποµοντέλα επέκτασης για ένα επεκταµένο πρότυπο module. -66-

75 Επέκταση Η υποκλάση της Module πρέπει να υλοποιεί την createextension() που θα κατασκευάζει την επέκταση του module, όπως ορίζει η εκάστοτε υλοποίηση Model Ένα Model έχει καταρχήν, όπως ήδη αναφέραµε, έναν τύπο, απ' αυτούς της απαρίθµησης Model.Type. Ονόµατα Ένα Model έχει ένα όνοµα που επιστρέφει η getname(), και είναι ο τύπος του µε πεζά γράµµατα: domain, util ή control, για χρήση σε ονόµατα φακέλων και στο query string. Το όνοµα που προορίζεται για ανθρώπινη κατανάλωση δίνεται από την gethumanname() ενώ η getfullhumanname()επιστρέφει το πλήρες όνοµα µαζί µε το όνοµα του module. Υποµοντέλα Ένα Model περιέχει ένα ή δυο Submodels. Ένα υποµοντέλo διακρίνεται από το είδος του, που είναι µια από τις τιµές της απαρίθµησης Submodel.Kind {OWN, STANDARD, EXTENSION}, δηλαδή είναι ιδιόκτητο, πρότυπο ή επέκταση. Ένα ιδιόκτητο µοντέλο έχει µόνο ένα ιδιόκτητο υποµοντέλο, το ownsubmodel, ενώ ένα επεκταµένο πρότυπο µοντέλο έχει ένα προτυπο υποµοντέλο, το standardsubmodel, και ένα υποµοντέλο-επέκταση, το extensionsubmodel. Επίσης υπάρχει το Mapsubmodels, από είδος υποµοντέλου σε υποµοντέλο, και η Submodel getsubmodel(submodel.kind submodelkind) που επιστρέφει το υποµοντέλο του είδους submodelkind. Η loadsubmodels() είναι αφηρηµένη στη Submodel και πρέπει να υλοποιείται σε µια υποκλάση, ώστε να φορτώνονται τα υποµοντέλα στις προαναφερθείσες µεταβλητές-µέλη Submodel Τελειώνοντας µε τις αφηρηµένες κλάσεις συστατικών, έχουµε την Submodel. Αυτή όπως αναφέραµε έχει ένα είδος, kind. -67-

76 Ονόµατα Η getname() επιστρέφει το kind σε πεζούς χαρακτήρες, η gethumanname() το όνοµα του υποµοντέλου για ανάγνωση από ανθρώπους ενώ η getfullhumanname() το πλήρες όνοµα, µαζί µε το όνοµα του module. Namespaces Ορίζεται η απαρίθµηση Submodel.NamespaceType {TEMP, NORMAL} όπου TEMP δηλώνει ένα προσωρινό namespace (στο πακέτο) ενώ NORMAL ένα κανονικό (σε χρήση), και οι παρακάτω µέθοδοι που έχουν να κάνουν µε τα namespaces: String getslashnamespace(namespacetype nstype): επιστρέφει το slash namespace τύπου nstype. String gettempslashnamespace(): επιστρέφει πάντα που είναι το προσωρινό namespace των πόρων του υποµοντέλου. gettempslashnamespaceforintramodulardependency(): επιστρέφει α_υποµοντέλου>. Είναι το namespace όπου περνούν οι τοπικοί ΠΠ αυτού του υποµοντέλου όταν αναφέρονται στα άλλα υποµοντέλα του ίδιου module. gettempslashnamespaceforintermodulardependency(): επιστρέφει µα_µοντέλου>/<όνοµα_υποµοντέλου>. Είναι το namespace όπου περνούν οι τοπικοί ΠΠ αυτού του υποµοντέλου όταν αναφέρονται σε άλλα modules. Για ιδιόκτητο module, είναι null. Παρόµοια ορίζονται µέθοδοι για τα sharp namespaces. 6.3 Πακέτο του Restlet Το πάκετο του Restlet, org.pisquared.modules.system.impl.restlet, περιέχει τις υποκλάσεις των προηγουµένων για την πλατφόρµα Restlet-Jena Δοµή καταλόγων Ας δούµε καταρχήν την δοµή των καταλόγων µιας εγκατάστασης της πλατφόρµας. Οι κλάσεις που θα παρουσιάσουµε αµέσως µετά αναπαριστούν καταλόγους σε αυτή τη δοµή. -68-

77 + / + imports/ // οντολογίες του συστήµατος ir.owl // οντολογία πληροφοριακών πόρων restlet-jena-system.owl // ειδική οντολογία συστήµατος system.owl // γενική οντολογία συστήµατος uris.properties // αντιστοιχία ονοµάτων αρχείων URIs - lib/ // βιβλιοθήκες Java + modules // κατάλογος των modules + <standard_extended_module_name>/ // ένα πρ. επ. module + extension/ // η επέκταση του module + control/ // υποµοντέλο ελέγχου της επέκτασης - representations/ // αναπαράστασεις των τοπικών ΠΠ support.rdf // το υποστηρικτικό µοντέλο του ontology.owl // η οντολογία του - domain/ // υποµοντέλο πεδίου της επέκτασης - util/ // υποµοντέλο πολλαπλών χρήσεων της επέκτασης - standard/ // πρότυπο κοµµάτι του module module.properties // ρυθµίσεις του module + <own_module_name>/ // ένα ιδιόκτητο module - control/ // ιδιόκτητο υποµοντέλο ελέγχου - domain/ // ιδιόκτητο υποµοντέλο πεδίου - util/ // ιδιόκτητο υποµοντέλο πολλαπλών χρήσεων module.properties // ρυθµίσεις του module PiSquared.jar // το εκτελέσιµο της εφαρµογής support.rdf // το υποστηρικτικό µοντέλο ολόκληρης της εφαρµογής application.properties // οι ρυθµίσεις της εφαρµογής jena.properties // οι ρυθµίσεις της Jena restlet.properties // οι ρυθµίσεις του Restlet Application Η υποκλάση της γενικής Application στο πακέτο του Restlet αντιστοιχεί στη ρίζα της δοµής των καταλόγων. Η υλοποίηση της loadconfiguration() φορτώνει τη ρύθµιση rooturi από το αρχείο application.properties. Οι getsupportingmodelinputstream() και getsupportingmodelinputstream() φορτώνουν από και γράφουν στο support.rdf το υποστηρικτικό µοντέλο, ενώ η getimportinputstreams() διαβάζει τις οντολογίες του συστήµατος από τον κατάλογο /imports/. Το /imports/uris.properties περιέχει τις αντιστοιχίες ονοµάτων αρχείων και -69-

78 URIs των οντολογιών. Η loadmodules() διαβάζει τους υποκαταλόγους του /modules/ και δηµιουργεί αντικείµενα Module, περνώντας στον constructor ως name το όνοµα του κάθε καταλόγου. Για κάθε module καλούνται οι loadconfiguration() και loadsubmodels(). Τέλος ορίζεται η getpath() που επιστρέφει τον µονοπάτι του καταλόγου της εφαρµογής στο δίσκο Module Η υλοποίηση της loadconfiguration() διαβάζει τις ρυθµίσεις του module από το αρχείο module.properties στον κατάλογο του module. Θ' αναφερθούµε στο αρχείο αυτό και στο επόµενο κεφάλαιο. Η υλοποίηση της createextension() κατασκευάζει τον κατάλογο extension/ στον κατάλογο του module και τη δοµή των υποκαταλόγων του. Επίσης ορίζεται η getpath() που επιστρέφει το µονοπάτι του κατάλογου του module, και η loadmodels() που θέτει αναφορές σε νέα αντικείµενα Model στις αντίστοιχες µεταβλητές-µέλη της Module Model H Model του πακέτου Restlet υλοποιεί την loadsubmodels(), που θέτει παροµοίως αναφορές σε νέα αντικείµενα Submodel στις αντίστοιχες µεταβλητές-µέλη της Model. H Model δεν αντιστοιχεί σε κάποιον συγκεκριµένο κατάλογο αλλά αντιστοιχούν τα υποµοντέλα του (ή το µοναδικό ιδιόκτητο υποµοντέλο) Submodel Υλοποιείται η getimportinputstreams() που φορτώνει τις εισαγόµενες οντολογίες από τον κατάλογο imports/ του υποµοντέλου, η getsupportingmodelinputstream() που διαβάζει το υποστηρικτικό µοντέλο του υποµοντέλου από το αρχείο support.rdf στο κατάλογο του και η getsupportingmodeloutputstream() που το γράφει εκεί, µε τρόπο αντίστοιχο των οµώνυµων κλάσεων της Application. Επίσης υλοποιούνται οι getontologyinputstream() και getontologyoutputstream() που κάνουν παρόµοια δουλειά µε την οντολογία του υποµοντέλου και το αρχείο ontology.owl. Τελικά ορίζεται οι getpath() που επιστρέφει το µονοπάτι του -70-

79 υποµοντέλου στο δίσκο και η getrepresentationspath() που επιστρέφει το µονοπάτι του καταλόγου των αναπαραστάσεων. 6.4 Πακέτο της Jena ModelManager Αυτό καταρχήν περιλαµβάνει την αφηρηµένη κλάση org.pisquared.system.impl.jena.modelmanager, που περιέχει τα φορτωµένα σηµασιολογικά µοντέλα της εφαρµογής, τα οποία είναι αντικείµενα τύπου Model, OntModel και InfModel της Jena, σ' ένα Map από String σε Model, loadedmodels, που κρατάει όλα τα φορτωµένα µοντέλα µε κλειδί το URI τους. Ορίζονται διάφορες παραλλαγές των συναρτήσεων createmodel(), createrdfsmodel(), createontmodel() που δηµιουργούν ή επιστρέφουν υπάρχοντα Models, InfModels και OntModels αντίστοιχα. H loadimports(map<string,inputstream> importedontologyinputstreams) δέχεται το Map από URIs σε ροές εισόδου των οντολογιών, που επιστρέφουν οι µέθοδοι getimportinputstreams() των κλάσεων Application και Module. Kαλεί την getimportinputstreams() της application και φορτώνει τις οντολογίες του συστηµάτων στον ModelManager. Η ModelManager δεν ορίζει ModelMaker, DocumentManager και OntModelSpec (για τα OntModels) αλλά αφήνει αφηρηµένες τις µεθόδους getmodelmaker(), getdocumentmanager()και getontmodelspec(), για να τα παρέχει η υποκλάση. Επίσης πρέπει να υλοποιηθεί η cleanmodels() που πρέπει να διαγράφει όλα τα µοντέλα από τον χώρο όπου αποθηκεύονται RDBModelManager Υποκλάση της ModelManager η org.pisquared.system.impl.jena.rdbmodelmanager που δέχεται ως παραµέτρους στον constructor της τις παραµέτρους σύνδεσης µε µια σχεσιακή βάση δεδοµένων (όνοµα βάσης και χρήστη, κωδικός πρόσβασης κλπ.). Θέτει ως ModelMaker αυτόν που επιστρέφει η ModelFactory.createModelRDBMaker() δοσµένου του αντικειµένου DBConnection της σύνδεσης µε τη βάση. Ως OntModelSpec τίθεται αυτό του -71-

80 Pellet reasoner, που είναι το PelletReasonerFactory.THE_SPEC. Τέλος ως DocumentManager τίθεται µια υποκλάση της OntDocumentManager, η org.pisquared.system.impl.jena.documentmanager, ειδικά κατασκευασµένη να µην φορτώνει ένα import από το URI του, αν βρίσκεται ήδη στη ΒΔ µοντέλο µε το URI αυτό, αλλά να χρησιµοποιεί το τελευταίο ControlAnnotationProperty Η org.pisquared.system.impl.jena.controlannotationproperty είναι από τις βασικότερες κλάσεις του συστήµατος. Αναπαριστά προφανώς µια control annotation property. Αυτή ταυτοποιείται από το όνοµα της, όχι από κάποιο URI, γιατί όπως είπαµε στο κεφάλαιο της σχεδίασης, µπορεί να αντιστοιχεί σε δυο OWL properties. Μια CAP έχει έναν τύπο, type, από τους ControlAnnotationProperty.Type {OBJECT, DATATYPE}, δηλαδή όπως και µια OWL object ή datatype property. Αν ο τύπος είναι DATATYPE πρέπει να ορίζεται και το datatype, που είναι ο τύπος δεδοµένων της ιδιότητας. Και τα δυο είδη properties µπορούν να έχουν ένα range από τιµές ως ΠΟ. Η µέθοδος Set<RDFNode> getrange(ontresource resource, Model model) επιστρέφει το ΠΟ της CAP για τον πόρο resource του µοντέλου model, ως ένα σύνολο απο RDFNodes. Μια CAP µπορεί να υπερβαίνει τη προκαθορισµένη υλοποίηση, που επιστρέφει άδειο σύνολο, και να επιστρέφει range που εξαρτάται από τον πόρο όπου θα εφαρµοστεί η ιδιότητα. Αυτό είναι κάτι που δεν µπορεί να εκφραστεί µε OWL datatype/object properties, πόσο µάλλον µε annotations. Χαρακτηριστικά Οι boolean µεταβλητές-µέλη overridableproperty, inheritedfromtype και inheritedfromclass ορίζουν το αν η CAP είναι υπερβάσιµη, κληρονοµήσιµη από τον τύπο και κληρονοµήσιµη από τη κλάση αντίστοιχα. Ορίζονται αντίστοιχοι µέθοδοι setters και getters. Αντίστοιχες ιδιότητες OWL Με την setproperty(annotationproperty property) τίθεται η αντίστοιχη µέθοδος OWL για στιγµιότυπα, ενώ µε την setproperties(annotationproperty instanceproperty, AnnotationProperty typeproperty) τίθενται και οι δυο. -72-

81 Μέθοδοι για το υποκείµενο boolean isvalidinstancesubject( OntResource resource, Model model): επιστρέφει true αν ο πόρος resource του (π 2 ) µοντέλου model είναι έγκυρο υποκείµενο για την ιδιότητα στιγµιοτύπου. Προκαθορισµένα επιστρέφει πάντα true. boolean isvalidtypesubject( OntResource resource, Model model): true αν ο πόρος resource είναι έγκυρο υποκείµενο για την ιδιότητα τύπου. Αν η CAP δεν είναι κληρονοµήσιµη από τον τύπο ή ο πόρος resource δεν είναι rdfs:class (δηλαδή δεν είναι «τύπος») ή είναι owl:class ενώ η CAP δεν είναι κληρονοµήσιµη από τη κλάση, προκαλείται IllegalArgumentException. Μέθοδοι για το αντικείµενο Object getdefaultobject(ontresource resource, Model model): Επιστρέφει την προκαθορισµένη τιµή της CAP, για τον συγκεκριµένο πόρο resource. Προκαθορισµένα είναι null, και πρέπει να παραµένει null για κληρονοµήσιµες ιδιότητες. void checkobjectvalidity(rdfnode node, OntResource resource, Model model): προκαλεί Exception µε κατάλληλο µήνυµα αν o node δεν είναι έγκυρη τιµή της CAP για τον πόρο resource. Προκαθορισµένα ελέγχει αν ο node είναι URI resource για OBJECT CAP, αν είναι literal για DATATYPE CAP, και αν υπάρχει range, αν βρίσκεται σ' αυτό. Object getobjectfromrdfnode(rdfnode node): επιστρέφει κατάλληλο Java object, ανάλογα µε τον τύπο της CAP. Συνήθως είναι String. Η checkresourcecontrolannotationpropertiesvalidity(ontresourc e resource, Model model) ελέγχει την εγκυρότητα όλων των CAPs του πόρου resource στο µοντέλο model, προκαλώντας µια Exception στην πρώτη ιδιότητα που δεν είναι σωστή. Οι CAPs του συστήµατος δηλώνονται ως αντικείµενα της ControlAnnotationProperty, αποθηκεύονται στην µεταβλητή-µέλος all που είναι ένα Map από String σε ControlAnnotationProperty και µπορούν ν' ανακτηθούν µε την getcontrolannotationproperty(string name) που επιστρέφει την ControlAnnotationProperty µε όνοµα name. -73-

82 6.5 Πακέτο Restlet και Jena Στο πακέτο org.pisquared.system.impl.restletjena περιλαµβάνονται οι κλάσεις που συνδιάζουν τις βιβλιοθήκες του Restlet µε της Jena για την παροχή της επιθυµητής λειτουργικότητας ApplicationUtils Προς το παρόν περιέχει µόνο την initializeapplication(application application) που αρχικοποιεί την εφαρµογή Application, εκτελώντας για κάθε Module την κατάλληλη ενέργεια αρχικοποίησης SemanticModelTransferrer Περιέχει µεθόδους φόρτωσης και ξεφόρτωσης των σηµασιολογικών µοντέλων της εφαρµογής και των Modules. Καταρχήν ορίζεται η απαρίθµηση SemanticModelsTransferAction {LOAD, UNLOAD} των ενεργειών φόρτωσης και ξεφόρτωσης των σηµασιολογικών µοντέλων. Φόρτωση / ξεφόρτωση σηµασιολογικών µοντέλων της εφαρµογής Η µέθοδος loadapplicationsupportingmodel(application application) φορτώνει το υποστηρικτικό µοντέλο της application στον ModelManager, καλώντας την transferapplicationsupportingmodel(application.semanticmode lstransferaction action, Application application) µε actionload. Φόρτωση / ξεφόρτωση σηµασιολογικών µοντέλων των modules Οι loadmodulesemanticmodels(module module) και unloadmodulesemanticmodels(module module) φορτώνουν και ξεφορτώνουν τα σηµασιολογικά µοντέλα του module, καλώντας τη transfermodulesemanticmodels(application.semanticmodelstran sferaction action, Module module) µε την αντίστοιχη SemanticModelsTransferAction. Η τελευταία µέθοδος κάνει χρήση των παρακάτω: -74-

83 transfersupportingmodel(application.semanticmodelstransfera ction action, Submodel submodel): µεταφέρει το υποστηρικτικό µοντέλο ενός υποµοντέλου. tranfersubmoduleontology(application.semanticmodelstransfer Action action, Submodel submodel): µεταφέρει την οντολογία ενός υποµοντέλου. getnewuri(submodel.namespacetype currentnstype, Submodel.NamespaceType newnstype, String currenturi, Submodel submodel): επιστρέφει το νέο URI τύπου newnstype (προσωρινό ή κανονικό) του τρέχοντος URI currenturi τύπου currentnstype, στο υποµοντέλο submodel. adaptontresourcecontrolannotationpropertyvalues(submodel.na mespacetype currentnstype, Submodel.NamespaceType newnstype, OntResource resource, Submodel submodel): Προσαρµόζει στο νέο namespace τύπου newnstype τις Control Annotation Properties του πόρου resource του υποµοντέλου submodel Archiver Περιέχει τις µεθόδους «πακεταρίσµατος» των modules και ολόκληρης της εφαρµογής σε αρχεία.zip, createapplicationarchive(application application) και createmodulearchive(module module), οι οποίες όµως είναι ακόµα υπό κατασκευή ModelUtils Περιέχει καταρχήν κάποιες getter µεθόδους για την ανάκτηση πόρων από ένα µοντέλο. OntResource getdescribedresource(string uri, Model model): επιστρέφει τον πόρο του οποίου η περιγραφή έχει URI uri στο µοντέλο model ή null αν δεν υπάρχει. OntResource getinformationresource(string uri, Model model): επιστρέφει τον πληροφοριακό πόρο µε το δοσµένο URI ή null αν δεν υπάρχει ή δεν είναι πληροφοριακός. ΠΠ θεωρείται και µια οντολογία. -75-

84 OntResource getresource(string uri, Model model): επιστρέφει τον πόρο µε αυτό το URI, ανεξαρτήτως τύπου. OntResource getdescribedresource(string uri, Resource type, Model model): επιστρέφει τον πόρο µε αυτό το URI και τύπου type ή null αν δεν είναι αυτού του τύπου ή αν δεν υπάρχει. Ακολουθούν οι OntModel getmodelontology(model model) και getsubmodelsupportingmodel(submodel submodel) που επιστρέφουν την οντολογία ενός µοντέλου και το υποστηρικτικό µοντέλο ενός υποµοντέλου αντίστοιχα. Τέλος περιέχονται κάποιες βοηθητικές µέθοδοι που επιστρέφουν το URI του editor βασικών τύπων πόρων, για χρήση κυρίως στον Browser ResourceUtils Μια εκτεταµένη κλάση που περιλαµβάνει µεθόδους σχετικούς µε πόρους. Μέθοδοι χαρακτηριστικών των πόρων boolean islocalresource(ontresource resource, Model model): true αν ο πόρος resource είναι τοπικός εντός του µοντέλου model, δηλαδή αν βρίσκεται σε κάποιο από τα namespaces των υποµοντέλων. boolean isimportedresource( Model model, OntResource resource): true αν ο πόρος resource είναι εισαγόµενος εντός του µοντέλου model. Εισαγόµενοι ορίζονται οι πόροι για τους οποίους υπάρχουν δηλώσεις σε εισαγόµενες οντολογίες ή και στην πρότυπη οντολογία, αν το µοντέλο είναι πρότυπο επεκταµένο. Είναι οι πόροι για τους οποίους δηλώσεις έχουµε µόνο στη βασική οντολογία του µοντέλου. Είναι οι µόνοι των οποίων τις περιγραφές µπορούµε να διαγράψουµε και να επεξεργαστούµε πλήρως. Επίσης δεν µπορούµε να επεξεργαστούµε τις αναπαραστάσεις ενός εισαγόµενου ΠΠ. Τέλος, οι πόροι που ορίζουν οι RDF, RDFS και OWL θεωρούνται και αυτοί εισαγόµενοι. Μέθοδοι ενεργειών στους πόρους deleteresourcerepresentations(resource resource, Model model): διαγράφει όλες τις αναπαραστάσεις του πόρου resource στο µοντέλο model. -76-

85 deleteresource(ontresource resource, Model model): διαγράφει τις αναπαραστάσεις και τις δηλώσεις του πόρου resourceστο µοντέλο model. Αν ο πόρος είναι τοπικός θα πρέπει να διαγράφονται και όποιες αναφορές σ' αυτόν σε εξαρτώµενα modules στο module του µοντέλου αυτού, κάτι που δεν έχει υλοποιηθεί ακόµα. Αν ο πόρος είναι εισαγόµενος, πετιέται IllegalArgumentEsxception. Control Annotation Properties Η κύρια µέθοδος που επιστρέφει τη τιµή µιας CAP ενός πόρου είναι η Object getcontrolannotationproperty(string propertyname, OntResource resource, Model model). Αυτή καλεί τις getinstancelevelcontrolannotationproperty(), getclasslevelannotationproperty() και gettypelevelcontrolannotationproperty() όποτε χρειάζεται, υλοποιώντας τα επίπεδα αναζήτησης της τιµής της CAP του αλγορίθµου στο κεφάλαιο της σχεδίασης Επισκόπηση της αρχιτεκτονικής της υλοποίησης Στο κεφάλαιο Εργαλεία είδαµε τις κλάσεις του Restlet που συµµετέχουν στο χειρισµό των αιτήσεων: συνήθως υπάρχει ένας Router ρίζας που αναθέτει τον χειρισµό των αιτήσεων σε κάποιο άλλο Restlet ή απευθείας σ έναν Handler σύµφωνα µε κάποια URI templates. Θ' ακολουθήσουµε την τακτική ενός Restlet ρίζας που θα αναθέτει τις αιτήσεις αλλού, αλλά αυτό το Restlet δεν θα είναι ένας Router. Οι Routers του Restlet µπορούν να αναθέσουν µια υποκλάση της Handler σε µια URI template, δηλαδή κάνουν χειρισµό των αιτήσεων ανάλογα µε τη σύνταξη του URI. Στη σχεδίαση που κάναµε όµως ο χειρισµός γίνεται ανάλογα µε τον χειριστή που αντιστοιχεί στον πόρο, τον οποίο επιστρέφει η CAP handler ή η descriptionhandler. Έτσι υλοποιήθηκε ο RootRestlet, µια υποκλάση της Restlet, που αναθέτει τον χειρισµό των αιτήσεων στον χειριστή που ορίζουν οι CAPs αυτές. Ένα στιγµιότυπο του RootRestlet θα προσκολλάται στην PiSquaredRestletApplication, της οποίας η createroot() θα τον δηµιουργεί ως root restlet. Ένα στιγµιότυπο της PiSquaredRestletApplication θα προσκολλάται τελικά στο προκαθορισµένο host του Component της εφαρµογής µας. -77-

86 Τι είδους χειριστές θα είναι όµως αυτοί, στους οποίους θα ανατίθενται οι αιτήσεις; Στην γενική οντολογία του συστήµατος ορίσαµε τη κλάση system:handler των ΠΠ ελέγχου αφηρηµένων «χειριστών». Στην υλοποίηση µας οι πραγµατικοί χειριστές θα είναι υποκλάσεις της Handler (κυρίως της Resource) ή της Restlet. Ορίζουµε τις κλάσεις OWL rjs:handler και rjs:restlet ως τις κλάσεις ΠΠ ελέγχου ενός Handler και ενός Restlet αντίστοιχα, ως υποκλάσεις της system:handler. Μια υποκλάση της rjs:handler θα είναι η rjs:resource ενώ της rjs:restlet η rjs:redirector, που ταυτοποιούν ΠΠ ελέγχου κλάσεων Resource και Redirector αντίστοιχα. Ορίστηκαν µόνο αυτές επειδή χρειάστηκαν για την υλοποίηση, ενώ στο µέλλον µπορεί να οριστούν και άλλες. Όλες τους ως system:handlerπεριλαµβάνονται στο ΠΟ των CAP handler και descriptionhandler. Για τις κλάσεις αυτές ορίζεται η ιδιότητα rjs:javaclassname, που είναι το (πλήρες) όνοµα της Java κλάσης της οποίας ΠΠ ελεγχου είναι ένα στιγµιότυπο τους. Στην Εικόνα 11 φαίνεται η τελική αρχιτεκτονική του συστήµατος µας. Το βέλος από τα Restlets στους Handlers δείχνει ότι ένα Restlet µπορεί κάλλιστα να αναθέσει σ' έναν Handler την αίτηση τελικά, και το βέλος πίσω στα Restlets δηλώνει ότι µπορεί να την αναθέσει σε κάποιο άλλο Restlet. Εικόνα 11 Η αρχιτεκτονική της υλοποίησης Restlet-Jena -78-