ΑΞΙΟΠΟΙΗΣΗ ΟΝΤΟΛΟΓΙΩΝ ΓΙΑ ΑΝΙΧΝΕΥΣΗ ΕΠΙΘΕΣΕΩΝ ΣΕ ΠΕΡΙΒΑΛΛΟΝΤΑ SIP

Transcript

1 ΑΞΙΟΠΟΙΗΣΗ ΟΝΤΟΛΟΓΙΩΝ ΓΙΑ ΑΝΙΧΝΕΥΣΗ ΕΠΙΘΕΣΕΩΝ ΣΕ ΠΕΡΙΒΑΛΛΟΝΤΑ SIP Η Διπλωματική Εργασία παρουσιάστηκε ενώπιον του Διδακτικού Προσωπικού του Πανεπιστημίου Αιγαίου Σε Μερική Εκπλήρωση των Απαιτήσεων για το Δίπλωμα του Μηχανικού Πληροφοριακών και Επικοινωνιακών Συστημάτων του ΑΓΓΕΛΟΥ Κ. ΚΑΥΚΑΛΑ ΕΑΡΙΝΟ ΕΞΑΜΗΝΟ 2008

2 Η ΤΡΙΜΕΛΗΣ ΕΠΙΤΡΟΠΗ ΔΙΔΑΣΚΟΝΤΩΝ ΕΠΙΚΥΡΩΝΕΙ ΤΗ ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ ΤΟΥ ΑΓΓΕΛΟΥ Κ. ΚΑΥΚΑΛΑ: ΛΑΜΠΡΙΝΟΥΔΑΚΗΣ ΚΩΝΣΤΑΝΤΙΝΟΣ, Επιβλέπων 30/06/2008 Τμήμα Μηχανικών Πληροφοριακών και Επικοινωνιακών Συστημάτων ΚΑΜΠΟΥΡΑΚΗΣ ΓΕΩΡΓΙΟΣ, Επιβλέπων Τμήμα Μηχανικών Πληροφοριακών και Επικοινωνιακών Συστημάτων ΡΟΥΣΚΑΣ ΑΓΓΕΛΟΣ, Μέλος Τμήμα Μηχανικών Πληροφοριακών και Επικοινωνιακών Συστημάτων ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΙΓΑΙΟΥ ΕΑΡΙΝΟ ΕΞΑΜΗΝΟ 2008 ii

3 ΠΕΡΙΛΗΨΗ Στην παρούσα εργασία παρουσιάζεται, η αξιοποίηση οντολογιών για την ανίχνευση επιθέσεων σε περιβάλλοντα του Session Initiation Protocol. Η πρώτη ενότητα αποτελεί μια εισαγωγή στη γλώσσα οντολογιών Ontology Web Language, που αξιοποιήθηκε για την δημιουργία του οντολογικού μοντέλου. Επιπρόσθετα, παρουσιάζεται η δομή, οι ιδιότητες και τα κυριότερα στοιχεία που απαρτίζουν μια οντολογία. Στην ενότητα που ακολουθεί, παρουσιάζεται η γλώσσα Semantic Web Rule Language, που χρησιμοποιήθηκε για τη δημιουργία κανόνων στο οντολογικό μοντέλο. Επίσης, αναλύονται οι δύο τρόποι σύνταξης των κανόνων, τα αντίστοιχα συντακτικά έκφρασης της SWRL στην RDF και την XML, όπως και οι ενσωματωμένοι κανόνες της γλώσσας που έχουν σχεδιαστεί για να παρέχουν διαλειτουργικότητα στη γλώσσα με τους υπόλοιπους διαδικτυακούς φορμαλισμούς. Στη συνέχεια, παρουσιάζεται ο βασικός τρόπος λειτουργίας του πρωτοκόλλου εγκαθίδρυσης συνόδων σε υποδομές VoIP και η δομή των μηνυμάτων του. Επιπλέον, αναφέρονται οι μηχανισμοί ασφάλειας που χρησιμοποιούνται για την αυθεντικοποίηση, τη διαφύλαξη της ιδιωτικότητας και ακεραιότητας των μηνυμάτων. Ωστόσο, αναλύονται οι τρόποι δράσης κακόβουλων χρηστών, καθώς το πρωτόκολλο παραμένει ευάλωτο σε επιθέσεις άρνησης παροχής υπηρεσιών και επιθέσεις στους μηχανισμούς ανάγνωσης και ανάλυσης των μηνυμάτων. Στην επόμενη ενότητα, παρουσιάζεται αναλυτικά το οντολογικό μοντέλο, ο τρόπος κατασκευής του και η εισαγωγή δεδομένων στο μοντέλο. Επιπρόσθετα, παρουσιάζονται οι κανόνες που αξιοποιήθηκαν για την ανίχνευση επιθέσεων στο πρωτόκολλο SIP, τα αποτελέσματα και οι χρόνοι απόκρισης του, που αποδεικνύουν την παροχή ασφάλειας του μοντέλου σε SIP υποδομές. Στην τελευταία ενότητα, καταλήγουμε στα συμπεράσματα που οδηγούμαστε από την αξιοποίηση ενός τέτοιου φορμαλισμού και αναλύονται τα χαρακτηριστικά που μπορούν υιοθετηθούν από πάροχους VoIP υπηρεσιών του ΑΓΓΕΛΟΥ Κ. ΚΑΥΚΑΛΑ Τμήμα Μηχανικών Πληροφοριακών και Επικοινωνιακών Συστημάτων ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΙΓΑΙΟΥ iii

4 ABSTRACT In this dissertation, is presented the ontology exploitation, against attacks in Session Initiation Protocol environments. The first section is an introduction to the Ontology Web Language that is exploited for the creation of the ontology model. Moreover, the structure, the characteristics and the basic elements of an ontology are presented. In the following section, the Semantic Web Rule Language, which is used for the representation of the axioms in the ontology, is presented. Also, we introduce the two syntaxes that are used to represent the rules, the corresponding syntaxes that are used to declare SWRL in RDF and XML and the built-in atoms that are designed for the interoperation of the language with other Web formalisms. In the next section, the basic operations of Session Initiation Protocol in VoIP infrastructures and the structure of its messages, are discussed. In addition, we mention the security mechanisms that are used for authentication, privacy and integrity of SIP messages. Nevertheless, SIP is subject to several vulnerabilities, so we focus on methods that a hacker can exploit to develop Denial of Service and parser attacks. In the next section, we provide analytically the ontology model, the construction method and the import of data into the model. Besides, we represent the rules that were developed for the detections of attacks in SIP, the results and the response time, that prove the benefits of safety in SIP infrastructures of the model. In the last section, we lead to the conclusions by the exploitation of such formalism and the characteristics that can be adopted from VoIP providers, are analyzed ANGELOS K. KAFKALAS Department of Information and Communication Systems Engineering UNIVERSITY OF THE AEGEAN iv

5 ΕΥΧΑΡΙΣΤΙΕΣ ΑΦΙΕΡΩΣΕΙΣ Η ολοκλήρωση της παρούσας διπλωματικής εργασίας σηματοδοτεί και το τέλος των προπτυχιακών μου σπουδών. Δράττομαι την ευκαιρία, για να ευχαριστήσω πάνω από όλα τους γονείς μου Κωνσταντίνο και Αναστασία, τον αδερφό μου Παντελή και τους συγγενείς μου Βασίλη και Μαρία για τα ψυχικά και όχι μόνο εφόδια που μου προσέφεραν σε όλη τη διάρκεια των φοιτητικών μου χρόνων. Δεν μπορώ να αφήσω απέξω από αυτό το σημείο τους φίλους που απέκτησα στο νησί της Σάμου και τους αδελφικούς μου φίλους στην Αθήνα για την στήριξη τους που με βοήθησε να υπερνικήσω αυτό τον δύσκολο στόχο. Ολοκληρώνοντας όμως, αυτό το έργο θέλω να ευχαριστήσω θερμά τους επιβλέποντες της παρούσας εργασίας. Συγκεκριμένα, τον κ. Καμπουράκη, για την πολύτιμη βοήθεια του σε καίρια σημεία καθ όλη την διάρκεια της. Ιδιαίτερα, θέλω να ευχαριστήσω τον Δημήτρη Γενειατάκη, για την καθοδήγηση και τον χρόνο που μου αφιέρωσε κατά την εκπόνηση της εργασίας. Καθώς προετοιμάζομαι για το επόμενο στάδιο των σπουδών, θα ήθελα να ευχαριστήσω σύσσωμο το διδακτικό προσωπικό του Τμήματος Μηχανικών Πληροφοριακών και Επικοινωνιακών συστημάτων, για τη γνώση, το ήθος που μου μετέδωσαν αυτά τα χρόνια και την θέληση για να προσφέρω στην επιστήμη. Κλείνοντας αυτή την ενότητα, θα ήθελα να αφιερώσω τη διπλωματική εργασία στην οικογένεια μου που με καθοδήγησαν με πίστη και με βοήθησαν να παραμείνω άνθρωπος. Εύχομαι κάποια στιγμή να τους το ανταποδώσω. ΣΑΜΟΣ 2008 ΑΓΓΕΛΟΣ ΚΑΥΚΑΛΑΣ v

6 ΠΙΝΑΚΑΣ ΠΕΡΙΕΧΟΜΕΝΩΝ ΚΕΦΑΛΑΙΟ 1 - Η OWL Εισαγωγή στην OWL Επισκόπηση της OWL Συσχετισμός των υπογλωσσών Η Δομή των OWL Οντολογιών Κεφαλίδες Οντολογιών Συνάθροιση Δεδομένων και Ιδιωτικότητα Βασικά Στοιχεία Απλές κλάσεις και αντικείμενα Απλές Ονομαζόμενες Κλάσεις Προσωπικότητες - Αντικείμενα Σχεδιασμός προς Χρήση Απλές Ιδιότητες Ορίζοντας Ιδιότητες Ιδιότητες και Τύποι Δεδομένων Ιδιότητες των Προσωπικοτήτων - Αντικειμένων Χαρακτηριστικά των Ιδιοτήτων Μεταβατικές Ιδιότητες Συμμετρικές Ιδιότητες Συναρτησιακές Ιδιότητες Ιδιότητα των Αντίθετων Αντίστροφη Συναρτησιακή Ιδιότητα Περιορισμοί Ιδιοτήτων Όλες οι τιμές από, Μερικές τιμές από Αριθμός στοιχείων Συνόλου Υπαρκτή Τιμή...28 ΚΕΦΑΛΑΙΟ 2 - Η SWRL Εισαγωγή στην SWRL Αφηρημένο Συντακτικό Επισκόπηση των Κανόνων Εύκολα Αναγνώσιμο Συντακτικό Ερμηνεία των Κανόνων Παραδείγματα Κανόνων με το συντακτικό της SWRL Ειδικό συντακτικό για την XML Παραδείγματα κανόνων με το συντακτικό της XML...41 vi

7 2.7 Ειδικό Συντακτικό για την RDF Παραδείγματα Κανόνων στο ειδικό συντακτικό της SWRL για την RDF Ενσωματωμένοι Κανόνες Ενσωματωμένοι Κανόνες για Συγκρίσεις Μαθηματικοί ενσωματωμένοι κανόνες Ενσωματωμένοι Κανόνες για Δυαδικές τιμές Ενσωματωμένοι Κανόνες για Αλφαριθμητικά Ενσωματωμένοι Κανόνες για URIs Ενσωματωμένοι κανόνες για Λίστες...47 ΚΕΦΑΛΑΙΟ 3 - ΤΟ ΠΡΩΤΟΚΟΛΛΟ SIP Εισαγωγή στο SIP Μορφή μηνυμάτων στο SIP Αιτήματα Αποκρίσεις Πεδία Κεφαλίδων Σώμα μηνύματος Επισκόπηση Λειτουργίας Αρχιτεκτονική Λειτουργίας του SIP Μηχανισμοί ασφάλειας στο SIP Αξιολόγηση των Μηχανισμών Ασφάλειας του SIP Σημεία ευπάθειας στο SIP και Άρνηση Παροχής Υπηρεσιών στα SIP Δίκτυα Επιθέσεις πλημμυρίδας στο SIP Επιθέσεις στους μηχανισμούς ανάλυσης και αναγνώρισης των SIP μηνυμάτων Επιθέσεις που βασίζονται στην σηματοδότηση του SIP...65 ΚΕΦΑΛΑΙΟ 4 - ΤΟ ΟΝΤΟΛΟΓΙΚΟ ΜΟΝΤΕΛΟ Εισαγωγή στο Οντολογιακό Μοντέλο Περιγραφής του SIP Επισκόπηση Οντολογικού Μοντέλου περιγραφής του SIP για την ασφάλεια VoIP υποδομών Κατασκευή της Οντολογίας Εισαγωγή Δεδομένων Εισαγωγή κανόνων Εξαγωγή Αποτελεσμάτων...81 ΚΕΦΑΛΑΙΟ 5 - ΣΥΜΠΕΡΑΣΜΑΤΑ ΚΑΙ ΜΕΛΛΟΝΤΙΚΗ ΕΡΓΑΣΙΑ...84 vii

8 viii

9 ΚΕΦΑΛΑΙΟ 1 - Η OWL 1.1 Εισαγωγή στην OWL Η δημιουργία των οντολογιών, ήταν ένα από τα κυριότερα θέματα που αφορούσε για αρκετά χρόνια τόσο τους ερευνητές της επιστήμης των υπολογιστών, όσο και τους φιλόσοφους. Από τις αρχές του 1990, διάφορες ερευνητικές προσπάθειες έχουν διερευνήσει την ιδέα του πώς η παρουσίαση της γνώσης από την τεχνητή νοημοσύνη θα μπορούσε να χρησιμοποιηθεί από τον παγκόσμιο Ιστό. Τα αποτελέσματα των ερευνών αυτών οδήγησαν σε γλώσσες που βασίζονταν στην HTML[1] (που ονομαζόταν SHOE), την XML[2] (που ονομαζόταν XOL και αργότερα έγινε γνωστότερη ως OIL) και διάφορες άλλες βασισμένες στην απεικόνιση γνώσης και σε προσεγγίσεις απόκτησης γνώσης. Η OWL[3] είναι μια αναθεωρητική ερευνητική προσπάθεια, βασισμένη στην DAML+OIL[4], επίσης γλώσσα οντολογιών διαδικτύου. Η W3C[5] δημιούργησε το Web Ontology Working Group, το οποίο ξεκίνησε τις εργασίες του την 1 η Νοεμβρίου του 2001 με επικεφαλής τους James Hendler και Guus Schreiber. Οι πρώτες αναφορές που αφορούσαν το συντακτικό της γλώσσας, της πηγές και τη γενική περιγραφή της δημοσιεύτηκαν τον Ιούλιο του Τα έγγραφα προδιαγραφών της OWL προτάθηκαν επίσημα από την W3C στις 10 Φεβρουαρίου του 2004 και η ομάδα εργασίας ολοκλήρωσε τις εργασίες της στις 31 Μαΐου του ιδίου έτους. Η OWL είναι ένας μείζων και συγκροτημένος φορμαλισμός για τη σχεδίαση και τη διασπορά των πληροφοριών των οντολογιών, ιδιαίτερα για τον Σημασιολογικό Ιστό (Semantic Web). Έχει ποικίλες επιρροές από διάφορες κοινότητες, στις οποίες συμπεριλαμβάνονται η RDF[6] (Resource Description Framework) και η DL[7] (Description Logics). Οι επιρροές αυτές είχαν ως αποτέλεσμα μια μεγάλη ποικιλία απαιτήσεων για την OWL, μερικές εκ των οποίων εμφανίζονται να συγκρούονται μεταξύ τους. Για αυτό τον λόγο στην OWL εμπεριέχονται πρωτοποριακές λύσεις για τη διευθέτηση αυτών των φαινομενικών συγκρούσεων. Το επίσημο συντακτικό της είναι η XML\RDF ένας τρόπος δηλαδή, να συντάσσεται η RDF στην XML. Επίσης, επειδή προέρχεται από την Description Logics, (όπου ως DL, θεωρούμε ένα μια οικογένεια λογικών κανόνων) τα σημασιολογικά της OWL παρέχονται μεταφράζοντας ένα συγκεκριμένο DL και είναι συμβατά με τα αντίστοιχα σημασιολογικά που παρέχονται για την 1

10 RDF. Συνεπώς, η OWL είναι παράλληλα ένα συντακτικό για την περιγραφή και την ανταλλαγή οντολογιών και έχει σωστά ορισμένα σημασιολογικά που παρέχουν την σημασία της οντολογίας. Οι γλώσσες οντολογιών παρέχουν πληροφορίες για τα διαφόρων τύπων αντικείμενα που περιέχονται στο πεδίο περιγραφής. Σύνολα τέτοιων περιγραφών ονομάζονται «Οντολογίες». Επομένως μπορούμε να πούμε ότι μια οντολογία είναι ένας τρόπος περιγραφής του κόσμου. Οι οντολογίες χρησιμοποιούνται στην τεχνητή νοημοσύνη, τον σημασιολογικό ιστό, τους μηχανικούς λογισμικού, την βιοϊατρική πληροφορική και την αρχιτεκτονική πληροφορίας ως μια φόρμα απεικόνισης της πληροφορίας του κόσμου ή τουλάχιστον ενός μέρους του. Για την επιστήμη των υπολογιστών, ως Οντολογία ορίζεται η αντιπροσώπευση ενός συνόλου εννοιών εντός ενός πεδίου, καθώς και οι συσχετίσεις μεταξύ αυτών των εννοιών. Χρησιμοποιείται για τη συλλογή των ιδιοτήτών και τον προσδιορισμό του πεδίου αυτού. Έχουν προταθεί διάφοροι τύποι οντολογιών, οι οποίες κατατάσσονται σε οντολογίες που δομούν τα θεμελιώδη αντικείμενα (παραδείγματος χάριν που διαιρούν τον κόσμο σε φυσικά αντικείμενα, σε φανταστικά αντικείμενα κ.ο.κ.), σε οντολογίες που παρέχουν την βάση για ευρείες περιοχές της γνώσης (παραδείγματος χάριν μια οντολογία για το ηλεκτρονικό εμπόριο) και σε οντολογίες για συγκεκριμένα πεδία εφαρμογής (παραδείγματος χάριν, που διαιρούν τις ταξιδιωτικές υπηρεσίες σε διαδικτιακές κρατήσεις πτήσεων, υπηρεσίες ενοικιάσεις αυτοκινήτων, κλπ.). Η συγκεκριμένη γλώσσα μπορεί να χρησιμοποιηθεί για την κατασκευή των περισσότερων τύπων οντολογιών, αν και οι εντολές πρώτου επιπέδου λογικής είναι περισσότερο εκφραστικές από ότι η OWL και για αυτό το λόγο κάποιοι περισσότερο εξειδικευμένοι τύποι οντολογιών δεν μπορούν να εκφραστούν χρησιμοποιώντας την OWL. 2

11 1.2 Επισκόπηση της OWL Η OWL παρέχει τρεις «υπογλώσσες» αυξανόμενης εκφραστικότητας, που σχεδιάστηκαν για να χρησιμοποιηθούν από ορισμένες κοινότητες χρηστών όπως οι προγραμματιστές. Η OWL Lite υποστηρίζει αυτούς τους χρήστες που κυρίως χρειάζονται κατηγοριοποιημένη ιεραρχία και απλούς περιορισμούς. Για παράδειγμα, ενώ υποστηρίζει περιορισμούς του αριθμού των στοιχείων ενός σύνολου (cardinality), επιτρέπει τιμές του 0 ή 1. Επιπρόσθετα, είναι ευκολότερο να δημιουργηθεί ένα εργαλείο που θα υποστηρίζει τη χρήση της OWL Lite, σε αντίθεση με τις άλλες δυο «υπογλώσσες» που είναι περισσότερο εκφραστικές. Η OWL DL υποστηρίζει τους χρήστες που χρειάζονται μέγιστη εκφραστικότητα διατηρώντας παράλληλα υπολογιστική πληρότητα (εγγυάται ότι όλα τα συμπεράσματα είναι υπολογίσιμα). Η OWL DL περιέχει οτιδήποτε μπορεί να κατασκευαστεί από αυτές τις τρεις γλώσσες, άλλα μπορεί να χρησιμοποιηθεί κάτω από ορισμένους περιορισμούς (για παράδειγμα, ενώ μια κλάση μπορεί να είναι υποκλάση πολλών κλάσεων, δε μπορεί να είναι αντικείμενο κάποιας άλλης κλάσης). Η OWL Full χρησιμοποιείται από χρήστες που απαιτούν μέγιστη εκφραστικότητα και τη συντακτική ελευθερία της RDF χωρίς υπολογιστικές εγγυήσεις. Για παράδειγμα, στη συγκεκριμένη υπογλώσσα μια κλάση μπορεί να θεωρηθεί ως μια συλλογή αντικειμένων αλλά και αυτούσια ως αντικείμενο. Ωστόσο είναι σχεδόν αδύνατο ότι θα υπάρξει λογισμικό εργαλείο που θα μπορεί να αντικατοπτρίζει όλα τα χαρακτηριστικά της OWL Full. Οι χρήστες οντολογιών που χρησιμοποιούν την OWL θα πρέπει να γνωρίζουν ποια από τις τρεις παραπάνω υπογλώσσες ταιριάζει καλύτερα στις ανάγκες τους. Η επιλογή ανάμεσα στην OWL Lite και την OWL DL εξαρτάται από το αν ο χρήστης απαιτεί μεγαλύτερη εκφραστικότητα που παρέχεται και από την OWL Full. Επίσης η επιλογή ανάμεσα στη OWL DL και την OWL Full κυρίως εξαρτάται από το αν ο χρήστης απαιτεί τη χρήση των διαδικασιών του μετα-μοντέλου του RDF σχήματος (για παράδειγμα αν θέλει να προσδιορίσει κλάσεις κλάσεων ή να εισάγει ρυθμίσεις στις κλάσεις). 3

12 Στον πίνακα 1 παρουσιάζονται αναλυτικά οι διαφορές μεταξύ των τριών υπογλωσσών, οι οποίες αφορούν κυρίως, τον προσδιορισμό των κλάσεων και τις συσχετίσεις μεταξύ αντικειμένων ή δεδομένων: OWL: Lite DL Full Θεωρητικά, κανένα Θεωρητικά, κανένα αρχείο της RDF, Όλα τα έγκυρα αρχεία Συμβατότητα αρχείο της RDF, μπορεί μπορεί να θεωρηθεί της RDF, είναι και OWL με την RDF να θεωρηθεί συμβατό με συμβατό με την OWL Full αρχεία την OWL DL Lite Απαιτεί διαχωρισμό Απαιτεί διαχωρισμό των Περιορισμοί των κλάσεων, των κλάσεων, των Οι κλάσεις μπορούν να στον περιπτώσεων, των περιπτώσεων, των είναι ταυτόχρονα προσδιορισμό συσχετίσεων και των συσχετίσεων και των αντικείμενα, ή ιδιότητες μιας κλάσης τιμών δεδομένων τιμών δεδομένων Περιορίζει την Πρόσμειξη με πρόσμειξη RDF και την RDF OWL Η μόνη περιγραφή κλάσεων που είναι Περιγραφές διαθέσιμη στην OWL κλάσεων Lite είναι η IntersectionOf (τομή) Μεταβλητές αριθμών Cardinality: 0/1 στοιχείών ενός MinCardinality: 0/1 συνόλου MaxCardinality: 0/1 (Cardinality) owl:allvaluesfrom (όλες οι τιμές από) Μεταβλητές Owl:someValuesFrom τιμών (μερικές τιμές από) Η owl:valuefrom θα Περιορίζει την Δεν υπάρχει περιορισμός πρόσμειξη RDF και πρόσμειξης OWL και OWL RDF Οι κλάσεις μπορούν να Οι κλάσεις μπορούν να περιγραφούν ως: περιγραφούν ως: UnionOf (ένωση), UnionOf (ένωση), ComplementOf ComplementOf (συμπλήρωμα), (συμπλήρωμα), IntersectionOf και IntersectionOf και enumeration enumeration (απαρίθμηση) (απαρίθμηση) Cardinality >=0 Cardinality >=0 MaxCardinality >=0 MaxCardinality >=0 MinCardinality >=0 MinCardinality >=0 Owl:allValuesFrom Owl:allValuesFrom Owl:someValueFrom Owl:someValueFrom Owl:hasValue Owl:hasValue (έχει τιμή) 4

13 πρέπει να είναι όνομα κλάσης. Η owl:class είναι Η owl:class είναι Η owl:class είναι ίση με Κλάσεις υποκλάση της υποκλάση της την RDFS:Class RDFS:Class RDFS:Class Επιτρέπεται. Συνεπώς η RDF και η OWL Μετα-μοντέλο Δεν επιτρέπεται Δεν επιτρέπεται μπορούν να επαυξηθούν ή να επαναπροσδιοριστούν Πίνακας [1] - Διαφορές OWL Lite, OWL DL και OWL Full Συσχετισμός των υπογλωσσών Η επιλογή της καταλληλότερης υπογλώσσας βασίζεται στις ανάγκες εκφραστικότητας του μοντέλου που αποτυπώνεται. Θα πρέπει να σημειωθεί ότι υπάρχουν ακριβείς έννοιες στη συμβατότητα καθώς γίνεται μετάβαση από τα ανώτερα επίπεδα στα κατώτερα των παραπάνω υπογλωσσών. Συγκεκριμένα, ισχύουν οι ακόλουθες συσχετίσεις μεταξύ των OWL Lite, OWL DL και OWL Full: Κάθε κανονική οντολογία της OWL Lite είναι ταυτόχρονα και κανονική οντολογία της OWL DL. Κάθε κανονική οντολογία της OWL DL είναι ταυτόχρονα και κανονική οντολογία της OWL Full. Κάθε έγκυρο συμπέρασμα στην OWL Lite είναι ταυτόχρονα και έγκυρο συμπέρασμα για την OWL DL. Κάθε έγκυρο συμπέρασμα στην OWL DL είναι ταυτόχρονα και έγκυρο συμπέρασμα για την OWL Full. Εξαιτίας των παραπάνω απαιτείται προσοχή όταν ένας χρήστης θέλει να μετατρέψει ένα RDF έγγραφο σε OWL. Όταν ο χρήστης κρίνει ότι καλύπτεται από την εκφραστικότητα της OWL Lite και της DL, θα πρέπει να είναι επιφυλακτικός και να βεβαιωθεί ότι το αρχικό έγγραφο της RDF συμμορφώνεται με τους κανονισμούς που ισχύουν για αυτές τις δύο υπογλώσσες. Μεταξύ άλλων, κάθε URI [12] (Uniform Resource Identifier) που χρησιμοποιείται ως όνομα κλάσης θα πρέπει οπωσδήποτε να είναι της μορφής owl:class, κάθε αντικείμενο θα πρέπει να ανήκει τουλάχιστον σε μια κλάση (ακόμα και στην owl:thing) και όλα τα URI s που χρησιμοποιούνται για τις 5

14 κλάσεις, τα χαρακτηριστικά και τα αντικείμενα θα πρέπει να είναι αμοιβαίως αποκλειόμενα. Όπου ως URI ορίζεται, ένα σύνολο από χαρακτήρες και αναγνωριστικά που ορίζουν μια συνοπτική ή φυσική πηγή δεδομένων. Οι σύγχρονες οντολογίες έχουν αρκετές δομικές ομοιότητες, ανεξάρτητα από την γλώσσα που εκφράζονται. Όπως αναφέρεται παραπάνω, οι περισσότερες οντολογίες περιγράφουν, προσωπικότητες (Individuals), κλάσεις, χαρακτηριστικά και συσχετίσεις. Όλα αυτά θα συζητηθούν αναλυτικότερα στην συνέχεια. 1.3 Η Δομή των OWL Οντολογιών Όπως προαναφέρθηκε η OWL είναι μέρος του Σημασιολογικού Ιστού. Η προσπάθεια αυτή έχει ως κύριο στόχο να κάνει τις διαδικτυακές πηγές ευκολότερα προσβάσιμες στις αυτοματοποιημένες διαδικασίες, προσθέτοντας πληροφορίες για αυτές που περιγράφουν ή παρέχουν Διαδίκτυο περιεχόμενο. Καθώς ο σημασιολογικός ιστός βρίσκεται στα αρχικά στάδια διανομής του, η OWL θα πρέπει να επιτρέπει τη συλλογή πληροφοριών από κατανεμημένες πηγές. Αυτό έχει εν μέρει σήμερα πραγματοποιηθεί, επιτρέποντας στις οντολογίες να συσχετίζονται και να εισάγουν τις πληροφορίες τους από άλλες οντολογίες. Επιπρόσθετα, η OWL ενστερνίζεται την αντίληψη του ανοιχτού κόσμου (Open World Assumption)[8],σύμφωνα με την οποία η αληθής τιμή μιας πρότασης είναι ανεξάρτητη, από το ενδεχόμενο ένας παρατηρητής ή ένας πράκτορας να γνωρίζει ότι είναι αληθής. Αντίθετα, στην αντίληψη του κλειστού κόσμου (Closed World Assumption)[9] κάθε ενδεχόμενο που δεν γνωρίζουμε ότι είναι αληθές, θεωρείται ταυτόχρονα ψευδές. Συνεπώς οι περιγραφές των πηγών δεν περιορίζονται σε ένα αρχείο ή ένα πεδίο. Αντίθετα, στην OWL δεν υποστηρίζεται η αντίληψη μοναδικών ονομάτων (Unique Name Assumption)[10], που υποστηρίζεται στην Description Logics, συνεπώς διαφορετικά ονόματα σε στοιχεία μιας οντολογίας δεν αποδεικνύουν το ενδεχόμενο ότι τα στοιχεία αυτά είναι διαφορετικά μεταξύ τους. Ωστόσο, οι κανόνες owl:sameas και owl:differentfrom, χρησιμοποιούνται για να δηλώσουν ότι συγκεκριμένα στοιχεία μιας οντολογίας είναι ίδια ή διαφορετικά μεταξύ τους. Προκειμένου να γραφτεί μια οντολογία η οποία θα μπορεί να ερμηνευτεί και να χρησιμοποιηθεί από ένα αυτόματο πράκτορα, απαιτείται ένα συντακτικό και μια επίσημη σημασιολογία για την OWL. Η OWL αποτελεί μια επέκταση του λεξιλόγιου της RDF. 6

15 Πριν κάνουμε χρήση οποιονδήποτε όρων, χρειαζόμαστε μια ακριβή ένδειξη των λεξιλογίων που χρησιμοποιούμε. Ο συνήθης τρόπος με τον οποίο ξεκινά μια οντολογία, είναι ένα πεδίο, που περιλαμβάνει ένα σύνολο XMLNamespace δηλώσεων, εσώκλειστες σε μια ανοιχτή ετικέτα rdf:rdf (<rdf:rdf>). Όπου ως XMLNamespace[11] ορίζεται ένα σύνολο ονομάτων που αναγνωρίζονται από μια αναφορά URI και χρησιμοποιούνται σε αρχεία XML ως τύποι στοιχείων ή ως τύποι ιδιοτήτων. Οι δηλώσεις αυτές παρέχουν μια σαφή ερμηνεία των προσδιοριστικών και καθιστούν την υπόλοιπη παρουσίαση της οντολογίας καλύτερα αναγνώσιμη. Μια τυπική OWL Οντολογία ξεκινά με μια δήλωση namespace όπως η παρακάτω. Βέβαια τα URIs των καθορισμένων οντολογιών δεν θα είναι πάντα αναφορές του τύπου w3c.org : <rdf:rdf xmlns =" /wine#" xmlns:vin =" /wine#" xml:base =" /wine#" xmlns:food=" /food#" xmlns:owl =" xmlns:rdf =" xmlns:rdfs=" xmlns:xsd =" Στην προηγούμενη οντολογία οι πρώτες δυο δηλώσεις αναγνωρίζουν το namespace που σχετίζεται με αυτή. Συγκεκριμένα, η πρώτη θέτει το namespace ως το προεπιλεγμένο, δηλώνοντας ότι κατάλληλα ονόματα που δεν έχουν πρόθεμα αναφέρονται σε αυτή την οντολογία. Η δεύτερη αναγνωρίζει το namespace αυτής της συγκεκριμένης οντολογίας με το πρόθεμα vin:. Η τρίτη αναγνωρίζει το βασικό URI για αυτό το αρχείο, ενώ η τέταρτη αναγνωρίζει το namespace της υποστηριζόμενης οντολογίας φαγητών με το πρόθεμα food:. H επόμενη δήλωση namespace μας αναφέρει ότι στο αρχείο αυτό, τα στοιχεία που έχουν ως πρόθεμα το owl: θα πρέπει να αναγνωρίζονται ως αντικείμενα που αναφέρονται σε απεικονίσεις από το namespace Σε αυτή τη μορφή είναι η συνήθης δήλωση OWL, που χρησιμοποιείται για την περιγραφή του OWL λεξιλογίου. Η OWL εξαρτάται από κατασκευαστές που ορίζονται από τύπους δεδομένων RDF, RDFS XML σχημάτων. Στο αρχείο αυτό, τα προθέματα rdf: αναφέρονται σε απεικονίσεις αντικειμένων από το namespace Οι επόμενες δύο 7

16 δηλώσεις των namespace δημιουργούν πανομοιότυπες αναφορές για τους τύπους δεδομένων RDF Schema (rdfs:) και XML Schema (xsd:). Για την αποφυγή συνεχούς αναφοράς σε τόσο μεγάλα URIs, είναι χρήσιμο να δημιουργούμε ένα σύνολο ορισμών οντοτήτων σε ένα DOCTYPE αρχείο (αρχείο τύπου δηλώσεων), το οποίο προηγείται του ορισμού των οντολογιών. Τα ονόματα που ορίζονται από τις δηλώσεις των namespace έχουν σχεδόν ίδιο νόημα με μέρη των XML ετικετών. Οι τιμές των ιδιοτήτων των οντολογιών δεν χρειάζονται τόσο αναλυτικές δηλώσεις namespace. Ωστόσο συνηθίζεται στην OWL να γίνεται αναφορά σε μηχανισμούς ανάλυσης και αναγνώρισης οντολογιών χρησιμοποιώντας τιμές ιδιοτήτων. Οι οποίοι μπορούν να γραφούν στην αναλυτική τους μορφή όπως για παράδειγμα /wine#merlot. Εναλλακτικά συντομεύσεις μπορούν να οριστούν χρησιμοποιώντας ορισμούς οντοτήτων (ENTITY), ένα παράδειγμα ακλουθεί στην συνέχεια : <!DOCTYPE rdf:rdf [ <!ENTITY vin " /wine#" > <!ENTITY food " /food#" > ]> Μετά από τις παραπάνω δηλώσεις μπορούμε να χρησιμοποιούμε την τιμή vin;merlot η οποία θα αναλύεται σε /wine#merlot. Σημειώνεται ότι, οι δηλώσεις των namespace rdf:rdf μπορούν να απλοποιηθούν, έτσι ώστε οι αλλαγές που γίνονται στον ορισμό των οντοτήτων να πολλαπλασιάζονται κατά την δημιουργία της οντολογίας. <rdf:rdf xmlns ="&vin;" xmlns:vin ="&vin;" xml:base ="&vin;" xmlns:food="&food;" xmlns:owl =" xmlns:rdf =" xmlns:rdfs=" xmlns:xsd =" 8

17 1.3.1 Κεφαλίδες Οντολογιών Από τη στιγμή που δηλωθούν τα namespaces, συνήθως περιλαμβάνουμε μια συλλογή δηλώσεων για την οντολογία, οι οποίες εμπερικλείονται σε μια ετικέτα owl:ontology. Αυτές οι ετικέτες έχουν τόσο σημαντική χρήση όσο τα σχόλια των γλωσσών προγραμματισμού, την έκδοση και την αναφορά σε άλλες οντολογίες για χρήση των ιδιοτήτων τους. <owl:ontology rdf:about=""> <rdfs:comment>an example OWL ontology</rdfs:comment> <owl:priorversion rdf:resource=" <owl:imports rdf:resource=" <rdfs:label>wine Ontology</rdfs:label> Στην ουσία δηλαδή, το αντικείμενο owl:ontology αποτελεί ένα μέρος για την συλλογή των περισσότερων OWL μετα-δεδομένων, για το αρχείο. Βέβαια δεν εγγυάται απόλυτα ότι το αρχείο περιγράφει μια οντολογία με τον συνήθη τρόπο. Σε μερικές κοινότητες οι οντολογίες δεν δημιουργούνται για τα αντικείμενα, αλλά μόνο για τις κλάσεις και τις ιδιότητες που ορίζουν ένα πεδίο. Όταν η οντολογία χρησιμοποιείται για την περιγραφή μιας συλλογής αντικειμένων οι ετικέτες owl:ontology μπορούν να χρησιμοποιηθούν για την καταγραφή της έκδοσης και για τη δήλωση των ορισμών, στους οποίους το αρχείο βασίζεται. Για τον λόγο αυτό, στην OWL ο όρος οντολογία, έχει διευρυνθεί για να συμπεριλαμβάνει δεδομένα αντικειμένων. Το χαρακτηριστικό rdf:about παρέχει ένα όνομα ή μια αναφορά για την οντολογία, όπου η τιμή του χαρακτηριστικού είναι στην πρότυπη μορφή και το όνομα της οντολογίας είναι η βάση του URI στο αντικείμενο owl:ontology. Τυπικά, αυτό είναι το URI του αρχείου που περιέχει την οντολογία. Εξαίρεση σε αυτό αποτελεί ένα πλαίσιο που χρησιμοποιεί το πεδίο xml:base το οποίο μπορεί να θέσει το βασικό URI για ένα αντικείμενο, έτσι ώστε να είναι διαφορετικό από το URI του συγκεκριμένου αρχείου. Το πεδίο rdfs:comment παρέχει την προφανή δυνατότητα σχολιασμού μιας οντολογίας. To πεδίο owl:imports παρέχει ένα μηχανισμό πανομοιότυπο με τη χρήση του include στις γνωστές γλώσσες προγραμματισμού. Πιο συγκεκριμένα δέχεται μια μοναδική τιμή, που αναγνωρίζεται από το χαρακτηριστικό rdf:resource. Η εισαγωγή μιας οντολογίας σε μια άλλη, παρέχει όλους τους ισχυρισμούς, από τους οποίους αποτελείται. Για την καλύτερη χρήση της οντολογίας που καλείται, θα πρέπει να συσχετιστεί με δήλωση του namespace της. Θα πρέπει να δοθεί ιδιαίτερη προσοχή, έτσι ώστε να κατανοήσουμε 9

18 την διαφορά των δύο αυτών μηχανισμών. Οι αρχικές δηλώσεις των namespaces, παρέχουν κατάλληλους μηχανισμούς που επιτρέπουν την χρήση του λεξιλογίου που αντιστοιχεί σε κάθε namespace. Ενώ, το πεδίο owl:import χρησιμοποιείται ως ένδειξη της πρόθεσης μας να συμπεριλάβουμε τις ιδιότητες και τα στοιχεία της οντολογίας που επιλέγεται. Αξίζει να σημειωθεί ότι ο μηχανισμός owl:imports, δεν δουλεύει κάθε φορά επιτυχώς. Όπως αναμένουμε στη χρήση του Σημασιολογικού Ιστού, η πρόσβαση στις πηγές που είναι κατανεμημένες στο διαδίκτυο δεν είναι πάντα πιθανή. Ωστόσο εργαλεία θα αντιμετωπίζουν αυτή την κατάσταση, αποθηκεύοντας τοπικά τις ζητούμενες οντολογίες για μεταγενέστερη χρήση. Ένα επιπρόσθετο σετ παρόμοιων πεδίων που θα μπορούσε να επισημανθεί, είναι μερικά από τα πρότυπα πεδία μετα-δεδομένων του Dublin Core. Αυτό το σετ περιέχει πεδία που δέχονται απλούς τύπους ή αλφαριθμητικά ως τιμές. Παραδείγματα αυτών είναι τα Title (τίτλος), Creator(δημιουργός), Publisher (εκδότης) και Date (ημέρα). Οι ιδιότητες που χρησιμοποιούνται ως σχόλια θα πρέπει να ορίζονται όπως στο ακόλουθο παράδειγμα : <owl:annotationproperty rdf:about="&dc;creator" /> H OWL παρέχει διάφορους μηχανισμούς για να συσχετίζει την οντολογία με αυτές που η συγκεκριμένη οντολογία καλεί. Επίσης θα πρέπει να συμπεριλαμβάνουμε ένα πεδίο rdfs:label για να υποστηρίζονται ετικέτες φυσικής γλώσσας στην οντολογία μας. Ο ορισμός της κεφαλίδας της οντολογίας μας κλείνει με την ετικέτα : </owl:ontology> Συνάθροιση Δεδομένων και Ιδιωτικότητα Η ικανότητα της OWL να εκφράζει οντολογικές πληροφορίες, για αντικείμενα που εμφανίζονται σε πολλαπλά αρχεία, υποστηρίζει και διασύνδεση των δεδομένων από διαφορετικές πηγές με ένα καθορισμένο τρόπο. Πιο συγκεκριμένα, η ικανότητα της Owl να εκφράζει ισοδυναμία χρησιμοποιώντας την ετικέτα owl:sameas μπορεί να χρησιμοποιηθεί για να εκφράσει ότι αντικείμενα που φαινομενικά φαίνονται διαφορετικά, είναι στην ουσία τα ίδια. Η ετικέτα owl:inversefunctionalproperty μπορεί επίσης, να χρησιμοποιηθεί για να συνδέσει αντικείμενα μεταξύ τους. Για παράδειγμα, αν ένα χαρακτηριστικό όπως ο Αριθμός κοινωνικής ασφάλισης έχει την παραπάνω ιδιότητα, τότε θα μπορούσε να προκύψει ότι, δυο διαφορετικά αντικείμενα είναι ίδια καθώς έχουν την ίδια τιμή του χαρακτηριστικού. Όταν αντικείμενα καθορίζεται να είναι ίδια από τέτοιες έννοιες, οι πληροφορίες για αυτά που είναι από διαφορετικές πηγές μπορούν να 10

19 συγχωνευτούν. Αυτή η συνάθροιση μπορεί να χρησιμοποιηθεί για να καθορίσει γεγονότα, τα οποία δεν είναι άμεσα εμφανή από της πηγές των πληροφοριών. Η ικανότητα του Σημασιολογικού Ιστού να συγχωνεύει πληροφορίες από διάφορες πηγές αποτελεί ένα ισχυρό χαρακτηριστικό που μπορεί να χρησιμοποιηθεί από πολλές εφαρμογές. Εντούτοις, η δυνατότητα συγχώνευσης των δεδομένων από πολλαπλές πηγές, σε συνδυασμό με την επαγωγική δύναμη της OWL μπορεί να οδηγεί σε καταχρήσεις. Επίσης, οι χρήστες της συγκεκριμένης γλώσσας θα πρέπει να προσέχουν πιθανές περιπτώσεις ευπάθειας. Λεπτομερείς λύσεις ασφάλειας εξετάστηκαν από την ομάδα εργασίας, ενώ διάφοροι οργανισμοί, αντιμετωπίζουν αυτά τα ζητήματα με ποικίλες λύσεις ασφάλειας Βασικά Στοιχεία Τα περισσότερα από τα βασικά στοιχεία της OWL έχουν να κάνουν με τις κλάσεις, τα χαρακτηριστικά, τα αντικείμενα των κλάσεων και τις σχέσεις μεταξύ των αντικειμένων. Τα κυριότερα στοιχεία που στο σύνολο τους δημιουργούν μια οντολογία περιγράφονται στη συνέχεια: Individuals (Προσωπικότητες - Αντικείμενα): περιπτώσεις ή αντικείμενα. Classes (Κλάσεις): σύνολα, συλλογές, έννοιες ή τύποι αντικειμένων. Attributes (Ιδιότητες): ιδιότητες, χαρακτηριστικά γνωρίσματα, ή παράμετροι που μπορούν να έχουν τα αντικείμενα ή οι κλάσεις. Relations (Σχέσεις): τρόποι με τους οποίους τα αντικείμενα ή οι κλάσεις μπορούν να συσχετίζονται μεταξύ τους. Function Terms (Κανόνες Λειτουργίας): περίπλοκες δομές που δημιουργούνται από συγκεκριμένες δομές και μπορούν να χρησιμοποιηθούν αντί ενός μεμονωμένου όρου. Restrictions (Περιορισμοί): τυπικές περιγραφές του τι θεωρείται σωστό ούτως ώστε κάποιος ισχυρισμός να γίνει αποδεκτός για εισαγωγή στο μοντέλο. Rules (Κανόνες): δηλώσεις της μορφής if then προτάσεων που περιγράφουν σε λογικά συμπεράσματα που μπορούν να προέλθουν από ένα ισχυρισμό. Axioms (Αξιώματα): ισχυρισμοί σε λογική μορφή που στο σύνολο τους οδηγούν στην γενική θεωρία του πεδίου που περιγράφει η οντολογία. Events (Γεγονότα): η αλλαγή χαρακτηριστικών ή σχέσεων. 11

20 1.3.4 Απλές κλάσεις και αντικείμενα Οι περισσότεροι χρήστες εξαρτώνται από την ικανότητα απεικόνισης των αντικειμένων. Για να γίνει αυτό στην πράξη, χρειαζόμαστε ένα μηχανισμό για την περιγραφή των κλάσεων στις οποίες τα αντικείμενα ανήκουν και τα χαρακτηριστικά που κληρονομούν λόγω αυτής της ιδιότητας. Μπορούμε ανα πάσα στιγμή να εισάγουμε συγκεκριμένα χαρακτηριστικά στα αντικείμενα, αλλά το δυνατότερο σημείο των οντολογιών προέρχεται από τη βασιζόμενη στις κλάσεις απεικόνιση. Μερικές φορές χρειάζεται να δείξουμε έμφαση στην διαφορά μεταξύ μίας κλάσης που την δεχόμαστε ως αντικείμενο και μιας κλάση που την δεχόμαστε ως ένα σύνολο που περιέχει στοιχεία. Το σύνολο των στοιχείων που είναι μέρος μιας κλάσης αναφέρεται ως προέκταση της κλάσης Απλές Ονομαζόμενες Κλάσεις Οι βασικότερες έννοιες σε ένα πεδίο, συσχετίζονται με κλάσεις που είναι ρίζες σε διάφορα ταξινομικά δέντρα. Κάθε αντικείμενο στην OWL είναι μέλος της κλάσης owl:thing. Αρά λοιπόν κάθε κλάση που ορίζει ο χρήστης είναι αυτομάτως υποκλάση της owl:thing. Οι ρίζες συγκεκριμένων πεδίων ορίζονται απλά δηλώνοντας μια ονομαζόμενη κλάση. Επίσης η OWL ορίζει την κενή κλάση owl:nothing. Στο παράδειγμα μας προσπαθούμε να ορίσουμε ένα μοντέλο περιγραφής οίνων, για αυτό το λόγο κατασκευάζουμε τρεις κλάσεις ρίζες: Winery (Οινοποιείο), Region (Περιοχή) και ConsumableThing (Αναλώσιμο Προϊόν). <owl:class rdf:id="winery"/> <owl:class rdf:id="region"/> <owl:class rdf:id="consumablething"/> Σημειώνεται ότι έχει γίνει αναφορά σε κλάσεις οι οποίες έχουν ονοματοδοθεί και βρίσκονται στα πεδία rdf:id=. Τυπικά, δεν ξέρουμε σχεδόν τίποτα για αυτές τις κλάσεις εκτός από την ύπαρξή τους και τη σημασία που παρέχεται από τη χρήση των γνωστών αγγλικών όρων. Παράλληλα, όσο οι κλάσεις υπάρχουν, μπορεί να μην έχουν αντικείμενα ως μέλη τους. Από όσα 12

21 γνωρίζουμε για αυτές μέχρι στιγμής θα μπορούσαν να ονομαστούν Thing1, Thing2 και Thing3. Χρησιμοποιούμε το rdf:id= Region για να εισάγουμε το όνομα ως μέρος του ορισμού του. Αυτό είναι το rdf:id attribute που είναι όμοιο με το γνωστό χαρακτηριστικό ID που χρησιμοποιείται στην XML. Εντός αυτού του αρχείου θα μπορούμε να αναφερόμαστε χρησιμοποιώντας την έκφραση #Region για παράδειγμα rdf:resource= #Region. Οι υπόλοιπες οντολογίες θα μπορούν να αναφέρονται σε αυτό το όνομα χρησιμοποιώντας την πλήρη μορφή: " Μια άλλη μορφή αναφοράς χρησιμοποιεί το συντακτικό rdf:about= #Region για να επεκτείνει τον ορισμό μιας πηγής. Η χρήση του rdf:about= &ont;#x αποτελεί ένα από τα σημαντικότερα στοιχεία για τη δημιουργία μιας κατανεμημένης οντολογίας. Επιτρέπει την επέκταση του αρχείου που περιέχει τον ορισμό της χ χωρίς να μετατρέπεται το αρχικό αρχείο και υποστηρίζεται η ανάπτυξη μιας μεγαλύτερης οντολογίας. Από εδώ και στο εξής μπορούμε να αναφερόμαστε σε κλάσεις που έχουμε ορίσει σε άλλες OWL κατασκευές χρησιμοποιώντας το αναγνωριστικό τους, δηλαδή το όνομα τους. Για την πρώτη κλάση, εντός του συγκεκριμένου αρχείου, μπορούμε να χρησιμοποιούμε το σχετικό αναγνωριστικό της, δηλαδή το #Winery. Αναφορές σε αυτή την κλάση μπορούν να γίνουν επίσης και από άλλα αρχεία. Ο λογικότερος τρόπος να γίνει αυτό, είναι να εισάγουμε το namespace και τους ορισμούς οντοτήτων που εμπεριέχουν το αρχείο που περιγράφει τη συγκεκριμένη οντολογία με κώδικα :... <!ENTITY vin " /wine#" > <!ENTITY food " /food#" >... <rdf:rdf xmlns:vin =" /wine#" xmlns:food=" /food#"... >... Χρησιμοποιώντας αυτούς τους ορισμούς θα μπορούμε να αναφερόμαστε στην κλάση της οινοποιίας, είτε χρησιμοποιώντας την XML ετικέτα vin:winery ή το χαρακτηριστικό &vin;winery. Επιπρόσθετα είναι πάντα πιθανό να αναφερόμαστε σε μια οντολογία χρησιμοποιώντας ολόκληρο το URI της : 13

22 Ο θεμελιώδης κατασκευαστής (constructor) για τις κλάσεις είναι ο rdfs:subclassof. Αυτός συσχετίζει μια συγκεκριμένη κλάση με μια γενικότερη κλάση. Για παράδειγμα αν η Χ είναι υποκλάση του Y, τότε κάθε αντικείμενο του X είναι επίσης αντικείμενο της Y. Η σχέση rdfs:subclassof είναι μεταβατική. Εάν η κλάση X είναι υποκλάση της Y και η Y είναι υποκλάση της Ζ τότε η Χ είναι υποκλάση του Z <owl:class rdf:id="potableliquid"> <rdfs:subclassof rdf:resource="#consumablething" /> </owl:class> Ορίζουμε το PortableLiquid (υγρά που επιτρέπεται να καταναλωθούν) να είναι υποκλάση του ConsumableThing. Στον κόσμο των οντολογιών που βασίζονται σε δίκτυα, οι δυο αυτές κλάσεις θα μπορούσαν να οριστούν σε μια ξεχωριστή κλάση, που θα περιείχε τα βασικά τμήματα κατασκευής της για μια ποικιλία οντολογιών φαγητών και ποτών (όπου στην ουσία αποτελεί το μέχρι τώρα παράδειγμα μας). Δηλαδή, ορίζονται στην οντολογία food η οποία συμπεριλαμβάνεται στην οντολογία wine. Η οντολογία food περιλαμβάνει ένα πλήθος κλάσεων, για παράδειγμα τις Food, EdibleThing, MealCourse και Shellfish, οι οποίες δεν ανήκουν σε μια συλλογή κρασιών και ποτών, αλλά συνδέονται με το λεξιλόγιο των κρασιών, εάν πρόκειται να κατασκευάσουμε ένα χρήσιμο μοντέλο. Το φαγητό και το κρασί είναι αμοιβαίως εξαρτώμενα, έτσι ώστε να ικανοποιήσουμε την ανάγκη προσδιορισμού της αντιστοιχίας φαγητού - κρασιού. Ο ορισμός μιας κλάσης αποτελείται από δυο μέρη: την παρουσίαση του ονόματος ή μιας αναφοράς και από την λίστα περιορισμών. Κάθε μια από τις άμεσα συμπεριλαμβανόμενες εκφράσεις εντός του ορισμού της κλάσης, περιορίζει περαιτέρω τα αντικείμενα της κλάσης. Μέχρι στιγμής, έχουμε δει παραδείγματα που συμπεριλαμβάνουν ένα περιορισμό, εξαναγκάζοντας κάθε νέα κλάση να είναι υποκλάση άλλη ονομαζόμενης κλάσης. Σε αυτό το σημείο μπορούμε να κατασκευάσουμε ένα απλό αλλά μη ολοκληρωμένο ορισμό για την κλάση Wine. Το Wine(Κρασί) είναι ένα PortableLiquid (Πόσιμο υγρό). Επίσης, ορίζουμε την κλάση Pasta (Μακαρόνια) ως ένα EdibleThing (Βρώσιμο είδος). <owl:class rdf:id="wine"> <rdfs:subclassof rdf:resource="&food;potableliquid"/> <rdfs:label xml:lang="en">wine</rdfs:label> <rdfs:label xml:lang="fr">vin</rdfs:label>... </owl:class> <owl:class rdf:id="pasta"> <rdfs:subclassof rdf:resource="#ediblething" />... </owl:class> 14

23 Η εγγραφή rdfs:label μας παρέχει ένα προαιρετικό όνομα για την κλάση που μπορεί να κατανοηθεί εύκολα από τους ανθρώπους. Στο μέλλον θα σχεδιαστούν εργαλεία αναπαράστασης που θα μπορούν να χρησιμοποιήσουν αυτό το πεδίο για να παρέχουν μια κατάλληλα εικόνα. Η πινακίδα (label) είναι κάτι σαν σχόλιο και δεν συμβάλει καθόλου στην λογική ερμηνεία μιας οντολογίας. Ο ορισμός μας για την κλάση wine είναι ακόμη ανολοκλήρωτος. Δεν γνωρίζουμε σχεδόν τίποτα για τα κρασιά εκτός από ότι είναι καταναλώσιμα υγρά, αλλά έχουμε αρκετές πληροφορίες για την δημιουργία και την απεικόνιση των αντικείμενων Προσωπικότητες - Αντικείμενα Εκτός από τις κλάσεις, θέλουμε να περιγράφουμε και τα μέλη τους. Συνήθως τα σκεφτόμαστε ως προσωπικότητες ή αντικείμενα, σύμφωνα με αυτά που ισχύουν στον πραγματικό κόσμο. Μια προσωπικότητα ή ένα αντικείμενο περιγράφεται μινιμαλιστικά, δηλώνοντας ότι αποτελεί μέλος μιας κλάσης. <Region rdf:id="centralcoastregion" /> Το παρακάτω έχει ίδια σημασία με το προαναφερόμενο παράδειγμα. <owl:thing rdf:id="centralcoastregion" /> <owl:thing rdf:about="#centralcoastregion"> <rdf:type rdf:resource="#region"/> </owl:thing> Το πεδίο rdf:type ανήκει στην RDF και συσχετίζει μια προσωπικότητα αντικείμενο με μια κλάση στην οποία είναι μέλος. Υπάρχουν αρκετά σημεία που θα πρέπει να επισημανθούν, σε αυτό το σημείο. Αρχικά, έχουμε αποφασίσει ότι το CentralCoastRegion (μια συγκεκριμένη περιοχή) είναι μέλος του Region, της κλάσης δηλαδή που περιέχει όλες τις γεωγραφικές περιοχές. Επίσης, δεν απαιτείται στο παραπάνω διμερές παράδειγμα ότι τα δυο στοιχεία θα πρέπει να είναι κοντά το ένα στο άλλο (στον κώδικα) ή ακόμα και στο ίδιο αρχείο (αν και τα ονόματα τους θα έπρεπε να επεκταθούν με το URI τους σε τέτοια περίπτωση). Σχεδιάζουμε της διαδικτυακές οντολογίες έτσι ώστε να 15

24 μπορούν να κατανεμηθούν, να μπορούν να κληθούν από άλλα αρχεία ή να συνεργαστούν για τη δημιουργία μιας μεγαλύτερης οντολογίας. Για να μπορούμε να έχουμε περισσότερες κλάσεις διαθέσιμες, για τις ιδιότητες που περιγράφονται στη συνέχεια, ορίζουμε ένα κλάδο ταξινόμησης που ονομάζεται Grape (αμπέλι) με μια προσωπικότητα να δηλώνει την ποικιλία Cabernet Sauvignon. Τα αμπέλια ορίζονται στην οντολογία των φαγητών: <owl:class rdf:id="grape">... </owl:class> Στη συνέχεια για την οντολογία των κρασιών έχουμε : <owl:class rdf:id="winegrape"> <rdfs:subclassof rdf:resource="&food;grape" /> </owl:class> <WineGrape rdf:id="cabernetsauvignongrape" /> Όπως περιγράφεται στα επόμενα το είδος CabernetSauvignonGrape, είναι μια προσωπικότητα αντικείμενο επειδή δηλώνει ένα συγκεκριμένο είδος αμπελιού Σχεδιασμός προς Χρήση Υπάρχουν σημαντικά θέματα όσον αφορά, το διαχωρισμό μεταξύ μιας κλάσης και μιας προσωπικότητας στην OWL. Μια κλάση αποτελείται από ένα απλό και περιγραφικό όνομα και ένα σύνολο από ιδιότητες που περιγράφουν ένα σύνολο από προσωπικότητες. Οι προσωπικότητες αντικείμενα είναι μέλη αυτών των συνόλων. Άρα λοιπόν, οι κλάσεις θα πρέπει να αντιστοιχούν σε σύνολα αντικειμένων που υπάρχουν στον πραγματικό κόσμο και οι προσωπικότητες σε υπάρχουσες οντότητες που θα μπορούν να ομαδοποιηθούν σε αυτές τις κλάσεις. Κατά την κατασκευή των οντολογιών, αυτός ο διαχωρισμός αντιμετωπίζεται συχνά με δύο τρόπους: Επίπεδα αναπαράστασης : Σε μερικά συμφραζόμενα αυτό που είναι εμφανώς μια κλάση μπορεί από μόνο του να υπολογιστεί ως μέρος μιας άλλης. Για παράδειγμα, στην οντολογία των κρασιών, αντιλαμβανόμαστε ότι ο όρος Grape (αμπέλι) δηλώνει όλες τις ποικιλίες αμπελιών. Το CabernetSauvignonGrape αποτελεί παράδειγμα τμήματος αυτής της κλάσης, αφού δηλώνει την πραγματική ποικιλία που ονομάζεται Cabernet 16

25 Sauvignon. Ωστόσο η ποικιλία αυτή θα μπορούσε από μόνη της να υπολογιστεί ως κλάση δηλαδή το σύνολο όλων των αμπελιών Cabernet Sauvignon. Υποκλάση ενάντιων περιπτώσεων: Είναι αρκετά εύκολο να μπερδέψουμε μια περίπτωση μιας σχέσης με την υποκλάση μιας σχέσης. Για παράδειγμα, μπορεί να φαίνεται αυθαίρετο να κάνουμε μια περίπτωση αντικείμενο το CabernetSauvignonGrape ως περίπτωση του Grape, σε αντίθεση με το να το κάνουμε υποκλάση του Grape. Αυτή δεν είναι μια αυθαίρετη απόφαση. Η κλάση Grape δηλώνει το σύνολο όλων των ποικιλιών αμπελιών και κατά συνέπεια κάθε υποκλάση του Grape θα πρέπει να δηλώνει ένα υποσύνολο αυτών των ποικιλιών. Άρα θα πρέπει να δεχτούμε το CabernetSauvignonGrape ως μια περίπτωση του Grape και όχι ως υποκλάση. Αυτό ισχύει επειδή το CabernetSauvignonGrape δεν περιγράφει ένα υποσύνολο των ποικιλιών των αμπελιών, είναι μια ποικιλία. Αξίζει να σημειωθεί ότι η ίδια διάκριση δημιουργείται με τη χρήση της κλάσης Wine. Ουσιαστικά η κλάση των κρασιών δηλώνει όλες τις ποικιλίες των κρασιών και όχι το σύνολο των φυσικών μπουκαλιών, που κάποιος μπορεί να αγοράσει. Εναλλακτικά σε μια οντολογία, κάθε περίπτωση κρασιού, θα μπορούσε να δημιουργεί μια κλάση που να περιείχε όλα τα μπουκάλια του συγκεκριμένου τύπου κρασιού. Μπορούμε εύκολα να φανταστούμε ένα πληροφοριακό σύστημα που να λειτουργεί ως κατάλογος για ένα έμπορο κρασιών, όπου χρειάζεται να γνωρίζει τα ξεχωριστά μπουκάλια κρασιού. Η οντολογία των κρασιών, έτσι όπως την έχουμε σχεδιάσει μέχρι στιγμής, θα χρειαζόταν να αντιμετωπίζει τις κλάσεις ως περιπτώσεις, έτσι ώστε να υποστηρίζει αυτή την εκδοχή. Η OWL Full υποστηρίζει τέτοια εκφραστικότητα, επιτρέποντας μας να αντιμετωπίζουμε μια περίπτωση ποικιλίας κρασιού, ως κλάση της οποίας οι περιπτώσεις είναι μπουκάλια κρασιού. Από μια παράλληλη οπτική γωνία, τα κρασιά που παράγονται από τα οινοποιία κάποια συγκεκριμένη χρονία, θεωρούνται εκλεκτές ποικιλίες. Για να αντικατοπτρίσουμε την ιδέα της εκλεκτής ποικιλίας θα πρέπει να αποφασίσουμε, αν χωράει στην συγκεκριμένη οντολογία. Μια περίπτωση της κλάσης wine, όπως αναφέραμε και παραπάνω παριστάνει μια συγκεκριμένη εκλεκτή ποικιλία κρασιού που παράχθηκε από ένα μοναδικό οινοποιείο, για παράδειγμα το FormanChardonnay. Το να προσθέσουμε ότι το κρασί που παράχθηκε το 2000 θεωρείται εκλεκτή ποικιλία δημιουργεί εξαιρετικό ενδιαφέρον, επειδή δεν έχουμε τη δυνατότητα να αναπαραστήσομε ένα υποσύνολο μιας υπάρχουσας προσωπικότητας αντικειμένων. Αυτή η ποικιλία δεν είναι μια νέα ποικιλία κρασιού, είναι ένα ειδικό υποσύνολο κρασιών που έχει έτος παραγωγής το Μια πιθανή λύση θα ήταν η χρήση της OWL Full και να αντιμετωπίσουμε τις προσωπικότητες ως κλάσεις με υποκλάσεις που δηλώνουν τις ποικιλίες. Μια άλλη λύση, θα ήταν να θεωρήσουμε τις εκλεκτές ποικιλίες (Vintage) ως μια ξεχωριστή κλάση της οποίας οι περιπτώσεις έχουν σχέσεις με το κρασί του οποίου είναι ποικιλία. 17

26 Το κυρίως θέμα αυτής της συζήτηση είναι ότι ο σχεδιασμός και η δημιουργία μιας οντολογίας θα πρέπει να αναλογεί στην χρήση που θα κάνουμε. Αυτά τα θέματα επίσης υπογραμμίζουν τις βασικές διαφορές ανάμεσα στην OWL Full και την OWL DL. Η OWL Full επιτρέπει την χρήση κλάσεων ως περιπτώσεων, ενώ η OWL DL όχι. Η οντολογία των κρασιών έχει σχεδιαστεί για την OWL DL οπότε οι προσωπικότητες αντικείμενα όπως το FormanChardonnay δεν θεωρούνται ως κλάσεις Απλές Ιδιότητες Ο κόσμος των κλάσεων και των περιπτώσεων δεν θα παρουσίαζαν κανένα ενδιαφέρον, αν το μόνο που μπορούσαμε να ορίσουμε ήταν οι ταξινομήσεις. Οι ιδιότητες μας δίνουν τη δυνατότητα να εισάγουμε γενικά γεγονότα για τα μέλη των κλάσεων και συγκεκριμένα γεγονότα για τις περιπτώσεις αντικείμενα Ορίζοντας Ιδιότητες ObjectProperty, DatatypeProperty, rdfs:subpropertyof, rdfs:domain, rdfs:range Μια ιδιότητα είναι μια δυαδική σχέση. Οι τύποι ιδιοτήτων διακρίνονται σε: Ιδιότητες τύπου δεδομένων, δηλαδή σχέσεις μεταξύ περιπτώσεων κλάσεων, RDF literals και XML Schema τύπων δεδομένων. Ιδιότητες αντικειμένων, δηλαδή σχέσεις μεταξύ περιπτώσεων δυο κλάσεων. Η ιδιότητα αντικειμένου ονόματος (name) δεν δημιουργεί σχέση μεταξύ του όρου RDF rdf:object. Υπάρχουν διάφοροι τρόποι να περιορίσουμε μια σχέση, όταν ορίζουμε μια ιδιότητα. Το πεδίο και η έκταση θα πρέπει να προσδιοριστούν. Ιδιότητες μπορούν να οριστούν ως ειδικότερες (υπόιδιότητες) μιας υπάρχουσας ιδιότητας. Πιθανοί είναι και περιπλοκότεροι περιορισμοί που περιγράφονται αργότερα. <owl:objectproperty rdf:id="madefromgrape"> <rdfs:domain rdf:resource="#wine"/> <rdfs:range rdf:resource="#winegrape"/> </owl:objectproperty> <owl:objectproperty rdf:id="course"> <rdfs:domain rdf:resource="#meal" /> 18

27 <rdfs:range rdf:resource="#mealcourse" /> </owl:objectproperty> Στην OWL, μια ακολουθία στοιχείων χωρίς σαφή διαχειριστή παριστάνει μια αναμφίβολη πρόταση. Η ιδιότητα madefromgrape έχει πεδίο την κλάση Wine και έκταση το WineGrape. Έτσι σχετίζονται περιπτώσεις της κλάσης Wine με περιπτώσεις της κλάσης WineGrape. Πολλαπλά πεδία, σημαίνουν ότι το πεδίο της ιδιότητας αποτελεί τομή των αναγνωρισμένων κλάσεων. Ομοίως, η ιδιότητα course σχετίζει ένα γεύμα (Meal) με μια πορεία γεύματος (MealCourse). Αξίζει να σημειωθεί ότι η χρήση των πληροφοριών του πεδίου και της έκτασης στην OWL είναι διαφορετική από αυτή στις γλώσσες προγραμματισμού. Ενώ οι τύποι χρησιμοποιούνται για τον έλεγχο συνέπειας στις γλώσσες προγραμματισμού στην OWL, η έκταση χρησιμοποιείται για να συμπεραίνουμε ένα τύπο. Για παράδειγμα : <owl:thing rdf:id="lindemansbin65chardonnay"> <madefromgrape rdf:resource="#chardonnaygrape" /> </owl:thing> Μπορούμε να συμπεράνουμε ότι το LindemansBin65Chardonnay είναι ένα κρασί επειδή το πεδίο madefromgrape είναι το Wine. Οι ιδιότητες, όπως οι κλάσεις μπορούν να τοποθετηθούν σε ιεραρχία. <owl:class rdf:id="winedescriptor" /> <owl:class rdf:id="winecolor"> <rdfs:subclassof rdf:resource="#winedescriptor" />... </owl:class> <owl:objectproperty rdf:id="haswinedescriptor"> <rdfs:domain rdf:resource="#wine" /> <rdfs:range rdf:resource="#winedescriptor" /> </owl:objectproperty> <owl:objectproperty rdf:id="hascolor"> <rdfs:subpropertyof rdf:resource="#haswinedescriptor" /> <rdfs:range rdf:resource="#winecolor" />... </owl:objectproperty> Η ιδιότητα WineDescriptor (περιγραφέας κρασιού) συσχετίζει τα κρασιά με το χρώμα τους και τα χαρακτηριστικά της γεύσης τους, όπως τη γλυκύτητα και άλλα. Υπο-ιδιότητα του haswinedescriptor αποτελεί το hascolour, του οποίου η ακτίνα περιορίζεται στο WineColour. Η 19

28 συσχέτιση rdfs:subpropertyof σε αυτή την περίπτωση σημαίνει ότι οτιδήποτε έχει την ιδιότητα hascolour με τιμή Χ έχει επίσης την ιδιότητα haswinedescriptor με την ίδια τιμή. Στη συνέχεια παρουσιάζουμε την ιδιότητα locatedin, η οποία σχετίζει τα αντικείμενα με τις περιοχές που βρίσκονται. <owl:objectproperty rdf:id="locatedin">... <rdfs:domain rdf:resource=" /> <rdfs:range rdf:resource="#region" /> </owl:objectproperty> Άξιο προσοχής, είναι το πώς ορίζονται το πεδίο και η ακτίνα της ιδιότητας αυτής. Το πεδίο επιτρέπει σε οτιδήποτε να βρίσκεται σε μια περιοχή, συμπεριλαμβάνοντας και τις ίδιες τις περιοχές. Η μεταβατική σύνθεση της σχέσης αυτής, δημιουργεί ένα δίκτυο με τις συμπεριλαμβανόμενες γεωγραφικές υπό-περιοχές και τα αντικείμενα. Τα αντικείμενα τα οποία δεν έχουν τίποτα εγκαταστημένο εντός τους μπορούν να προέρχονται από οποιαδήποτε κλάση, ενώ αυτά που περιέχουν άλλα πρέπει να είναι περιοχές. Μπορούμε πλέον να διευρύνουμε τον ορισμό του Wine, έτσι ώστε να συμπεριλαμβάνει την υπόθεση ότι ένα κρασί φτιάχνεται από τουλάχιστον ένα WineGrape. Αντίστοιχα με τους ορισμούς των ιδιοτήτων οι ορισμοί των κλάσεων έχουν πολλαπλά υπό-μέρη που αναμφίβολα συνδέονται. <owl:class rdf:id="wine"> <rdfs:subclassof rdf:resource="&food;potableliquid"/> <rdfs:subclassof> <owl:restriction> <owl:onproperty rdf:resource="#madefromgrape"/> <owl:mincardinality rdf:datatype="&xsd;nonnegativeinteger">1</owl:mincardinality> </owl:restriction> </rdfs:subclassof>... </owl:class> Ο γραμμοσκιασμένος περιορισμός παραπάνω δηλαδή: <owl:restriction> <owl:onproperty rdf:resource="#madefromgrape"/> <owl:mincardinality rdf:datatype="&xsd;nonnegativeinteger">1</owl:mincardinality> </owl:restriction> 20

29 ορίζει μια κλάση χωρίς όνομα που απεικονίζει ένα σύνολο από αντικείμενα με τουλάχιστον μια ιδιότητα madefromgrape. Αυτές οι κλάσεις ονομάζονται ανώνυμες κλάσεις. Συμπεριλαμβάνοντας αυτόν το περιορισμό στο σώμα ορισμού της κλάσης Wine ορίζουμε ότι τα αντικείμενα που είναι κρασιά είναι και μέλη αυτής της ανώνυμης κλάσης. Αυτό σημαίνει ότι κάθε προσωπικότητα αντικείμενο κρασιού θα πρέπει να συμμετέχει σε τουλάχιστον μια σχέση madefromgrape. Μπορούμε στην συνέχεια να περιγράψουμε την κλάση Vintage (εκλεκτής ποιότητας κρασί), όπως είπαμε προηγουμένως. <owl:class rdf:id="vintage"> <rdfs:subclassof> <owl:restriction> <owl:onproperty rdf:resource="#vintageof"/> <owl:mincardinality rdf:datatype="&xsd;nonnegativeinteger">1</owl:mincardinality> </owl:restriction> </rdfs:subclassof> </owl:class> Η ιδιότητα vintageof συσχετίζει ένα Vintage με ένα Wine. <owl:objectproperty rdf:id="vintageof"> <rdfs:domain rdf:resource="#vintage" /> <rdfs:range rdf:resource="#wine" /> </owl:objectproperty> Στη συνέχεια θα σχετίζουμε τα Vintage με τη χρονιά παραγωγής τους Ιδιότητες και Τύποι Δεδομένων Ξεχωρίζουμε τις ιδιότητες ανάλογα με το αν συσχετίζουν προσωπικότητες αντικείμενα μεταξύ τους (object properties) ή προσωπικότητες αντικείμενα με τύπους δεδομένων (datatype properties) Οι τύποι δεδομένων μπορούν να εκτιμώνται από μεταβλητές RDF μέχρι απλούς τύπους όπως αυτοί ορίζονται σύμφωνα με τα XML σχήματα. H OWL χρησιμοποιεί τους περισσότερους από τους υπαρκτούς τύπους των XML σχημάτων. Αναφορές σε αυτούς τους τύπους παρέχονται από τα URI αναφοράς για κάθε τύπο, Οι παρακάτω τύποι δεδομένων προτείνονται για χρήση στην OWL: xsd:string xsd:normalizedstring xsd:boolean xsd:decimal xsd:float xsd:double xsd:integer xsd:nonnegativeinteger xsd:positiveintege r 21

30 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. Όλοι οι μεταγλωττιστές απαιτείται να υποστηρίζουν τους τύπους δεδομένων xsd:integer και xsd:string. Περισσότεροι υπάρχοντες τύποι δεδομένων του XML σχήματος μπορούν να χρησιμοποιηθούν στην OWL Full, αρκεί να υπάρχει κατάλληλος ορισμός τους στην αναφορά του OWL Semantics and Abstrax Syntax. <owl:class rdf:id="vintageyear" /> <owl:datatypeproperty rdf:id="yearvalue"> <rdfs:domain rdf:resource="#vintageyear" /> <rdfs:range rdf:resource="&xsd;positiveinteger"/> </owl:datatypeproperty> Η ιδιότητα yearvalue συσχετίζει το VintageYear με θετικές ακέραιες τιμές. Παρακάτω παρουσιάζουμε την ιδιότητα hasvintageyear η οποία σχετίζει ένα Vintage με το VintageYear Ιδιότητες των Προσωπικοτήτων - Αντικειμένων Αρχικά περιγράφουμε τις προσωπικότητες Region (περιοχή) και Winery (οινοποιείο) και στη συνέχεια ορίζουμε το πρώτο μας κρασί, ένα Cabernet Sauvignon. <Region rdf:id="santacruzmountainsregion"> <locatedin rdf:resource="#californiaregion" /> </Region> <Winery rdf:id="santacruzmountainvineyard" /> <CabernetSauvignon rdf:id="santacruzmountainvineyardcabernetsauvignon" > <locatedin rdf:resource="#santacruzmountainsregion"/> <hasmaker rdf:resource="#santacruzmountainvineyard" /> </CabernetSauvignon> Το παράδειγμα μας είναι ακόμα ελλιπές. Υπάρχει ένα πλήθος γεύσεων κρασιού που περιγράφονται σε ολόκληρη την οντολογία. Θα μπορούσαμε να συλλογιστούμε, ποια 22

31 αντικείμενα του μενού από την οντολογία των φαγητών θα μπορούσε να ακολουθεί αυτό το κρασί. Γνωρίζουμε από τον παραπάνω ορισμό ότι το Santa Cruz Mountain Vineyard παράγει το συγκεκριμένο κρασί. Επειδή όμως, είναι Cabernet Sauvignon είναι κόκκινο και ξηρό κρασί. Θα μπορούσαμε να προσθέσουμε ιδιότητες τύπων δεδομένων σε προσωπικότητες αντικείμενα σε ένα παρόμοιο μοτίβο. Παρακάτω περιγράφουμε μια περίπτωση του VintageYear και το συσχετίζουμε με μια συγκεκριμένη τιμή του &xsd:positiveinteger <VintageYear rdf:id="year1998"> <yearvalue rdf:datatype="&xsd;positiveinteger">1998</yearvalue> </VintageYear> Χαρακτηριστικά των Ιδιοτήτων Οι επόμενες ενότητες περιγράφουν μηχανισμούς που χρησιμοποιούνται για να εισάγουν παραπάνω λεπτομέρειες στις ιδιότητες. Έχουμε τη δυνατότητα, να καθορίζουμε χαρακτηριστικά των ιδιοτήτων, τα οποία μας παρέχουν ένα ισχυρό μηχανισμό για ισχυρές περιγραφές μιας ιδιότητας Μεταβατικές Ιδιότητες Εάν μια ιδιότητα P, ορίζεται ως μεταβατική για κάθε x,y,z : P(x,y) and P(y,z) implies P(x,z) Η ιδιότητα locatedin είναι μεταβατική. <owl:objectproperty rdf:id="locatedin"> <rdf:type rdf:resource="&owl;transitiveproperty" /> <rdfs:domain rdf:resource="&owl;thing" /> <rdfs:range rdf:resource="#region" /> </owl:objectproperty> <Region rdf:id="santacruzmountainsregion"> <locatedin rdf:resource="#californiaregion" /> </Region> <Region rdf:id="californiaregion"> <locatedin rdf:resource="#usregion" /> </Region> Επειδή η περιοχή Santa Cruz Mountain (SantaCruzMountainsRegion) βρίσκεται (locatedin) στην περιοχή California (CaliforniaRegion), θα πρέπει επίσης να βρίσκεται (locatedin) στην περιοχή USA (USARegion), άρα συνεπάγεται ότι η ιδιότητα locatedin είναι μεταβατική. 23

32 Συμμετρικές Ιδιότητες Εάν μια ιδιότητα P έχει οριστεί ως συμμετρική τότε για κάθε x και y: P(x,y) iff P(y,x) H ιδιότητα adjacentregion (γειτονική περιοχή) είναι συμμετρική, ενώ η locatedin όχι. Για να γίνουμε πιο ακριβείς δεν προτείνεται η ιδιότητα locatedin να είναι συμμετρική. Τίποτα από την οντολογία των κρασιών μέχρι στιγμής δεν αποτρέπει στην ιδιότητα να είναι συμμετρική. <owl:objectproperty rdf:id="adjacentregion"> <rdf:type rdf:resource="&owl;symmetricproperty" /> <rdfs:domain rdf:resource="#region" /> <rdfs:range rdf:resource="#region" /> </owl:objectproperty> <Region rdf:id="mendocinoregion"> <locatedin rdf:resource="#californiaregion" /> <adjacentregion rdf:resource="#sonomaregion" /> </Region> Η περιοχή MendocinoRegion είναι γειτονική με την SonomaRegion και το αντίθετο. Η περιοχή MendocinoRegion βρίσκεται στην CaliforniaRegion το αντίθετο όμως δεν ισχύει Συναρτησιακές Ιδιότητες Εάν μια ιδιότητα P ορίζεται ως συναρτησιακή τότε για κάθε x,y,z : P(x,y) and P(x,z) implies y = z Στην οντολογία των κρασιών η ιδιότητα hasvintageyear είναι συναρτησιακή. Κάθε κρασί έχει ένα μοναδικό έτος εκλεκτής ποικιλίας. Άρα κάθε αντικείμενο Vintage μπορεί μόνο να συσχετιστεί με ένα μοναδικό έτος χρησιμοποιώντας την ιδιότητα hasvintageyear. Δεν απαιτείται από μια συναρτησιακή ιδιότητα ότι όλα τα στοιχεία του πεδίου θα έχουν τιμές. <owl:class rdf:id="vintageyear" /> <owl:objectproperty rdf:id="hasvintageyear"> <rdf:type rdf:resource="&owl;functionalproperty" /> <rdfs:domain rdf:resource="#vintage" /> <rdfs:range rdf:resource="#vintageyear" /> </owl:objectproperty> 24

33 Ιδιότητα των Αντίθετων Εάν μια ιδιότητα Ρ1 έχει οριστεί ως αντίθετη της Ρ2 τότε για κάθε χ και y : P1(x,y) iff P2(y,x) Παρατηρούμε ότι η ιδιότητα owl:inverseof παίρνει ως όρισμα το όνομα μιας ιδιότητας. A iff B σημαίνει ότι (A implies B) και (B implies A). <owl:objectproperty rdf:id="hasmaker"> <rdf:type rdf:resource="&owl;functionalproperty" /> </owl:objectproperty> <owl:objectproperty rdf:id="produceswine"> <owl:inverseof rdf:resource="#hasmaker" /> </owl:objectproperty> Τα κρασιά (Wines) έχουν παραγωγούς, όπου στον ορισμό της οντολογίας περιορίζονται σε οινοποιεία (Winerys). Τότε κάθε οινοποιείο, παράγει εκείνα τα κρασιά που το αναγνωρίζουν ως παραγωγό τους Αντίστροφη Συναρτησιακή Ιδιότητα Εάν μια ιδιότητα P ορίζεται ως αντίστροφη συναρτησιακή ιδιότητα τότε για κάθε x,y,z : P(y,x) and P(z,x) implies y = z Παρατηρούμε ότι, η ιδιότητα produceswine στο συγκεκριμένο σημείο είναι αντίστροφη συναρτησιακή. Αυτό ισχύει γιατί η αντίστροφη μιας συναρτησιακής ιδιότητας συγκαταλέγεται αυτόματα ως αντίστροφη συναρτησιακή. Δηλαδή ορίζουμε την ιδιότητα hasmaker ως συναρτησιακή, αντιστοιχα ορίζουμε την ιδιότητα produceswine ως αντιστροφή μιας συναρτησιακής ιδιότητας, αυτό σημαίνει ότι η produceswine είναι αντίστροφη συναρτησιακή. Θα μπορούσαμε να είχαμε ορίσει ότι οι ιδιότητες hasmaker και η produceswine είναι αντίστροφες συναρτησιακές, όπως φαίνεται παρακάτω : <owl:objectproperty rdf:id="hasmaker" /> <owl:objectproperty rdf:id="produceswine"> <rdf:type rdf:resource="&owl;inversefunctionalproperty" /> <owl:inverseof rdf:resource="#hasmaker" /> </owl:objectproperty> Θα πρέπει να σκεφτούμε τα στοιχεία μιας συναρτησιακής ιδιότητας σαν ένα μοναδικό κλειδί στις βάσεις δεδομένων. Στην OWL Full μπορούμε να ορίσουμε μια ιδιότητα τύπου δεδομένων να είναι αντίστροφη συναρτησιακή. Γεγονός που μας επιτρέπει να έχουμε ως μοναδικό κλειδί ένα αλφαριθμητικό. Στην OWL DL και OWL Lite αυτό δεν μπορεί να γίνει. 25

34 Περιορισμοί Ιδιοτήτων Μπορούμε επιπλέον να περιορίσουμε την εμβέλεια μιας ιδιότητας σε συγκεκριμένα πλαίσια έτσι ώστε να προσδιορίσουμε τα χαρακτηριστικά της. Αυτό είναι δυνατό χρησιμοποιώντας τους περιορισμούς των ιδιοτήτων. Οι διάφοροι τρόποι που περιγράφονται παρακάτω, μπορούν να χρησιμοποιηθούν εντός ενός owl:restriction. Τα στοιχεία των owl:property δηλώνουν την περιορισμένη ιδιότητα Όλες οι τιμές από, Μερικές τιμές από Έχουμε ήδη, δει έναν τρόπο για να περιορίσουμε τους τυπούς των στοιχείων που απαρτίζουν μια ιδιότητα. Οι μηχανισμοί αυτοί είναι γενικοί, αφού απευθύνονται σε όλα τα αντικείμενα μιας ιδιότητας. Οι επόμενοι δύο, δηλαδή οι: allvaluesfrom και somevaluesfrom, είναι τοπικοί στην κλάση που εμπεριέχονται. Ο περιορισμός owl:allvaluesfrom απαιτεί ότι κάθε περίπτωση της κλάσης έχει περιπτώσεις της συγκεκριμένης ιδιότητας. Δηλαδή, οι τιμές της ιδιότητας είναι όλες μέλη της κλάση που δείχνει η ιδιότητα owl:allvaluesfrom. <owl:class rdf:id="wine"> <rdfs:subclassof rdf:resource="&food;potableliquid" />... <rdfs:subclassof> <owl:restriction> <owl:onproperty rdf:resource="#hasmaker" /> <owl:allvaluesfrom rdf:resource="#winery" /> </owl:restriction> </rdfs:subclassof>... </owl:class> Ο παραγωγός ενός κρασιού (Wine) θα πρέπει να είναι οινοποιείο (Winery). Ο περιορισμός allvaluesfrom στην ιδιότητα hasmaker δείχνει μόνο την κλάση των κρασιών (Wine). Οι παράγωγοι των τυριών δεν συμπεριλαμβάνονται από αυτό τον τοπικό περιορισμό. Παρόμοιος είναι και ο περιορισμός owl:somevaluesfrom. Εάν αντικαταστήσουμε τον περιορισμό owl:allvaluesfrom με τον owl:somevaluesfrom στο προηγούμενο παράδειγμα, θα σήμαινε ότι τουλάχιστον ένα στοιχείο από την ιδιότητα hasmaker της κλάσης Wine θα έδειχνε σε μια προσωπικότητα που είναι Winery. <owl:class rdf:id="wine"> <rdfs:subclassof rdf:resource="&food;potableliquid" /> <rdfs:subclassof> <owl:restriction> <owl:onproperty rdf:resource="#hasmaker" /> <owl:somevaluesfrom rdf:resource="#winery" /> </owl:restriction> 26

35 </rdfs:subclassof>... </owl:class> Η διαφορά ανάμεσα σε αυτές τις δυο φόρμες, είναι ίδια με τη διαφορά ανάμεσα σε μια γενική και μια υπαρκτή ποσοτικοποίηση. Σχέση allvaluesfrom somevaluesfrom Επιπτώσεις Για όλα τα κρασιά, εάν έχουν παραγωγούς, όλοι οι παραγωγοί είναι οινοποιεία Για όλα τα κρασιά, έχουν τουλάχιστον ένα παραγωγό, που είναι οινοποιείο. Η πρώτη δήλωση δεν απαιτεί από ένα κρασί να έχει παραγωγό. Εάν έχει όμως έναν ή περισσότερους θα πρέπει να είναι όλοι οινοποιεία. Η δεύτερη απαιτεί ότι πρέπει να υπάρχει τουλάχιστον ένα οινοποιείο ως παραγωγός, αλλά μπορεί να υπάρχουν και παραγωγοί που δεν είναι οινοποιεία Αριθμός στοιχείων Συνόλου Έχουν ήδη αναφερθεί παραδείγματα, περιορισμού αριθμού στοιχείων συνόλου. Έχουν γίνει προσθέσεις για ελάχιστο αριθμό στοιχείων συνόλου στην OWL. Η ιδιότητα owl:cardinality επιτρέπει τον λεπτομερή προσδιορισμό των στοιχείων μιας συσχέτισης. Για παράδειγμα, ορίζουμε ότι η κλάση Vintage θα έχει ακριβώς ένα VinatgeYear. <owl:class rdf:id="vintage"> <rdfs:subclassof> <owl:restriction> <owl:onproperty rdf:resource="#hasvintageyear"/> <owl:cardinality rdf:datatype="&xsd;nonnegativeinteger">1</owl:cardinality> </owl:restriction> </rdfs:subclassof> </owl:class> Ορίζουμε την ιδιότητα hasvintageyear να είναι συναρτησιακή όπου στην ουσία είναι το ίδιο με το να λέμε ότι κάθε εκλεκτής ποιότητας κρασί έχει ακριβώς ένα χρόνο παραγωγής. Η εφαρμογή αυτής της ιδιότητας, ισχυρίζεται ότι κάθε εκλεκτής ποιότητας κρασί (Vintage) έχει ακριβώς ένα χρόνο παραγωγής (VintageYear). Οι εκφράσεις αριθμών στοιχείων συνόλου με τιμές που οριοθετούνται σε 0 και 1 είναι μέρος της OWL Lite. Αυτό επιτρέπει στο χρήστη να δηλώνει «τουλάχιστον ένα», «όχι παραπάνω από ένα» και «ακριβώς ένα». Τιμές διαφορετικές του 0 και του 1 επιτρέπονται στην OWL DL όπου η ιδιότητα owl:maxcardinality μπορεί να χρησιμοποιηθεί για να δηλώσει ένα πάνω όριο. Αντίστοιχα η owl:mincardinality χρησιμοποιείται για να 27

36 δηλώσει ένα κάτω όριο. Ο συνδυασμός των δύο, μπορεί να χρησιμοποιηθεί για να οριοθετήσει ένα σύνολο τιμών για την ιδιότητα Υπαρκτή Τιμή Η ιδιότητα hasvalue μας επιτρέπει να οριοθετούμε κλάσεις, που βασίζονται στην ύπαρξη συγκεκριμένων τιμών, στις ιδιότητες. Επομένως, ένα αντικείμενο μπορεί να είναι μέλος μια τέτοιας κλάσης, αρκεί τουλάχιστον μια από τις τιμές της ιδιότητας του να είναι ίση με τις τιμές της ιδιότητας hasvalue. <owl:class rdf:id="burgundy">... <rdfs:subclassof> <owl:restriction> <owl:onproperty rdf:resource="#hassugar" /> <owl:hasvalue rdf:resource="#dry" /> </owl:restriction> </rdfs:subclassof> </owl:class> Εδώ δηλώνουμε ότι κάθε κρασί Burgundy είναι ξηρό. H ιδιότητα τους hassugar θα πρέπει να έχει τουλάχιστον μια τιμή που να είναι ίση με την ξηρότητα Dry. Όσον αφορά τις ιδιότητες allvaluesfrom και somevaluesfrom αυτός είναι ένας τοπικός περιορισμός. Ισχύει για την hassugar όπως αυτή εφαρμόζεται στο Burgundy. 28

37 ΚΕΦΑΛΑΙΟ 2 - Η SWRL 2.1 Εισαγωγή στην SWRL Η SWRL (Semantic Web Rule Language)[13] αποτελεί μια πρόταση γλώσσας κανόνων για τον Σημασιολογικό Ιστό. Βασίζεται σε ένα συνδυασμό των OWL DL και OWL Lite μαζί με την υπογλώσσα Datalog Rule ML της Rule Markup Language[14]. Έτσι επεκτείνει τα αξιώματα (axioms) της OWL, για να υποστηρίζουν κανόνες τύπου Horn [15]. Δηλαδή, επιτρέπει οι κανόνες τύπου Horn να συνδυάζονται με την βάση γνώσης της OWL. Επίσης, παρέχει ένα περιληπτικό συντακτικό υψηλού επιπέδου, το οποίο επεκτείνει το συντακτικό της OWL. Επιπλέον, ένα μοντέλο σημασιολογικών παρέχει κατάλληλες ερμηνείες στις OWL Οντολογίες, εμπεριέχοντας κανόνες γραμμένους στο συντακτικό της SWRL. Οι κανόνες που προτείνονται έχουν την μορφή προηγούμενου (body) και επακόλουθου (head) και των ακόλουθων επιπτώσεων, που το σώμα επιφέρει στην κεφαλίδα. Η ερμηνεία της μορφής αυτής μπορεί να επεξηγηθεί καλύτερα ως εξής: όταν οι συνθήκες που έχουν οριστεί στο σώμα ισχύουν, τότε οι συνθήκες που έχουν οριστεί στην κεφαλίδα πρέπει να ισχύουν και αυτές. Τυπικά ένας κανόνες έχει την παρακάτω μορφή: Antecedent Consequent Και τα δυο μέρη του κανόνα περιέχουν μηδέν ή παραπάνω αξιώματα. Ένα άδειο σώμα θεωρείται ως αληθές, δηλαδή ικανοποιείται από κάθε ερμηνεία, άρα και το μέρος του επακόλουθου θα ικανοποιείται πάντα. Αντίθετα ένα κενό επακόλουθο θεωρείται ως λάθος, δηλαδή δεν ικανοποιείται από καμία ερμηνεία και άρα το μέρος του σώματος θεωρείται και αυτό πάντοτε λάθος. Πολλαπλά αξιώματα συνδυάζονται. Σημειώνουμε ότι κανόνες με συνδυαστικά επακόλουθα μπορούν πολύ εύκολα να μετασχηματιστούν σε πολλούς κανόνες, καθένας με το δικό του επακόλουθο. Παράλληλα, παρέχεται ένα XML συντακτικό για αυτούς τους κανόνες, το οποίο βασίζεται στο συντακτικό της RuleML και της OWL XML. Περαιτέρω, παρουσιάζεται ένα ειδικό RDF συντακτικό βασισμένο στο συντακτικό ανταλλαγής μεταξύ OWL και RDF/XML. 29

38 2.2 Αφηρημένο Συντακτικό Το συντακτικό αυτό διευρύνει το αφηρημένο συντακτικό της OWL και παρόλο που θεωρείται αφηρημένο δεν είναι τόσο εύκολα αναγνώσιμο από τους ανθρώπους. Για αυτό λόγο θα χρησιμοποιούμε ένα «ανεπίσημο» συντακτικό κατανοητό από οποιοδήποτε. Παρόλα αυτά το συντακτικό αυτό δεν θα είναι συγκεκριμένο και δεν αντικατοπτρίζει το πλήρως ορισμένο συντακτικό της SWRL. Το αφηρημένο συντακτικό ορίζεται σε αυτό το σημείο, από έννοιες της Extended BNF[16] που είναι παρόμοια με την EBNF notation που χρησιμοποιείται στην XML. Στα τερματικά σύμβολα βάζουμε ελληνικό ερωτηματικό (;), τα μη τερματικά σύμβολα είναι μαυρισμένα και δεν παίρνουν ερωτηματικό. Οι εναλλακτικές επιλογές συνήθως ξεχωρίζουν από μια κάθετη μπάρα ( ), όπως χρησιμοποιείται το λογικό OR στις γλώσσες προγραμματισμού. Τα μέρη του κανόνα που μπορούν να συμβούν το πολύ μια φορά εμπερικλείονται σε [ ], ενώ τα μέρη που μπορούν να συμβούν απεριόριστες φορές (ίσως και 0) εμπερικλείονται σε { }. Τα κενά αγνοούνται στους κανόνες. Τα ονόματα στο αφηρημένο συντακτικό είναι αναφορές τύπου RDF URI, τα οποία μπορούν να συντομευτούν σε ειδικά ονόματα, χρησιμοποιώντας ένα από τα ακόλουθα namespaces. Όνομα Namespace Namespace Rdf Rdfs Xsd Owl Επισκόπηση των Κανόνων Μια οντολογία της OWL σε αφηρημένο συντακτικό περιέχει μια ακολουθία από αξιώματα και δεδομένα. Τα αξιώματα μπορούν να είναι διαφόρων τύπων όπως, αξιώματα υποκλάσεων ή αξιώματα ισότητας κλάσεων. Προτείνεται η επέκτασή τους με αξιώματα κανόνων. 30

39 axiom ::= rule Όπως προαναφέρθηκε κάθε αξίωμα κανόνας περιλαμβάνει ένα μέρος προηγούμενου και επακόλουθου τα οποία με την σειρά τους περιλαμβάνουν ένα σύνολο από άτομα (που πιθανώς να είναι και κενό), επίσης σε κάθε αξίωμα κανόνα μπορεί να οριστεί ένα URI, το οποίο χρησιμοποιείται για να αναγνωρίζει τον κανόνα. rule ::= 'Implies(' [ URIreference ] { annotation } antecedent consequent ')' antecedent ::= 'Antecedent(' { atom } ')' consequent ::= 'Consequent(' { atom } ')' Οι κανόνες που έχουν άδειο σώμα μπορούν να χρησιμοποιηθούν για τη δήλωση γεγονότων χωρίς όρους, ωστόσο θεωρείται σωστότερο, τέτοιου είδους γεγονότα να δηλώνονται στο αρχείο της OWL. Αξιώματα κανόνες που δεν έχουν κενό σώμα ή κεφαλίδα ισχύουν εάν και μόνο αν ισχύουν και όλες οι συνιστώσες τους, πιο συγκεκριμένα θεωρούνται ως λογικές ενώσεις των ατόμων τους. atom ::= description '(' i-object ')' datarange '(' d-object ')' individualvaluedpropertyid '(' i-object i-object ')' datavaluedpropertyid '(' i-object d-object ')' sameas '(' i-object i-object ')' differentfrom '(' i-object i-object ')' builtin '(' builtinid { d-object } ')' builtinid ::= URIreference Τα άτομα συνήθως είναι της μορφής C(x), P(x,y), sameas(x,y) differentfrom(x,y), ή builtin(r,x,...), όπου C είναι μια περιγραφή OWL ή ένα μέρος των δεδομένων, η μεταβλητή P είναι ιδιότητα της OWL, r είναι μια ενσωματωμένη σχέση (όπως το sameas(x,y)) και τα x και y είναι μεταβλητές, δηλαδή αντικείμενα προσωπικότητες της OWL, ή τιμές δεδομένων ανάλογα με την περιγραφή. Στο περιεχόμενο της OWL Lite, περιγραφές ατόμων της μορφής C(x) περιορίζονται σε ονομασμένες κλάσεις. Ένα άτομο της μορφής C(x) ισχύει εάν x είναι μια περίπτωση της περιγραφόμενης κλάσης C ή μέρος των δεδομένων της, ένα άτομο της μορφής P(x,y) ισχύει εάν το x σχετίζεται με το y μέσω της ιδιότητας P και μία ενσωματωμένη σχέση (built-in) της μορφής r(r,x, ) ισχύει εάν υπάρχουν μεταβλητές για τις οποίες αυτή η σχέση είναι αληθής. Αξίζει να παρατηρήσουμε ότι οι σχέσεις sameas() και differentfrom() είναι συντακτικά αντίθετες. Αυτό βέβαια δεν αυξάνει την εκφραστική δυνατότητα της γλώσσας. 31

40 i-object ::= i-variable individualid d-object ::= d-variable dataliteral Τα άτομα μπορούν να αναφέρονται σε προσωπικότητες αντικείμενα, σε λογικές μεταβλητές, μεταβλητές αντικειμένων ή μεταβλητές δεδομένων. Οι μεταβλητές όπως είναι ευρέως γνωστό παίρνουν όλες τις τιμές που αντιστοιχούν στο πεδίο τιμών τους. Όπως μπορεί κανείς να συμπεράνει λογικά οι μεταβλητές που ικανοποιούν τις συνθήκες του σώματος μπορούν να ικανοποιούν την κεφαλίδα. i-variable ::= 'I-variable(' URIreference ')' d-variable ::= 'D-variable(' URIreference ')' 2.3 Εύκολα Αναγνώσιμο Συντακτικό Το αφηρημένο EBNF συντακτικό που αναλύθηκε παραπάνω μπορεί να ακολουθεί τις προδιαγραφές της OWL και να είναι χρήσιμο για να ορίζουμε κανόνες XML και RDF ωστόσο, είναι αρκετά αναλυτικό για την περιγραφή ενός κανόνα και δύσκολο να διαβαστεί. Από εδώ και στο εξής θα χρησιμοποιούμε συνήθως ένα «ανεπίσημο» συντακτικό που είναι εύκολα αναγνώσιμο και χρησιμοποιείται σε αρκετές δημοσιευμένες εργασίες για τους κανόνες. Στο συντακτικό αυτό οι κανόνες έχουν την μορφή που αναλύθηκε στην εισαγωγή του συγκεκριμένου κεφαλαίου: Σώμα Κεφαλίδα Όπου και τα δύο μέρη του κανόνα αποτελούνται από ενώσεις ατόμων για παράδειγμα a 1 ^... ^ a n. Οι μεταβλητές δηλώνονται χρησιμοποιώντας ένα αγγλικό ερωτηματικό για παράδειγμα?x. Χρησιμοποιώντας αυτό το λεξικό ένας κανόνας που βεβαιώνει την σύνθεση των ιδιοτήτων πατέρα και αδερφού συνεπάγεται την ιδιότητα του θείου. Πιο συγκεκριμένα αυτός ο κανόνας γράφεται : parent(?x,?y) ^ brother(?y,?z) -> uncle(?x,?z) Στο συντακτικό αυτό οι ενσωματωμένες σχέσεις μπορούν να γραφτούν σε μια πιο συναρτησιακή μορφή. Για παράδειγμα ο κανόνας op:numeric-add(?x,3,?z) μπορεί να γραφτεί :?x = op:numeric-add(3,?z) 32

41 Τα σημασιολογικά για την SWRL αποτελούν μια απλή επέκταση των σημασιολογικών που παρέχονται στην OWL. Η βασική ιδέα είναι ο ορισμός των συνδέσεων, επεκτάσεων των σημασιών της OWL και παράλληλα η χαρτογράφηση των μεταβλητών στα στοιχεία του πεδίου. Ένας κανόνας ικανοποιείται από μια σημασία εάν και μόνο αν κάθε σύνδεση που ικανοποιεί το σώμα του κανόνα, ικανοποιεί και την κεφαλίδα. Οι οντολογίες και τα αξιώματα που σχετίζονται με σημασιολογικές συνθήκες παραμένουν ως έχουν, ύστερα από την ικανοποίηση ενός κανόνα. 2.4 Ερμηνεία των Κανόνων Από την OWL μπορούμε να θυμηθούμε ότι δοθέντος ενός χάρτη δεδομένων D, μια αφηρημένη σημασία της OWL είναι της μορφής : I = <R, EC, ER, L, S, LV> Όπου R είναι ένα σύνολο από πηγές, LV^R είναι ένα σύνολο από λογικές τιμές, EC είναι μια χαρτογράφηση από τις κλάσεις και τους τύπους δεδομένων σε υποσύνολα R και L. ER είναι μια χαρτογράφηση από τις σχέσεις σε δυαδικές σχέσεις Ε και R, L είναι μια χαρτογράφηση από τις τυπωμένες λογικές μεταβλητές σε στοιχεία LV και S είναι μια χαρτογράφηση από τα ονόματα των προσωπικοτήτων αντικειμένων σε στοιχεία EC (δηλ. owl:thing). Για να χειριστούμε τις ενσωματωμένες συσχετίσεις, αυξάνουμε τον χάρτη δεδομένων έτσι ώστε να χαρτογραφεί τις ενσωματωμένες συσχετίσεις στα αντίστοιχα σύνολα. Για παράδειγμα, η σχέση op:numeric-add χαρτογραφείται σε τριάδες αριθμητικών τιμών που ερμηνεύουν σωστά την αριθμητική πρόσθεση. 2.5 Παραδείγματα Κανόνων με το συντακτικό της SWRL Παράδειγμα 1 ο Ένα απλό παράδειγμα χρήσης των κανόνων θα ήταν να ισχυριστούμε ότι ο συνδυασμός των ιδιοτήτων hasparent και hasbrother συνεπάγονται την ιδιότητα hasuncle. Τυπικά ένας τέτοιος κανόνας θα μπορούσε να γραφτεί ως εξής: hasparent(?x1,?x2) ^ hasbrother(?x2,?x3) -> hasuncle(?x1,?x3) Ενώ χρησιμοποιώντας το αφηρημένο συντακτικό θα γραφόταν ως εξής: Implies(Antecedent(hasParent(I-variable(x1) I-variable(x2)) 33

42 hasbrother(i-variable(x2) I-variable(x3))) Consequent(hasUncle(I-variable(x1) I-variable(x3)))) Από τον παραπάνω κανόνα ισχύει ότι, αν ο χ1 έχει γονέα τον χ2 και ο χ2 έχει αδερφό τον χ3 τότε ο χ1 έχει θείο τον χ3. Παράδειγμα 2 ο Ένα ακόμα ευκολότερο παράδειγμα θα ήταν να ισχυριστούμε ότι κάθε μαθητής (Student) είναι άνθρωπος (Person) το οποίο θα γραφόταν ως εξής : Student(?x1) -> Person(?x1). Implies(Antecedent(Student(I-variable(x1))) Consequent(Person(I-variable(x1)))) Ωστόσο, χρησιμοποιώντας τους κανόνες για τόσο απλά συμπεράσματα, αντιγράφουμε δυνατότητα της subclass της OWL. Οπότε θα ήταν λογικότερο να χρησιμοποιούσαμε : την ή Class(Student partial Person) SubClassOf(Student Person) στο αρχείο της OWL που θα έκανε την πληροφορία άμεσα διαθέσιμη σε έναν μεταγλωττιστή της. Παράδειγμα 3 ο Συνήθως χρησιμοποιούμε τους κανόνες για να δηλώνουμε τις τιμές ιδιοτήτων από μια προσωπικότητα σε μια συσχετιζόμενη προσωπικότητα, όπως στο παρακάτω παράδειγμα το οποίο εκφράζει το γεγονός ότι το στιλ ενός έργου τέχνης είναι το ίδιο με το στιλ του καλλιτέχνη : Artist(?x) ^ artiststyle(?x,?y) ^ Style(?y) ^ creator(?z,?x) -> style/period(?z,?y) Παράδειγμα 4 ο Είναι αρκετά χρήσιμο να συμπεριλαμβάνουμε περιγραφές της OWL στους κανόνες μας, αντί να χρησιμοποιούνται ονοματισμένες κλάσεις. Ο προηγούμενος κανόνας θα μπορούσε να επεκταθεί με ένα ξεχωριστό κανόνα για να παρέχονται πληροφορίες για την αποκλειστικότητα του στιλ (θεωρώντας ότι το στιλ δεν είναι πάντα αποκλειστικό). Artist(?x) & ( 1 artiststyle)(?x) & creator(?z,?x) -> ( 1 style/period)(?z) 34

43 2.6 Ειδικό συντακτικό για την XML Το ειδικό συντακτικό για την XML αποτελεί ένα συνδυασμό του συντακτικού παρουσίασης της OWL στην XML και του συντακτικού της RuleML XML. Ο συνδυασμός αυτός αποφέρει τα παρακάτω πλεονεκτήματα: Αυθαίρετες κλάσεις στην OWL (π.χ. περιγραφές) μπορούν να χρησιμοποιηθούν ως κατηγορήματα στους κανόνες. Οι κανόνες και τα οντολογικά αξιώματα μπορούν να συνδυαστούν ελεύθερα. Το υπάρχον XSLT stylesheet μπορεί εύκολα να επεκταθεί έτσι ώστε να παρέχει μια χαρτογράφηση σε γράφους RDF που επεκτείνουν το συντακτικό ανταλλαγής μεταξύ RDF OWL και XML. Απλοποιείται η διαλειτουργικότητα μεταξύ OWL και RuleML, εργαλεία που ήδη υπάρχουν για την RuleML μπορούν να προσαρμοστούν στην SWRL και προετοιμάζεται μια εξελικτική πορεία επέκτασης στα χαρακτηριστικά γνωρίσματα των κανόνων. Το XML σχήμα για το ειδικό συντακτικό συμβατότητας της SWRL με την XML είναι το : swrlx.xsd. Το αρχείο αυτό μέχρι στιγμής δημιουργεί μια τοπική αντιγραφή του XML σχήματος για το συντακτικό παρουσίασης της OWL στην XML και έχει μετατραπεί έτσι ώστε, να επιτρέπονται εκτεταμένες αναφορές σε πολλά από τα στοιχεία και χαρακτηριστικά που δεν συμπεριλαμβάνονταν σε αυτό και ορίζονται στο owlx:datarange. Το συντακτικό της SWRL για την XML χρησιμοποιεί τα namespaces: και (xsd). Το στοιχείο της οντολογίας ρίζας του συντακτικού παρουσίασης της OWL στην XML επεκτείνεται ώστε να εμπεριέχει τα στοιχεία των αξιωμάτων imp (δήλωση κανόνα) και var (δήλωση μεταβλητής) που υπάρχουν ως βασικά στοιχεία κανόνων στην RuleML. element Ontology <swrlx:ontology swrlx:name = xsd:anyuri > Content: (owlx:versioninfo owlx:priorversion owlx:backwardcompatiblewith owlx:incompatiblewith owlx:imports owlx:annotation owlx:class[axiom] owlx:enumeratedclass(d,f) 35

44 owlx:subclassof(d,f) owlx:equivalentclasses owlx:disjointclasses(d,f) owlx:datatypeproperty owlx:objectproperty owlx:subpropertyof owlx:equivalentproperties owlx:individual[axiom] owlx:sameindividual owlx:differentindividuals ruleml:imp[axiom] ruleml:var[axiom])* </swrlx:ontology> swrlx:name αναφέρεται στο όνομα της Οντολογίας, που είναι το Χαρακτηριστικό: βασικό URI αυτού του στοιχείου. Σημείωση: είναι το βασικό στοιχείο των αρχείων OWL στο συντακτικό παρουσίασης σε XML μορφή, ενώ το rdf:rdf χρησιμοποιείται ως το βασικό στοιχείο των αρχείων OWL σε RDF/XML. Στη συνέχεια πρέπει απλά να παρουσιάσουμε το αντίστοιχο συντακτικό για τις μεταβλητές και τους κανόνες. Τα πεδία μεταβλητών απλά δηλώνουν ότι το δοθέν αλφαριθμητικό θα χρησιμοποιηθεί ως μεταβλητή. element ruleml:var [axiom] <ruleml:var>xsd:string</ruleml:var> Γονέας: swrlx:ontology Τα στοιχεία imp είναι παρόμοια με τα αξιώματα subclassof. Παρουσιάζονται στο RuleML namespace. Ένα αξίωμα κανόνα μπορεί να ερμηνευτεί ως μια λογική επίπτωση ανάμεσα στο σώμα και την κεφαλίδα ενός κανόνα. Αντίστοιχα με τα αξιώματα subclassof, οι κανόνες μπορούν να έχουν σχόλια. Επίσης ένας κανόνας μπορεί να ονομαστεί, αν ο χρήστης το επιθυμεί χρησιμοποιώντας ένα URI. element ruleml:imp [axiom] <ruleml:imp> Content: ( rlab?, owlx:annotation*, _body, _head ) </ruleml:imp> Γονέας: swrlx:ontology Αυτό το στοιχείο μας επιτρέπει να λέμε ότι κάθε στοιχείο που ικανοποιεί το Σημείωση: σώμα ενός κανόνα θα πρέπει επίσης να ικανοποιεί και την κεφαλίδα του. 36

45 element ruleml:_rlab <ruleml:_rlab ruleml:href = xsd:anyuri (required) > Content: ( ) </ruleml:_rlab> Γονέας: ruleml:imp Και το _body αλλά και το _head είναι λίστες ατόμων που διαβάζονται ως κλίσεις των συστατικών ατόμων. element ruleml:_body <ruleml:_body> Content: ( swrlx:atom* ) </ruleml:_body> Γονέας : ruleml:imp element ruleml:_head <ruleml:_head> Content: ( swrlx:atom* ) </ruleml:_head> Γονέας : ruleml:imp Τα άτομα μπορούν να διαμορφώνονται από μοναδικές δηλώσεις (κλάσεις) δυαδικές δηλώσεις (ιδιότητες), ισότητες ή ανισότητες. swrlx:atom Content: (swrlx:classatom swrlx:datarangeatom swrlx:individualpropertyatom swrlx:datavaluedpropertyatom swrlx:sameindividualatom swrlx:differentindividualsatom swrlx:builtinatom) Γονέας : ruleml:_body, ruleml:_head Τα άτομα των κλάσεων αποτελούνται από μια περιγραφή και ένα όνομα μια περίπτωση αντικειμένου ή το όνομα μιας μεταβλητής. element swrlx:classatom <swrlx:classatom> Content: ( owlx:description, swrlx:iobject ) </swrlx:classatom> 37

46 Γονέας : swrlx:atom Η περιγραφή σε ένα άτομο κλάσης μπορεί να είναι το όνομα μιας κλάσης, ή μια περίπλοκη περιγραφή χρησιμοποιώντας δυαδικούς συνδυασμούς, περιορισμούς, και άλλα. Για παράδειγμα : <swrlx:classatom> <owlx:class owlx:name="person" /> <ruleml:var>x1</ruleml:var> </swrlx:classatom> <swrlx:classatom> <owlx:intersectionof> <owlx:class owlx:name="person" /> <owlx:objectrestriction owlx:property="hasparent"> <owlx:somevaluesfrom owlx:class="physician" /> </owlx:objectrestriction> </owlx:intersectionof> <ruleml:var>x2</ruleml:var> </swrlx:classatom> Τα άτομα του πεδίου των δεδομένων αποτελούνται από το πεδίο των δεδομένων και μια λογική μεταβλητή ή το όνομα μιας κανονικής μεταβλητής element swrlx:datarangeatom <swrlx:datarangeatom> Content: ( owlx:datarange, swrlx:dobject ) </swrlx:datarangeatom> Γονέας : swrlx:atom Η περιγραφή ενός ατόμου πεδίου δεδομένων μπορεί να αποτελείται από ένα αναγνωριστικό τύπου δεδομένων ή ένα σύνολο λογικών μεταβλητών. Για παράδειγμα: swrlx:datarangeatom> <owlx:datatype owlx:name="&xsd;int" /> <ruleml:var>x1</ruleml:var> </swrlx:datarangeatom> <swrlx:datarangeatom> <owlx:oneof> <owlx:datavalue owlx:datatype="&xsd;int">5</owlx:datavalue> <owlx:datavalue owlx:datatype="&xsd;int">10</owlx:datavalue> </owlx:oneof> <ruleml:var>x2</ruleml:var> </swrlx:datarangeatom> Τα άτομα των ιδιοτήτων αποτελούνται από το όνομα μιας ιδιότητας και δύο στοιχεία που μπορεί να είναι ονόματα προσωπικοτήτων αντικειμένων, ονόματα μεταβλητών ή τιμές δεδομένων. 38

47 element swrlx:individualpropertyatom <swrlx:individualpropertyatom swrlx:property = xsd:anyuri {required} > Content: ( swrlx:iobject, swrlx:iobject ) </swrlx:individualpropertyatom> swrlx:property αναφορά στο όνομα της ιδιότητας μιας Χαρακτηριστικό: προσωπικότητας Γονέας: swrlx:atom element swrlx:datavaluedpropertyatom <swrlx:datavaluedpropertyatom swrlx:property = xsd:anyuri {required} > Content: ( swrlx:iobject, swrlx:dobject ) </swrlx:datavaluedpropertyatom> Χαρακτηριστικό: swrlx:property αναφορά στο όνομα μιας ιδιότητας δεδομένων Γονέας: swrlx:atom Επειδή η OWL δεν υποστηρίζει πολύπλοκες περιγραφές ιδιοτήτων, το άτομο μιας ιδιότητας μπορεί να πάρει μόνο ένα όνομα ιδιότητας. Για παράδειγμα : <swrlx:individualpropertyatom swrlx:property="hasparent"> <ruleml:var>x1</ruleml:var> <owlx:individual owlx:name="john" /> </swrlx:individualpropertyatom> <swrlx:datavaluedpropertyatom swrlx:property="grade"> <ruleml:var>x1</ruleml:var> <owlx:datavalue owlx:datatype="&xsd;int">4</owlx:datavalue> </swrlx:datavaluedpropertyatom> Τα άτομα same (different) individuals εκφράζουν ισότητα (ανισότητα) μεταξύ συνόλων προσωπικοτήτων αντικειμένων και μεταβλητών. element swrlx:sameindividualatom <swrlx:sameindividualatom> Content: ( swrlx:iobject* ) </swrlx:sameindividualatom> Γονέας : swrlx:atom element swrlx:differentindividualsatom <swrlx:differentindividualsatom> Content: ( swrlx:iobject* ) </swrlx:differentindividualsatom> 39

48 Γονέας : swrlx:atom Αξίζει να παρατηρήσουμε ότι τα άτομα ισοτήτων ή ανισοτήτων μπορούν να εκφράσουν ισότητα ή ανισότητα αντίστοιχα, συνδυάζοντας μεταβλητές με τα ονόματα των προσωπικοτήτων αντικειμένων. Για παράδειγμα: <swrlx:sameindividualatom> <ruleml:var>x1</ruleml:var> <ruleml:var>x2</ruleml:var> <owlx:individual owlx:name="clinton" /> <owlx:individual owlx:name="bill_clinton" /> </swrlx:sameindividualatom> Τα άτομα των ενσωματωμένων κανόνων παρέχουν μια διεπαφή για τους ενσωματωμένους κανόνες. element swrlx:builtinatom <swrlx:builtinatom swrlx:builtin = xsd:anyuri {required} > Content: ( swrlx:dobject* ) </swrlx:builtinatom> Χαρακτηριστικό: swrlx:builtin αναφορά σε έναν ενσωματωμένο κανόνα Γονέας: swrlx:atom Model group swrlx:iobject Content: ( owlx:individual[id] ruleml:var[id] ) Γονέας: swrlx:classatom, swrlx:individualpropertyatom, swrlx:sameindividualatom, swrlx:differentindividualsatom Model group swrlx:dobject Content: ( owlx:datavalue ruleml:var[id] ) Γονέας: swrlx:datavaluedpropertyatom element ruleml:var [ID] <ruleml:var>xsd:string</ruleml:var> Γονέας: swrlx:iobject, swrlx:dobject το στοιχείο χρησιμοποιείται μεμονωμένα για αναφορές σε ονόματα Σημείωση: μεταβλητών και δεν ορίζει κάποια μεταβλητή όπως το var axiom που είδαμε παραπάνω. 40

49 2.6.1 Παραδείγματα κανόνων με το συντακτικό της XML Στο πρώτο μας παράδειγμα χρησιμοποιούμε την SWRL για να εκφράσουμε ότι ο συνδυασμός των ιδιοτήτων hasparent και hasbrother συνεπάγεται την ιδιότητα hasuncle <ruleml:imp> <ruleml:_rlab ruleml:href="#example1"/> <ruleml:_body> <swrlx:individualpropertyatom swrlx:property="hasparent"> <ruleml:var>x1</ruleml:var> <ruleml:var>x2</ruleml:var> </swrlx:individualpropertyatom> <swrlx:individualpropertyatom swrlx:property="hasbrother"> <ruleml:var>x2</ruleml:var> <ruleml:var>x3</ruleml:var> </swrlx:individualpropertyatom> </ruleml:_body> <ruleml:_head> <swrlx:individualpropertyatom swrlx:property="hasuncle"> <ruleml:var>x1</ruleml:var> <ruleml:var>x3</ruleml:var> </swrlx:individualpropertyatom> </ruleml:_head> </ruleml:imp> Στο επόμενο παράδειγμα κάνουμε χρήση των ενσωματωμένων κανόνων για την μετατροπή των μονάδων μέτρησης. <ruleml:imp> <ruleml:_rlab ruleml:href="#convertlength"/> <owlx:annotation> <owlx:documentation>ex2:lengthininches = ex1:lengthinfeet * 12</owlx:Documentation> </owlx:annotation> <ruleml:_body> <swrlx:datavaluedpropertyatom swrlx:property="&ex1;#lengthinfeet"> <ruleml:var>instance</ruleml:var> <ruleml:var>feet</ruleml:var> </swrlx:datavaluedpropertyatom> </ruleml:_body> <ruleml:_head> <swrlx:builtinatom swrlx:builtin="&swrlb;#multiply"> <ruleml:var>inches</ruleml:var> <ruleml:var>feet</ruleml:var> <owlx:datavalue owlx:datatype="&xsd;#int">12</owlx:datavalue> </swrlx:builtinatom> <swrlx:datavaluedpropertyatom swrlx:property="&ex2;#lengthininches"> 41

50 <ruleml:var>instance</ruleml:var> <ruleml:var>inches</ruleml:var> </swrlx:datavaluedpropertyatom> </ruleml:_head> </ruleml:imp> Συμβουλεύουμε τον αναγνώστη να διαβάσει τα παραρτήματα 4, 5 για περισσότερα παραδείγματα SWRL κανόνων εκφρασμένων στο συντακτικό της XML. 2.7 Ειδικό Συντακτικό για την RDF Στη συνέχεια θα παρουσιάζουμε ένα ειδικό συντακτικό για τους SWRL κανόνες στην RDF. Είναι σχεδιασμένο έτσι ώστε να παρέχει την δυνατότητα παρουσίασης της SWRL στην RDF, άλλα η παρουσία μεταβλητών στους κανόνες υπερβαίνει τα RDF σημασιολογικά. Δεν γνωρίζουμε ακόμη εάν η προοριζόμενη ερμηνεία των RDF γράφων μπορεί να περιγραφεί ως μια σημασιολογική επέκταση της RDF. Το RDF σχήμα για την SWRL είναι το swrl.rdf. Μια OWL οντολογία για την SWRL είναι η swrl.owl. Κάθε ένα αρχείο από τα προηγούμενα παρέχει μονομερείς περιγραφές για συντακτικό της SWRL, αν και το συντακτικό της OWL είναι περιεκτικότερο της RDF Παραδείγματα Κανόνων στο ειδικό συντακτικό της SWRL για την RDF Τα επόμενα παραδείγματα υλοποιούν μια ικανή επέκταση των κανόνων του συντακτικού OWL RDF/XML. Το πρώτο παράδειγμα, είναι επανάληψη του παραδείγματος που προαναφέρθηκε για τις ιδιότητες hasparent και hasbrother όπου εάν και οι δύο είναι αληθείς για συγκεκριμένα δεδομένα, τότε συνεπάγεται η ιδιότητα hasuncle. <swrl:variable rdf:id="x1"/> <swrl:variable rdf:id="x2"/> <swrl:variable rdf:id="x3"/> <ruleml:imp> <ruleml:body rdf:parsetype="collection"> <swrl:individualpropertyatom> <swrl:propertypredicate rdf:resource="&eg;hasparent"/> <swrl:argument1 rdf:resource="#x1" /> <swrl:argument2 rdf:resource="#x2" /> </swrl:individualpropertyatom> <swrl:individualpropertyatom> <swrl:propertypredicate rdf:resource="&eg;hassibling"/> <swrl:argument1 rdf:resource="#x2" /> 42

51 <swrl:argument2 rdf:resource="#x3" /> </swrl:individualpropertyatom> <swrl:individualpropertyatom> <swrl:propertypredicate rdf:resource="&eg;hassex"/> <swrl:argument1 rdf:resource="#x3" /> <swrl:argument2 rdf:resource="#male" /> </swrl:individualpropertyatom> </ruleml:body> <ruleml:head rdf:parsetype="collection"> <swrl:individualpropertyatom> <swrl:propertypredicate rdf:resource="&eg;hasuncle"/> <swrl:argument1 rdf:resource="#x1" /> <swrl:argument2 rdf:resource="#x3" /> </swrl:individualpropertyatom> </ruleml:head> </ruleml:imp> To επόμενο παράδειγμα υλοποιεί τον κανόνα στον οποίο ισχυριζόμαστε ότι το στιλ ενός έργου τέχνης είναι το ίδιο με το στιλ του καλλιτέχνη. <swrl:variable rdf:id="x"/> <swrl:variable rdf:id="y"/> <swrl:variable rdf:id="z"/> <ruleml:imp> <ruleml:body rdf:parsetype="collection"> <swrl:classatom> <swrl:classpredicate rdf:resource="&ulan;artist"/> <swrl:argument1 rdf:resource="#x" /> </swrl:classatom> <swrl:classatom> <swrl:classpredicate rdf:resource="&aat;style"/> <swrl:argument1 rdf:resource="#y" /> </swrl:classatom> <swrl:individualpropertyatom> <swrl:propertypredicate rdf:resource="&aatulan;artiststyle"/> <swrl:argument1 rdf:resource="#x" /> <swrl:argument2 rdf:resource="#y" /> </swrl:individualpropertyatom> <swrl:individualpropertyatom> <swrl:propertypredicate rdf:resource="&vra;creator"/> <swrl:argument1 rdf:resource="#x" /> <swrl:argument2 rdf:resource="#z" /> </swrl:individualpropertyatom> </ruleml:body> <ruleml:head rdf:parsetype="collection"> <swrl:individualpropertyatom> <swrl:propertypredicate rdf:resource="&vra;style/period"/> <swrl:argument1 rdf:resource="#z" /> <swrl:argument2 rdf:resource="#y" /> </swrl:individualpropertyatom> </ruleml:head> </ruleml:imp> 43

52 2.8 Ενσωματωμένοι Κανόνες Το σύνολο των ενσωματωμένων κανόνων της SWRL έχει σχεδιαστεί έτσι ώστε να επιτρέπει περαιτέρω επεκτάσεις των κανόνων στις επόμενες εκδόσεις. Μέχρι στιγμής παρέχει ευκαμψία στα διάφορα OWL μοντέλα, ώστε να επιλέγουν υποσύνολα κανόνων που υποστηρίζονται στις υπάρχουσες εκδόσεις της SWRL. Το σύστημα των ενσωματωμένων κανόνων παρέχει επίσης, διαλειτουργικότητα της SWRL με τους υπόλοιπους διαδικτυακούς φορμαλισμούς παρέχοντας επεκτασιμότητα, υποδομές ενσωματωμένων κανόνων για τις Σημασιολογικές Γλώσσες Διαδικτύου, υπηρεσίες και εφαρμογές διαδικτύου. Οι ενσωματωμένοι κανόνες της SWRL ορίζονται χρησιμοποιώντας το namespace Ενσωματωμένοι Κανόνες για Συγκρίσεις swrlb:equal Ικανοποιήσιμο εάν και μόνο αν το πρώτο και το δεύτερο όρισμα είναι ίσα. swrlb:notequal Η άρνηση του κανόνα swrlb:equal. swrlb:lessthan Ικανοποιήσιμο εάν και μόνο αν το πρώτο και το δεύτερο όρισμα είναι ιδίου τύπου δεδομένων και το πρώτο όρισμα είναι μικρότερο από το δεύτερο σύμφωνα με κάποια συγκεκριμένη σειρά. swrlb:lessthanorequal Μικρότερο ή ίσο σύμφωνα με τα παραπάνω. swrlb:greaterthan Αντίστοιχα με το swrlb:lessthan. swrlb:greaterthanorequal Παρόμοιο με το swrl:lessthanorequal. 44

53 2.8.2 Μαθηματικοί ενσωματωμένοι κανόνες Οι επόμενοι κανόνες ορίζονται για διάφορους αριθμητικούς τύπους. Η σχέση ικανοποιείται αν τα ορίσματα ανήκουν σε συγκεκριμένο αριθμητικό τύπο δεδομένων για τον οποίο ορίζεται η σχέση. swrlb:add Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα είναι ίσο με το αριθμητικό άθροισμα του δεύτερου ορίσματος με το τελευταίο όρισμα. swrlb:subtract Ικανοποιήσιμο εάν και μονό αν το πρώτο όρισμα ισούται με την αριθμητική διαφορά του δεύτερου ορίσματος και του τρίτου. swrlb:multiply Αντίστοιχα για τον αριθμητικό πολλαπλασιασμό. swrlb:divide Αντίστοιχα για την αριθμητική διαίρεση. swrlb:integerdivide Ικανοποιήσιμο εάν το πρώτο όρισμα είναι το ακέραιο πηλίκο της διαίρεσης του δευτέρου ορίσματος με το τρίτο. Μονό οι ακέραιες τιμές της διαίρεσης ελέγχονται. swrlb:mod Αντίστοιχα, ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα ισούται με το υπόλοιπο της διαίρεσης του δευτέρου ορίσματος και του τρίτου. swrlb:pow Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα ισούται με το αποτέλεσμα του δευτέρου ορίσματος στη δύναμη του τρίτου ορίσματος. swrlb:unaryplus Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα ισούται με το δεύτερο και τα ορίσματα τους είναι τα ίδια. swrlb:unaryminus Αντίστοιχα για διαφορετικα ορίσματα. swrlb:abs Ο κανόνας αυτός εκφράζει την απόλυτη τιμή. swrlb:sin Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα αντιστοιχεί στην ημίτονο με τιμή rad του δευτέρου ορίσματος. swrlb:cos Αντίστοιχα για την συνημίτονο. 45

54 swrlb:tan Αντίστοιχα για την εφαπτομένη Ενσωματωμένοι Κανόνες για Δυαδικές τιμές swrlb:booleannot Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα είναι αληθές και το δεύτερο είναι ψευδές ή το ακριβώς αντίθετο Ενσωματωμένοι Κανόνες για Αλφαριθμητικά Οι επόμενοι κανόνες ορίζονται μόνο για αλφαριθμητικά. swrlb:stringequalignorecase Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα είναι το ίδιο με το δεύτερο. Αγνοούμε μικρά η κεφαλαία γράμματα. swrlb:stringconcat Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα είναι το αποτέλεσμα της ένωσης του δευτέρου ορίσματος και του τρίτου. swrlb:substring Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα είναι ίσο με το αλφαριθμητικό μεγέθους ίσου με της τιμής του τετάρτου ορίσματος (επιλεκτικά) και το αλφαριθμητικό ξεκινά από τον χαρακτήρα του τρίτου ορίσματος που υπάρχει στο δεύτερο όρισμα. swrlb:stringlength Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα αντιστοιχεί στο μέγεθος του δευτέρου ορίσματος. swrlb:uppercase Ικανοποιησίμο εάν και μόνο αν το πρώτο γνώρισμα αντιστοιχεί στα κεφαλαία γράμματα του δευτέρου ορίσματος. swrlb:lowercase Αντίστοιχα για τα μικρά γράμματα του δευτέρου ορίσματος. swrlb:contains Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα περιέχει το δευτερο όρισμα. Εδώ γίνεται έλεγχος για κεφαλαία και μικρά γράμματα. swrlb:containsignorecase Αντιστοιχα με το παραπάνω. Εδώ αγνοούμαι αν τα γράμματα είναι κεφαλαία η μικρά. swrlb:startswith Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα ξεκινά με το δεύτερο όρισμα. 46

55 swrlb:endswith Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα τελειώνει με το δεύτερο. swrlb:substringbefore Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα αποτελείται από τους χαρακτήρες του δευτέρου ορίσματος που προηγούνται του τρίτου. swrlb:substringafter Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα αποτελείται από τους χαρακτήρες του δευτέρου ορίσματος που έπονται του τρίτου ορίσματος. swrlb:matches Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα ταιριάζει με την κανονική έκφραση του δευτέρου ορίσματος Ενσωματωμένοι Κανόνες για URIs Οι επόμενοι ενσωματωμένοι κανόνες ορίζονται για τους τύπους δεδομένων των XML Schema που σχετίζονται με τα URIs. swrlb:resolveuri Ικανοποιήσιμο εάν και μόνο αν ή αναφορά URI του πρώτου ορίσματος είναι ίδια με την αναφορά URI του δευτέρου ορίσματος έχοντας ως βάση το τρίτο όρισμα. swrlb:anyuri Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα είναι μια αναφορά URI που περιέχει το σχήμα του δεύτέρου ορίσματος, τον host του τρίτου ορίσματος, τον αριθμό της πόρτας του τέταρτου ορίσματος, το μονοπάτι του πέμπτου, το ερώτημα του έκτου ορίσματος και το τμήμα του εβδόμου ορίσματος Ενσωματωμένοι κανόνες για Λίστες Οι επόμενοι κανόνες ορίζονται για λίστες RDF. Αξίζει να σημειώσουμε ότι αυτοί οι κανόνες δεν μπορούν να χρησιμοποιηθούν από τις υπογλώσσες OWL Lite και DL αφού οι λίστες RDF μπορούν να χρησιμοποιηθούν μόνο στην OWL Full. swrlb:member Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα είναι μέλος της λίστας του δευτέρου ορίσματος 47

56 swrlb:length Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα αντιστοιχεί στο μέγεθος της λίστας του δευτέρου ορίσματος. swrlb:first Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα είναι το πρώτο μέλος της λίστας του δευτέρου ορίσματος. swrlb:rest Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα είναι λίστα που περιέχει την λίστα του δευτέρου ορίσματος χωρίς το πρώτο της μέλος. swrlb:sublist Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα περιέχει την λίστα του δευτέρου ορίσματος swrlb:empty Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα είναι μια κενή λίστα. swrlb:listconcat Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα είναι λίστα που παρουσιάζει την ένωση τον λιστών του δευτέρου και τρίτου ορίσματος. swrlb:listintersection Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα είναι λίστα που περιέχει μέλη που βρίσκονται στις λίστες του δευτέρου και του τρίτου ορίσματος. swrlb:listsubtraction Ικανοποιήσιμο εάν και μόνο αν το πρώτο όρισμα είναι λίστα που περιέχει τα στοιχεία της δεύτερης λίστας που δεν είναι μέλη της λίστας του τρίτου ορίσματος. 48

57 ΚΕΦΑΛΑΙΟ 3 - ΤΟ ΠΡΩΤΟΚΟΛΛΟ SIP 3.1 Εισαγωγή στο SIP Υπάρχουν αρκετές εφαρμογές στο διαδίκτυο που απαιτούν τη δημιουργία και τη διαχείριση μιας συνόδου, όπου ως σύνοδος θεωρείται η ανταλλαγή δεδομένων μεταξύ ενός συνόλου συμμετεχόντων. Η δημιουργία τέτοιων εφαρμογών περιπλέκεται από τις ενέργειες που μπορεί να κάνουν οι συμμετέχοντες: παραδείγματος χάριν μπορεί να κινούνται από τερματικά σημεία σε άλλα, μπορεί να διευθυνσυοδοτούνται χρησιμοποιώντας πολλαπλά ονόματα και μπορεί να επικοινωνούν χρησιμοποιώντας ταυτόχρονα διαφορετικά μέσα. Μέχρι σήμερα έχουν δημιουργηθεί πολυάριθμα πρωτόκολλα, τα οποία χρησιμοποιούν ποικίλους τρόπους συνόδων πραγματικού χρόνου ανταλλαγής πολυμεσικών δεδομένων, όπως φωνής, βίντεο ή μηνυμάτων κειμένου. Το Session Initiation Protocol (SIP)[17] συνεργάζεται πρωτόκολλα επιτρέποντας σε διαδικτυακά τερματικά σημεία, που ονομάζονται πράκτορες χρηστών, να ανακαλύπτουν το ένα το άλλο και να συμφωνούν στα χαρακτηριστικά μιας συνόδου που πρόκειται να διαμοιραστούν. Για τον εντοπισμό πιθανών συμμετεχόντων στη σύνοδο και για άλλες λειτουργίες, το SIP επιτρέπει τη δημιουργία υποδομών δικτυακών εξυπηρετών, που ονομάζονται proxy servers, στους οποίους οι πράκτορες χρηστών μπορούν να στέλνουν μηνύματα εγγραφής, προσκλήσεων σε συνόδους και άλλα αιτήματα. Έτσι το SIP μπορεί να θεωρηθεί ως ένα ευκίνητο εργαλείο γενικού σκοπού για την δημιουργία, παραμετροποίηση και τερματισμό συνόδων το οποίο δουλεύει ανεξάρτητα από το πρωτόκολλα μεταφοράς και του τύπου συνόδου που έχει καθιερωθεί ανάμεσα στους συμμετέχοντες. Επίσης, ένας χρήστης έχει τη δυνατότητα να προσκαλέσει νέους συμμετέχοντες σε ήδη εγκαθιδρυμένες συνόδους, όπως συνόδους περισσότερες των δύο ατόμων. Επιπρόσθετα οι χρήστες μπορούν να αφαιρούν ή να προσθέτουν μέσα επικοινωνίας. Μια ακόμη δυνατότητα του SIP είναι η υποστήριξη χαρτογράφησης ονομάτων και η ύπαρξη υπηρεσιών ανακατεύθυνσης, επιτρέποντας κινητικότητα στους χρήστες. Οι πέντε κύριες παράμετροι για την εγκαθίδρυση και τον τερματισμό μιας πολυμεσικής επικοινωνίας που χρησιμοποιούνται από το SIP είναι οι εξής: Τοποθεσία χρήστη: προσδιορισμός του τερματικού που θα χρησιμοποιηθεί για την επικοινωνία. Διαθεσιμότητα χρήστη: προσδιορισμός της πρόθεσης του καλούμενου να έρθει σε επικοινωνία. Δυνατότητες χρήστη: προσδιορισμός των μέσων που θα χρησιμοποιηθούν καθώς και τον παραμέτρων τους. 49

58 Εγκατάσταση συνόδου: διαπίστευση των παραμέτρων της συνόδου από τον χρήστη που καλεί αλλά και από αυτόν που δέχεται την κλήση. Διαχείριση συνόδου: συμπεριλαμβάνει μετάδοση και τερματισμό συνόδων, παραμετροποίηση των παραμέτρων της συνόδου και τη χρήση υπηρεσιών. 3.2 Μορφή μηνυμάτων στο SIP Τα μηνύματα στο SIP είναι είτε αιτήματα που στέλνει ο χρήστης στον εξυπηρέτη, είτε αποκρίσεις από τον εξυπηρέτη στο χρήστη. Και οι δυο τύποι μηνυμάτων χρησιμοποιούν τη βασική μορφή του RFC 2822[18].Η μορφή και των δύο αυτών τύπων αποτελείται από τα εξής στοιχεία: Μια αρχική γραμμή (first-line ή start-line). Μια ή περισσότερες κεφαλίδες. Μια άδεια γραμμή που δείχνει το τέλος της κεφαλίδας. Ένα σώμα μηνύματος, το οποίο δεν είναι υποχρεωτικό Αιτήματα Τα αιτήματα στο SIP ξεχωρίζουν από την παρουσία της γραμμής αιτήματος στη θέση της αρχικής γραμμής. Η γραμμή αιτήματος περιέχει ένα όνομα μεθόδου, το URI του αιτούντα και την έκδοση του πρωτοκόλλου που ξεχωρίζει με ένα κενό, από τα προηγούμενα στοιχεία. Μέθοδος: Για αυτό το πεδίο ορίζονται 6 διαφορετικά ονόματα μεθόδων: 1. REGISTER (Έγγραφή), για την εγγραφή των στοιχείων επικοινωνίας. 2. INVITE (Πρόσκληση), για την πρόσκληση κάποιο χρήστη σε κάποια σύνοδο ή για την έναρξη μιας συνόδου. 3. ACK (Βεβαίωση λήψης) 4. CANCEL (Ακύρωση), για την ακύρωση μιας συνόδου. 5. BYE, για την σήμανση του τερματισμού μιας συνόδου. 6. OPTIONS (Επιλογές), για ερωτήματα των δυνατοτήτων των εξυπηρετών. Request-URI: Το Request-URI είναι ένα SIP URI ή SIPS URI ή ένα γενικό URI. Δηλώνει το χρήστη ή την υπηρεσία στην οποία το αίτημα αυτό απευθύνεται. Το Request URI δεν θα πρέπει να περιέχει κενούς χαρακτήρες και να περικλείεται σε < >. Τα στοιχεία του SIP υποστηρίζουν Request-URIs με διαφορετικά προθέματα από τα sip και sips, όπως για παράδειγμα το πρόθεμα tel, χρησιμοποιώντας βέβαια κατάλληλους μηχανισμούς μετάφρασης. SIP-Version: Και οι δύο τύποι μηνυμάτων, αιτήματα ή αποκρίσεις, περιέχουν την έκδοση του SIP που χρησιμοποιείται και ανάλογα με αυτή ακολουθούν εντολές 50

59 απαιτήσεων καθώς και αριθμοί αναβάθμισης της έκδοσης. Οι εφαρμογές που στέλνουν SIP μηνύματα θα πρέπει να συμπεριλαμβάνουν στα μηνύματα τους την έκδοση SIP/2.0, έτσι ώστε να συμμορφώνονται με αυτή την προδιαγραφή. Αντίθετα με το HTTP/1.1, το SIP δέχεται τον αριθμό έκδοσης ως αλφαριθμητικό, αν και αυτό στην πραγματικότητα δεν αποτελεί κάποια διαφορά Αποκρίσεις Οι αποκρίσεις του SIP ξεχωρίζουν από τα αιτήματα γιατί έχουν μια γραμμή κατάστασης (status-line) στη θέση της πρώτης γραμμής (start-line) του μηνύματος. Η γραμμή κατάστασης περιέχει την έκδοση του πρωτοκόλλου που ακολουθείται από έναν αριθμό με την ονομασία κωδικός κατάστασης (status-code) καθώς και μια φράση που σχετίζεται με τον κωδικό Ο κωδικός κατάστασης είναι ένας τριψήφιος ακέραιος κωδικός αποτελέσματος που δείχνει το αποτέλεσμα μιας προσπάθειας να κατανοηθεί και να ικανοποιηθεί ένα αίτημα. Η φράση κατάστασης (Reason-Phrase) δίνει μια μικρή επεξήγηση του κωδικού κατάστασης. Πιο συγκεκριμένα, η φράση χρησιμοποιείται για την κατανόηση από τον άνθρωπο ενώ ο κωδικός χρησιμοποιείται από τις μηχανές. Το πρώτο ψηφίο του κωδικού κατάστασης προσδιορίζει την κλάση της απόκρισης, Τα τελευταία δύο ψηφία δεν παίζουν κάποιο ρόλο κατηγοριοποίησης. Για αυτό το λόγο, κάθε απόκριση με κωδικό κατάστασης μεταξύ του 100 και του 199 αναγνωρίζεται ως 1xx response. Αντίστοιχα κωδικός κατάστασης μεταξύ του 200 και του 299 αναγνωρίζεται ως 2xx response κ.ο.κ. Η δεύτερη έκδοση του SIP επιτρέπει 6 τιμές για το πρώτο ψηφίο: 1xx: Προσωρινή κατάσταση, η αίτηση έχει παραληφθεί, συνεχίζεται η επεξεργασία του αιτήματος. 2xx: Επιτυχία, η αίτηση παραλήφθηκε επιτυχώς, έχει κατανοηθεί και έγινε αποδοχή του μηνύματος. 3xx: Προώθηση, πρέπει να γίνουν περισσότερες ενέργειες για την ολοκλήρωση του αιτήματος. 4xx: Σφάλμα πελάτη, το αίτημα περιέχει λάθος συντακτικό ή δεν μπορεί να ικανοποιηθεί σε αυτόν εξυπηρέτη. 5xx: Σφάλμα εξυπηρέτη, ο εξυπηρέτης δεν μπόρεσε να ικανοποιήσει ένα φαινομενικά έγκυρο αίτημα. 6xx: Γενική αποτυχία, το αίτημα δεν μπορεί να ικανοποιηθεί σε κανένα εξυπηρέτη. 51

60 3.2.3 Πεδία Κεφαλίδων Τα πεδία των κεφαλίδων ακολουθούν το πρότυπο του RFC2822[18]. Κάθε πεδίο στην κεφαλίδα αποτελείται από το όνομα του πεδίου και τη τιμή του πεδίου. Η σειρά των πεδίων στις κεφαλίδες δεν είναι και τόσο σημαντική. Ωστόσο, το RFC προτείνει τα πεδία που επεξεργάζονται από τους proxy εξυπηρέτες (όπως τα πεδία Via, Route, Record- Route, Proxy-Require και άλλα) να εμφανίζονται στην αρχή του μηνύματος για να επιτυγχάνεται γρηγορότερη ανάλυση. Επίσης, σημαντικό είναι τα πεδία με τα ίδια ονόματα να τοποθετούνται στην ίδια σειρά. Πολλαπλά πεδία με ίδιο όνομα θα πρέπει να βρίσκονται στο ίδιο μήνυμα εάν και μόνο αν ολόκληρο το πεδίο ορίζεται ως λίστα που τα στοιχεία της ξεχωρίζουν με κόμμα (, ). Οπότε, παρέχεται η δυνατότητα να συνδυάζονται πολλαπλές γραμμές πεδίων σε ένα, επισυνάπτοντας κάθε συνακόλουθη τιμή στην αρχική χωρίς να αλλάζει η σημασιολογία του μηνύματος. Εξαιρέσεις σε αυτόν τον κανόνα αποτελούν τα πεδία WWW-Authenticate, Authorization, Proxy-Authenticate και Proxy-Authorization. Η τυπική δομή της κεφαλίδας ως μέρος ενός SIP μηνύματος είναι η παρακάτω : Πεδίο Via : περιέχει την διεύθυνση από την οποία ο αιτούμενος περιμένει να πάρει τις αποκρίσεις στο αίτημα του, μπορεί επίσης να ακολουθείται από την παράμετρο branch που αναγνωρίζει ξεχωριστά κάθε δοσοληψία. Πεδίο To : περιέχει ένα εμφανιζόμενο όνομα και το SIP URI στο οποίο η αίτηση αναφέρεται. Πεδίο From : περιέχει επίσης ένα εμφανιζόμενο όνομα και το SIP URI που αναφέρει τον αποστολέα της αίτησης. Επιπρόσθετα, το πεδίο έχει μια παράμετρο ετικέτας που περιέχει ένα τυχαίο αλφαριθμητικό το οποίο προστίθεται στο URI από το λογισμικό τηλεφώνου και χρησιμοποιείται για σκοπούς αναγνώρισης. Πεδίο Call-Id : περιέχει ένα διεθνές αναγνωριστικό για την συγκεκριμένη κλίση, συνδυάζει ένα τυχαίο αλφαριθμητικό και το όνομα του εξυπηρέτη του λογισμικού τηλεφώνου ή την IP διεύθυνση του. Ο συνδυασμός των πεδίων To, From και Call-Id ορίζει στο σύνολό του μια ομότιμη SIP συσχέτιση μεταξύ του αιτούμενου και του αποκρινόμενου. Πεδίο CSeq ή Command Sequence: αποτελείται από έναν ακέραιο αριθμό και το όνομα μιας μεθόδου. Ο αριθμός αυτός αυξάνεται για κάθε νέα αίτηση κατά τη διάρκεια μιας συνόδου. Πεδίο Contact : περιέχει ένα SIP URI που αποτελεί μια διαδρομή για να επικοινωνήσει κάποιος με τον αιτούμενο. Συνήθως έχει τη μορφή ενός πλήρους ονόματος πεδίου. Ενώ μια τέτοια μορφή είναι προτιμητέα, αρκετά συστήματα δεν έχουν επίσημα ονόματα πεδίου, οπότε σε τέτοιες περιπτώσεις επιτρέπεται και η χρήση της IP του συστήματος. Το πεδίο Via ενημερώνει τα υπόλοιπα στοιχεία που να αποστέλλουν τις αποκρίσεις, ενώ το πεδίο Contact ενημερώνει τα υπόλοιπα στοιχεία που να αποστέλλουν τα μελλοντικά αιτήματα τους. 52

61 Πεδίο Max Forwards : χρησιμοποιείται για να οριοθετεί το πλήθος των hops που μπορεί να κάνει ένα αίτημα προκειμένου να ανακαλύψει τον παράλήπτη. Αποτελείται από έναν ακέραιο αριθμό που μειώνεται κατά ένα σε κάθε hop. Πεδίο Content-type : περιέχει μια περιγραφή του σώματος του μηνύματος. Πεδίο Content-length : περιέχει το πλήθος των bytes από τα οποία αποτελείται το μήνυμα Σώμα μηνύματος Οι αιτήσεις συμπεριλαμβανομένων και των νέων αιτημάτων ορίζονται ως επεκτάσεις στην προδιαγραφή του SIP[17] και μπορούν να περιέχουν σώματα μηνύματος. Η ερμηνεία του σώματος εξαρτάται από την μέθοδο της αίτησης. Για τα μηνύματα των αποκρίσεων, η μέθοδος απόκρισης και ο κωδικός της κατάστασης της απόκρισης καθορίζουν τον τύπο και την σημασία κάθε σώματος μηνύματος. Όλες οι αποκρίσεις μπορούν να περιλαμβάνουν σώμα μηνύματος. Τύπος Σώματος Μηνύματος O τύπος του μέσου του σώματος μηνύματος θα πρέπει να ορίζεται στο πεδίο Content- Type της κεφαλίδας του μηνύματος. Αν το μήνυμα έχει υποστεί κάποια κωδικοποίηση αυτή θα πρέπει να ορίζεται στο πεδίο Content-Encoding. Επίσης, ο τύπος των χαρακτήρων μπορεί να ορίζεται ως μέρος του πεδίου Content-Type. Τα μηνύματα στο SIP μπορεί να περιέχουν δυαδικά σώματα ή μέρη των σωμάτων τους μπορεί να είναι σε αυτή τη μορφή. Όταν δεν ορίζεται κάποιος συγκεκριμένος τύπος χαρακτήρων τότε θεωρείται ως προεπιλεγμένη τιμή η UTF-8. Μήκος Σώματος Μηνύματος Το μήκος τους μηνύματος σε bytes παρέχεται από το πεδίο Content-Length. Η μέθοδος τεμαχισμού των πακέτων που χρησιμοποιείται από το πρωτόκολλο HTTP/1.1 δε θα πρέπει να χρησιμοποιείται στο SIP, επειδή κάθε μήνυμα τεμαχίζεται σε τυχαίου μεγέθους πακέτα. SIP Message First Line [Message-type] [SIP-URI]* [Version] Header [Via] [From] [To] [Contact] [Call-ID] [CSeq] [Content- Type] [Content-Length] Message Body Πίνακας [2] Η δομή ενός SIP μηνύματος 53

62 3.3 Επισκόπηση Λειτουργίας Στη συνέχεια παρουσιάζονται οι βασικές λειτουργίες του SIP χρησιμοποιώντας ορισμένα παραδείγματα. Το πρώτο από αυτά παρουσιάζει τις βασικές λειτουργίες του SIP: εύρεση τοποθεσίας τερματικού σημείου, σηματοδότηση της επιθυμίας για επικοινωνία, διαπραγμάτευση των παραμέτρων της συνόδου για την εγκαθίδρυση αυτής και τερματισμό της συνόδου από την στιγμή που αυτή έχει εγκαθιδρυθεί. Στην Εικόνα 1 φαίνεται ένα τυπικό παράδειγμα ανταλλαγής μηνυμάτων SIP ανάμεσα σε δύο χρήστες την Alice και τον Bob. Σε αυτό το παράδειγμα, η Alice χρησιμοποιεί μια SIP εφαρμογή από τον υπολογιστή της (συνήθως ονομάζεται softphone, δηλαδή λογισμικό τηλέφωνο) για να καλέσει τον Bob στο SIP τηλέφωνο του μέσω του διαδικτύου. Επίσης υπάρχουν δύο proxy εξηπηρέτες ανάμεσα στον Bob και την Alice για την εγκαθίδρυση της συνόδου. Η Alice καλεί τον Bob χρησιμοποιώντας την SIP ταυτότητα, ένα είδος URI που αναφέρεται ως SIP URI και έχει παρόμοια μορφή με αυτή των διευθύνσεων και συνήθως αποτελείται από το όνομα χρήστη και το όνομα του εξυπηρέτη. Στην περίπτωση μας το SIP URI του Bob είναι: sip:bob@biloxi.com, και της Alice sip:alice@atlanta.com. Το SIP βασίζεται στο μοντέλο δοσοληψιών HTTP αιτήσεων αποκρίσεων. Κάθε δοσοληψία εμπεριέχει μια αίτηση που θέτει σε λειτουργία συγκεκριμένες μεθόδους ή λειτουργίες στον εξυπηρέτη και τουλάχιστον μια απόκριση. Στο παράδειγμα μας, η δοσοληψία ξεκινά από το λογισμικό τηλέφωνο της Alice που στέλνει μια αίτηση INVITE που δρομολογείται στο SIP URI του Bob. Η αίτηση INVITE αποτελεί ένα παράδειγμα SIP μεθόδου που καθορίζει την ενέργεια που ο αιτών, σε αυτή την περίπτωση η Alice, θέλει ο εξυπηρέτης (στην περίπτωσή μας του Bob) να χειριστεί. Το μήνυμα INVITE αποτελείται από πολλά πεδία κεφαλίδων τα οποία θα αναλυθούν στην συνέχεια. Τα πεδία των κεφαλίδων είναι χαρακτηριστικά που παρέχουν επιπρόσθετες πληροφορίες για το μήνυμα. Το παράδειγμα μας ξεκινά από το INVITE μήνυμα της Alice. 54

63 Εικόνα [1] Ανταλλαγή SIP μηνυμάτων Δημιουργία κλίσης Η μορφή του μηνύματος που στέλνει η Alice είναι η παρακάτω: INVITE SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bk776asdhds Max-Forwards: 70 To: Bob From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 142 Εικόνα [2] Μια τυπική αίτηση στο SIP Η πρώτη γραμμή του μηνύματος περιέχει το όνομα της μεθόδου που χρησιμοποιείται στο παράδειγμα μας INVITE. Οι επόμενες γραμμές είναι η λίστα των πεδίων της κεφαλίδας που αναλύθηκαν παραπάνω. Τo παράδειγμα μας περιέχει το ελάχιστο σύνολο των πεδίων που απαιτείται για ένα τυπικό μήνυμα. Οι αναλυτικές ρυθμίσεις της συνόδου, όπως ο τύπος των μέσων που θα χρησιμοποιηθούν για την συνομιλία, ή το πλήθος των δειγμάτων, δεν περιγράφονται χρησιμοποιώντας το SIP. Ωστόσο, το σώμα ενός SIP μηνύματος περιέχει μια περιγραφή της συνόδου, κρυπτογραφημένη σε μορφή άλλου πρωτοκόλλου. Μια τέτοια μορφή χρησιμοποιείται από το πρωτόκολλο περιγραφής συνόδου SDP. Τα μηνύματα SDP εμπεριέχονται στα 55

64 μηνύματα SIP με έναν τρόπο ανάλογο με την επισύναψη αρχείων στην ηλεκτρονική αλληλογραφία. Από τη στιγμή που το τηλέφωνο λογισμικού δεν γνωρίζει την τοποθεσία του Bob ή τον SIP server του πεδίου Biloxi.com στέλνει το INVITE μήνυμα στον εξυπηρέτη της Alice. Η διεύθυνση του εξυπηρέτη της Alice μπορεί να έχει παραμετροποιηθεί στο λογισμικό της Alice ή μπορεί να βρεθεί από έναν DHCP. Ένας proxy εξυπηρέτης δέχεται SIP αιτήματα και τα προωθεί προς όφελος του αιτούντα. Στο παράδειγμα μας ο εξυπηρέτης της Alice δέχεται την αίτηση της και απαντά με ένα μήνυμα 100 (trying), δείχνοντας ότι έχει παραλάβει την αίτηση της και εργάζεται προκειμένου να παραδώσει το μήνυμα της. Η απόκριση αυτή περιέχει τα ίδια πεδία To, From, Call-ID, CSeq και την παράμετρο branch στο πεδίο Via όπως και το INVITE επιτρέποντας έτσι στο τηλέφωνο της Alice να συσχετίσει την απόκριση με το αίτημα της. Στη συνέχεια ο proxy εξυπηρέτης αναζητά τον Biloxi.com εξυπηρέτη, πιθανότατα μέσω του DNS, έτσι ώστε να βρει τον SIP εξυπηρέτη που παρέχει υπηρεσίες για αυτό το πεδίο. Το αποτέλεσμα αυτής της αναζήτησης είναι η IP διεύθυνση του αναζητούμενου εξυπηρέτη και η προώθηση του INVITE μηνύματος. Πριν όμως ο εξυπηρέτης της Atlanta.com προωθήσει το μήνυμα, προσθέτει ένα επιπρόσθετο πεδίο Via που περιέχει την διεύθυνση του. Ο Biloxi.com εξυπηρέτης με τη σειρά του απαντά με μια 100 απόκριση έτσι ώστε να δείξει ότι δέχτηκε το μήνυμα και επεξεργάζεται την αίτηση. Στη συνέχεια, αναζητά την IP διεύθυνση του Bob και αποστέλλει την αίτηση προσθέτοντας και αυτός τα στοιχεία του σε ένα νέο πεδίο Via. Το SIP τηλέφωνο του Bob δέχεται την αίτηση και ειδοποιεί τον Bob για την εισερχόμενη κλήση από την Alice, έτσι ώστε αυτή να αποφασίσει αν θα δεχτεί την κλήση ή αν θα την απορρίψει. Το τηλέφωνο του Bob δείχνει ότι χτυπά αποστέλλοντας μια απόκριση 180 μέσω των δύο εξυπηρετών ακολουθώντας την ακριβώς αντίστροφη πορεία του μηνύματος που έφτασε σε αυτόν. Όταν το τηλέφωνο της Alice δεχτεί την απόκριση αυτή προωθεί την πληροφορία στην Alice πιθανότατα με έναν ήχο που της δείχνει ότι καλεί, ή εμφανίζοντας ένα κατάλληλο μήνυμα στην οθόνη. Στο παράδειγμά μας ο Bob αποφασίζει να απαντήσει στην κλήση. Όταν σηκώσει το ακουστικό, το τηλέφωνο του στέλνει ένα μήνυμα 200 (ok) για να δείξει ότι η κλήση έχει απαντηθεί. Το επόμενο βήμα είναι η ανταλλαγή SDP μηνυμάτων τα οποία περιγράφουν τα μέσα που θα χρησιμοποιηθούν στη σύνοδο. Αν ο Bob ήθελε να απορρίψει την κλήση μια απόκριση σφάλματος θα έφτανε πίσω στην Alice και δεν θα απαιτούνταν η ανταλλαγή μηνυμάτων περιγραφής της συνόδου. Το μήνυμα αποδοχής της κλήσης που στέλνει το τηλέφωνο του Bob έχει την παρακάτω μορφή: 56

65 SIP/ OK Via: SIP/2.0/UDP server10.biloxi.com ;branch=z9hg4bknashds8;received= Via: SIP/2.0/UDP bigbox3.site3.atlanta.com ;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hg4bk776asdhds ;received= To: Bob From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 131 Εικόνα [3] Μια τυπική απόκριση στο SIP Η σύνοδος μεταξύ των δυο μερών έχει ξεκινήσει και αποστέλλονται πακέτα δεδομένων χρησιμοποιώντας τη μορφή στην οποία και οι δύο συμφώνησαν κατά την ανταλλαγή των SDP μηνυμάτων. Κατά τη διάρκεια της συνόδου, οι συμμετέχοντες μπορεί να αλλάξουν τα χαρακτηριστικά της. Αυτό επιτυγχάνεται με την αποστολή ενός νέου INVITE μηνύματος που περιέχει τις νέες περιγραφές. Μόλις ο ένας συμμετέχοντας αποδεχτεί τις νέες ρυθμίσεις ο αιτούντας του απαντά με ένα ACK μήνυμα. Αντίστοιχα, αν ο συνομιλητής δεν αποδεχτεί τις νέες ρυθμίσεις αποκρίνεται με ένα 408 μήνυμα (Not Acceptable Here) και επίσης δέχεται ένα ACK μήνυμα. Το γεγονός αυτό δεν επηρεάζει τη τρέχουσα σύνοδο. Κατά τη διακοπή της συνομιλίας, ο Bob κλείνει το τηλέφωνο πρώτος στέλνοντας ένα BYE μήνυμα. Η Alice αποκρίνεται με ένα 200 (ok) μήνυμα, το οποίο τερματίζει την σύνοδο και την δοσοληψία. 57

66 3.4 Αρχιτεκτονική Λειτουργίας του SIP Μια τυπική δικτυακή υποδομή για την λειτουργία του SIP πρέπει να εμπεριέχει τα παρακάτω στοιχεία. User Agents - UAs (Πράκτορες Χρηστών): Οι πράκτορες που χρησιμοποιούνται από ένα χρήστη λειτουργούν αντί για αυτόν σε ένα τερματικό. Ο πράκτορας του πελάτη (UAC), είναι υπεύθυνος για την δημιουργία των αιτημάτων του ενώ ο πράκτορας του εξυπηρέτη (UAS) επεξεργάζεται και αποκρίνεται σε κάθε αίτημα που δέχεται από τον πελάτη. Registar Server (Εξυπηρέτης Εγγραφών): Οι πράκτορες των πελατών επικοινωνούν με τους εξυπηρέτες εγγραφών για να δηλώσουν την ύπαρξή τους στο δίκτυο. Μια βάση δεδομένων που περιέχει τις τοποθεσίες των χρηστών καθώς και τις ρυθμίσεις που αυτοί επιθυμούν να έχουν αποτελούν τον εξυπηρέτη registar. Proxy Server: Ένας proxy εξυπηρέτης λαμβάνει τα αιτήματα των χρηστών και τα προωθεί στην τοποθεσία του χρήστη που δέχεται την κλήση είτε προωθώντας τα άμεσα στον καλούμενο είτε προωθώντας τα σε άλλο εξυπηρέτη ο οποίος γνωρίζει την τοποθεσία του χρήστη. Redirect Server (Εξυπηρέτης ανακατεύθυνσης): Ο εξυπηρέτης ανακατεύθυνσης δέχεται τα αιτήματα από τους πράκτορες των χρηστών και τους ενημερώνει για τον εξυπηρέτη που βρίσκεται στο επόμενο hop. Στη συνέχεια ο πράκτορας του χρήστη επικοινωνεί με αυτόν τον εξυπηρέτη. Εικόνα [4] Εικονικό παράδειγμα αρχιτεκτονικής του SIP 58

67 3.5 Μηχανισμοί ασφάλειας στο SIP Η δημιουργία νέων υπηρεσιών για την εγκαθίδρυση πολυμεσικών συνόδων στο διαδίκτυο καθιστά αναγκαία τη δημιουργία μηχανισμών ασφάλειας για την προστασία των μεταδιδόμενων δεδομένων από κακόβουλους χρήστες που θέλουν να τα αλλάξουν, να υποκλέψουν τα δεδομένα ή να επηρεάσουν μια σύνοδο. Επιθέσεις τέτοιου είδους μπορούν να συμβούν κατά τη διάρκεια σύναψης της συνόδου, είτε κατά τη διάρκεια της μετάδοσης των δεδομένων. Άρα λοιπόν, τα δεδομένα εγκαθίδρυσης συνόδου και της συνομιλίας απαιτούν κατάλληλους μηχανισμούς ασφάλειας. Στη συνέχεια, θα περιγραφούν υπηρεσίες παροχής ασφάλειας που βασίζονται στο SIP οι οποίες σχετίζονται με τα δεδομένα που μεταδίδονται από τη στιγμή που θα εγκαθιδρυθεί μια σύνοδος. Η προδιαγραφή του SIP δεν συμπεριλαμβάνει κανέναν συγκεκριμένο μηχανισμό ασφάλειας. Προτείνεται όμως η αξιοποίηση ήδη γνωστών διαδικτυακών μηχανισμών. Πιο συγκεκριμένα, οι επόμενες μέθοδοι περιγράφονται στην προδιαγραφή του SΙP για την παροχή ασφάλειας. Αυθεντικοποίηση: Ο αλγόριθμος σύνοψης για την αυθεντικοποίηση που περιγράφεται στο RFC 2617[19] είναι ένα challenge response πρωτόκολλο. Μέχρι στιγμής αποτελεί τον πιο διαδεδομένο μηχανισμό ασφάλειας στο SIP για την επαλήθευση των χρηστών και την αυθεντικοποίηση των μηνυμάτων. Ένας εξυπηρέτης πρέπει να αυθεντικοποιεί τον πελάτη και αποστολέα των αιτήσεων/αποκρίσεων, σύμφωνα με τις προκαθορισμένες ρυθμίσεις των SIP εξυπηρετών. Αυτός ο μηχανισμός μπορεί να εφαρμοστεί σε συγκεκριμένα αιτήματα, σε συγκεκριμένους χρήστες και από συγκεκριμένους εξυπηρέτες. Η ακολουθία μηνυμάτων που παρουσιάζεται στη συνέχεια απαιτείται για την εφαρμογή της HTTP αυθεντικοποίησης σύνοψης στο SIP : 1. Ο πελάτης στέλνει ένα SIP μήνυμα (π.χ. SIP REGISTER) στον εξυπηρέτη απαιτώντας αυθεντικοποίηση, η απάντηση που θα λάβει είναι είτε η αυθεντικοποίηση του εξυπηρέτη (407, proxy server response), είτε απάντηση μη εξουσιοδότησης (401, register or redirect server response). 2. Η απάντηση που θα λάβει ο πελάτης, περιέχει μια κεφαλίδα αυθεντικοποίησης WWW, που περιέχει ένα challenge, αυτό στη συνέχεια θα χρησιμοποιηθεί από τον πελάτη για τον υπολογισμό των διαπιστευτηρίων. 3. Στη συνέχεια, ο πελάτης δημιουργεί ένα SIP μήνυμα που συμπεριλαμβάνει μια κεφαλίδα αυθεντικοποίησης με τα υπολογισμένα διαπιστευτήρια. IPsec και SIP: Το πρωτόκολλο διαδικτύου (IP) χρησιμοποιείται για την μετάδοση των SIP μηνυμάτων, το οποίο όμως, είναι ευάλωτο σε επιθέσεις τύπου παραπλάνησης, υποκλοπής της συνόδου, ανάλυσης της κυκλοφορία των πακέτων κ.α. Το IPsec[20] λειτουργεί ξεχωριστά στο επίπεδο IP και παρέχει ένα σύνολο υπηρεσιών για την προστασία των IP πακέτων, από τέτοιου είδους επιθέσεις. Μπορεί να προσφέρει εμπιστευτικότητα, ακεραιότητα και μηχανισμούς αυθεντικοποίησης της πηγής των δεδομένων, όπως και προστασία της κίνησης του δικτύου αξιοποιώντας τα πρωτόκολλα ενθυλάκωσης (Encapsulading Security Paylod) και κεφαλίδων αυθεντικοποίησης 59

68 (Authentication Header). Η χρήση του IPsec από το SIP διασφαλίζει τα δεδομένα από διάφορες δικτυακές ευπάθειες, παρέχοντας κάποια εμπιστοσύνη, πριν ακόμα οι συνομιλητές ανταλλάξουν χειραψία μεταξύ τους. Transport Secure Layer (TLS)[21]: Ένας άλλος τρόπος προστασίας για τις επικοινωνίες μέσω του SIP επιτυγχάνεται με την χρήση του πρωτοκόλλου ασφάλειας επιπέδου μετάδοσης (TLS). Εδώ επιτυγχάνουμε αυθεντικοποίηση των στοιχείων του δικτύου με χειραψίες, οι οποίες προϋποθέτουν αμοιβαία ανταλλαγή πιστοποιητικών. Επιπρόσθετα, το TLS μπορεί να αποτελέσει μέρος του SIP, καθώς τρέχει πάνω από το TCP/IP και σε πρωτόκολλα ανωτέρου επιπέδου όπως το HTTP και το FTP, αν και οι κεφαλίδες του TCP δεν μπορούν να κρυπτογραφηθούν. Ωστόσο μέχρι στιγμής το TLS δεν μπορεί να συνδυαστεί με το UDP. Επίσης, οι πολλές ανοιχτές TCP συνδέσεις μπορεί να αποτελέσουν πρόβλημα για τον SIP proxy εξυπηρέτη κοστίζοντας του σε μνήμη. Το SIP παρέχει ασφαλείς συνδέσεις χρησιμοποιώντας το SIP Secure URI (π.χ. Άξιο προσοχής όμως είναι το γεγονός ότι, το TLS δεν υποστηρίζεται πλήρως από τους υπάρχοντες πράκτορες χρηστών. Authentication, Authorization, Accounting Services in SIP: Για την αυθεντικοποίηση και την εξουσιοδότηση των χρηστών, καθώς και για την παροχή λογιστικών υπηρεσιών, είναι ευκολότερο για τις οντότητες του SIP να επικοινωνούν με ένα εξυπηρέτη αυθεντικοποίησης, εξουσιοδότησης, και λογιστικής καταγραφής, αντί να αποθηκεύουν τοπικά τα πιστοποιητικά των χρηστών όπως απαιτείται από τον αλγόριθμο σύνοψης HTTP. Επιπρόσθετα, ένας AAA εξυπηρέτης παρέχει τη δυνατότητα στους διαχειριστές του να ρυθμίζουν δυναμικά την μέθοδο της αυθεντικοποίησης και της εξουσιοδότησης που απαιτείται, π.χ. ανά χρήστη ή ανά υπηρεσία. Εκτός από αυτό, η διασύνδεση ετερογενών δικτύων, συνήθως οδηγεί στην πρόσβαση των SIP υπηρεσιών αξιοποιώντας τις στο δίκτυο. Το γεγονός αυτό, δίνει την δυνατότητα σε κινούμενους χρήστες να έχουν πρόσβαση σε πολυμεσικές εφαρμογές σε διαφορετικά δίκτυα. Η ύπαρξη κινούμενων χρηστών απαιτεί επιπρόσθετους μηχανισμούς στον AAA εξυπηρέτη. Για την παροχή τέτοιων μηχανισμών, αξιοποιούνται πρωτόκολλα όπως το Radius[22] ή το Diameter[23], τα οποία προτείνεται να ενσωματωθούν στην αρχιτεκτονική του SIP. Για την αξιοποίηση των δυνατοτήτων που παρέχει ένας ΑΑΑ εξυπηρέτης στο SIP, απαιτείται η χρήση μηχανισμών που περιγράφονται στο RFC 3702[24]. S/MIME και SIP: Τα μηνύματα του SIP μπορούν να περιέχουν MIME σώματα[17]. Για αυτό το λόγο, μηχανισμοί ασφάλειας μπορούν να αξιοποιηθούν χρησιμοποιώντας το S/MIME[25]. Από τους μηχανισμούς ασφάλειας που παρέχει το S/MIME το SIP αξιοποιεί μόνο δύο tunneling ακεραιότητας και αυθεντικοποίησης και tunneling κρυπτογραφίας. Ωστόσο, αυτή η λύση απαιτεί υποδομές δημοσίων κλειδιών, διαφορετικά η ανταλλαγή δημοσίων κλειδιών από τους χρήστες θα είναι ευάλωτη σε επιθέσεις MITM (Man in the Middle). 60

69 3.5.1 Αξιολόγηση των Μηχανισμών Ασφάλειας του SIP Όπως προαναφέρθηκε, ο αλγόριθμος σύνοψης HTTP χρησιμοποιείται συνήθως ως μηχανισμός ασφάλειας για το SIP. Αν και προσφέρει αυθεντικοποίηση του μηνύματος και προστασία της απάντησης του δεν μπορεί να παρέχει ακεραιότητα και εμπιστευτικότητα στα μηνύματα. Επίσης, σύμφωνα με το RFC 3261[17], ένας κακόβουλος χρήστης μπορεί να κάνει spam κλήσεις. Επιπρόσθετα, η μέθοδος αυτή είναι ευάλωτη σε επιθέσεις MITM (Μan in the middle) καθώς χρησιμοποιεί μηνύματα αρχικού κειμένου (plaintext) και έτσι κάποιος ωτακουστής μπορεί να υποκλέψει το αρχικό αλλά και το κρυπτογραφημένο μήνυμα. Ο αλγόριθμος αυτός απαιτεί ακόμη και ένα έμπιστο περιβάλλον για τη διανομή των κωδικών. Οι κωδικοί μπορεί να είναι αποθηκευμένοι στον εξυπηρέτη είτε σε μορφή αρχικού κειμένου είτε κρυπτογραφημένοι. Ωστόσο, τα κρυπτογραφημένα μηνύματα δεν προσφέρουν υψηλά επίπεδα ασφάλειας αφού είναι εφικτός ο υπολογισμός των πιστοποιητικών του μηνύματος με επιθέσεις του τύπου brute force. Περαιτέρω, λόγω της απουσίας συσχετισμού του ονόματος του χρήστη με το SIP URI του, ένας κακόβουλος χρήστης μπορεί να παρουσιαστεί ως κανονικός. Αν και έχουν προταθεί διάφορες λύσεις για την αντιμετώπιση αυτών των προβλημάτων που παρουσιάζονται στον αλγόριθμο σύνοψης HTTP, απαιτούνται αλλαγές και στους πράκτορες των χρηστών για την υιοθέτηση των λύσεων. Το γεγονός ότι δεν υπάρχει κανένα μοντέλο αυθεντικοποίησης αφήνει ανοικτό το ενδεχόμενο σε κάποιον επιτιθέμενο να έχει πρόσβαση σε υπηρεσίες που είναι διαθέσιμες στους κανονικούς χρήστες. Ένα άλλο σημαντικό πρόβλημα είναι ότι οι ενδιάμεσοι SIP proxy εξυπηρέτες δεν μπορούν να γνωρίζουν ότι ο πράκτορας του χρήστη έχει αυθεντικοποιηθεί. Εξίσου σημαντική είναι και η προστασία των προσωπικών δεδομένων του χρήστη και της αληθινής του ταυτότητας, άρα απαιτείται η παροχή ανωνυμίας, ιδιωτικότητας και ιδιωτικότητα της τοποθεσίας του χρήστη. Οι πράκτορες των χρηστών μπορούν αν παρέχουν ανωνυμία «κρύβοντας» το πεδίο From: από της κεφαλίδες των αιτήσεων. Ωστόσο, κάτι τέτοιο δεν μπορεί να γίνει με όλα τα πεδία των κεφαλίδων. Για παράδειγμα, το πεδίο Contact: της κεφαλίδας χρησιμοποιείται για την εύρεση της διαδρομής του αιτήματος και δεν μπορεί να προστατευθεί. Συνεπώς, ένα ικανό επίπεδο ιδιωτικότητας δεν μπορεί να διασφαλιστεί χωρίς κατάλληλες υποδομές στους SIP proxy εξυπηρέτες. Η προστασία που παρέχεται από το IPsec, υποθέτει μια προυπάρχουσα εμπιστοσύνη στους συνομιλητές και μπορεί να αξιοποιηθεί μόνο σε μοντέλα hop by hop. Αν και το IPsec εφαρμόζεται στα επίπεδα λειτουργικού συστήματος, οι περισσότεροι πελάτες του SIP δεν εφαρμόζουν αυτό το πρωτόκολλο. Για αυτό το λόγο το IPsec μπορεί να προστατεύει μόνο την κίνηση ανάμεσα στους εξυπηρέτες του δικτύου. Επιπρόσθετα, οι προδιαγραφές του SIP δεν προτείνουν κάποιο πλαίσιο διαχείρισης κλειδιών, το οποίο όμως απαιτείται για την ανταλλαγή κλειδιών στο διαδίκτυο. Σε αντίθεση με το IPsec, το TLS δεν χρειάζεται κάποια σχέση εμπιστοσύνης μεταξύ των συνομιλητών. Μπορεί όμως να χρησιμοποιηθεί για μονομερής αυθεντικοποίηση και είναι καταλληλότερο για αυθεντικοποίηση εντός του ιδίου πεδίου. Ωστόσο το TLS αποτυγχάνει να παρέχει ασφάλεια από άκρη σε άκρη και μέχρι στιγμής δεν υπάρχει κάποιος μηχανισμός που να διαβεβαιώνει ότι το πρωτόκολλο αξιοποιείται σε ολόκληρη 61

70 την διαδρομή παράδοσης ενός πακέτου και από όλους τους εμπλεκόμενους. Με δύο λόγια, η απουσία μιας PKI υποδομής στο VoIP, καθιστά την εφαρμογή λύσεων όπως το TLS προβληματική. Το S/MIME υποστηρίζει ακεραιότητα και εμπιστευτικότητα από άκρη σε άκρη. Αλλά, μεγαλώνει το μέγεθος των SIP μηνυμάτων. Επιπρόσθετα, δεν προστατεύεται η ακεραιότητα και η εμπιστευτικότητα ολόκληρου του μηνύματος, επειδή δεν επιτρέπεται η μεταβολή της κεφαλίδας, καθώς οι ενδιάμεσοι κόμβοι πρέπει να έχουν πρόσβαση σε αυτή για την επεξεργασία και την δρομολόγηση του μηνύματος. Όπως και στο TLS η απουσία μιας PKI υποδομής αποτελεί έναν επιπλέον περιορισμό στην διαλειτουργικότητα του S/MIME και του SIP. Εκτός από τους προαναφερόμενους περιορισμούς, σε κάποιες περιπτώσεις οι υπηρεσίες ασφάλειας μπορεί να απαιτούν τον συνδυασμό του TLS και του S/MIME. Συμπεριλαμβάνοντας έτσι την χρήση του TLS για την υποστήριξη της ακεραιότητας και της αυθεντικοποίησης και του S/MIME για την ιδιωτικότητα τμημάτων των μεταδιδόμενων δεδομένων. Ωστόσο, κάποιοι ενδιάμεσοι κόμβοι μπορεί να χρειάζεται να διαβάσουν αυτά τα δεδομένα. Για το λόγο αυτό, χρειάζεται ένας μηχανισμός ασφάλειας για τη διασφάλιση του σώματος των μηνυμάτων και των κεφαλίδων μεταξύ των πρακτόρων των χρηστών και των proxy εξυπηρετών, παρέχοντας ταυτόχρονα τις κατάλληλες πληροφορίες σε αυτούς που τις χρειάζονται. Αυτός ο μηχανισμός ονομάζεται ασφάλεια από την άκρη ως την μέση (end-to-middle). 3.6 Σημεία ευπάθειας στο SIP και Άρνηση Παροχής Υπηρεσιών στα SIP Δίκτυα Παρά τη χρήση των μηχανισμών που αναφέρθηκαν στο προηγούμενο μέρος, οι υπηρεσίες του SIP παραμένουν ευάλωτες. Ο στόχος κάθε επίθεσης είναι είτε η διακοπή της υπηρεσίας που είναι γνωστή και ως άρνηση παροχής υπηρεσιών (Denial of Service) DOS, είτε η μη εξουσιοδοτημένη πρόσβαση σε υπολογιστικούς πόρους. Αφού το SIP αξιοποιεί γνωστές διαδικτυακές τεχνολογίες, κληρονομεί όλα τα γνωστά σημεία ευπάθειας που υπάρχουν στην διαδικτυακή σφαίρα. Επιπρόσθετα, υπάρχουν κάποιες συγκεκριμένες επιθέσεις που στοχεύουν αποκλειστικά στο SIP. Όλα τα στοιχεία μιας SIP αρχιτεκτονικής (π.χ. proxy registar servers, συσκευές χρηστών), είναι ευάλωτα σε τέτοιου είδους επιθέσεις. Όμως είναι πιθανό, αυτές οι επιθέσεις να έχουν διαφορετική μορφή ανάλογα με το δικτυακό στοιχείο που στοχεύουν. Μια από τις πιο γνωστές μεθόδους για τη δημιουργία προβλημάτων στη διαθεσιμότητα της παρεχόμενης υπηρεσίας είναι υπερκατανάλωση των υπολογιστικών πόρων του στόχου δημιουργώντας πολλαπλά αιτήματα στον πάροχο της VoIP υπηρεσίας. Μια άλλη πιθανή ευπάθεια είναι η δημιουργία πιθανών λαθών στους SIP εξυπηρέτες. Παράλληλα, καθώς η διαδικτυακή τηλεφωνία θεωρείται υπηρεσία, ένας επιτιθέμενος θα προσπαθήσει να ανακαλύψει ελαττώματα στην ασφάλεια σε επίπεδο εφαρμογής ή να εκμεταλλευτεί υπάρχοντα λάθη σε πρωτόκολλα με επιθέσεις παρόμοιες με αυτές που συμβαίνουν σε διαδικτυακές εφαρμογές και υπηρεσίες. 62

71 3.6.1 Επιθέσεις πλημμυρίδας στο SIP Επιθέσεις πλημμυρίδας ενάντια σε μια διαδικτυακή εφαρμογή μπορούν να συμβούν από μία ή πολλαπλές πηγές. Σε αυτού του τύπου τις επιθέσεις ο επιτιθέμενος δημιουργεί ένα μεγάλο αριθμό αιτημάτων προς τα θύματά του που συνήθως είναι διαδικτυακοί κόμβοι. Αυτός ο τύπος επίθεσης ονομάζεται RRDoS Attack. Μια τέτοια επίθεση μπορεί να χρησιμοποιηθεί έχοντας ως στόχο την παράλυση μιας SIP υποδομής. Στη συνέχεια περιγράφεται ο τρόπος με τον οποίο μια τέτοια επίθεση μπορεί να χρησιμοποιηθεί ενάντια σε SIP υποδομές Επίθεση πλημμυρίδας στον Registar Server Ένα από τα σημαντικότερα δικτυακά στοιχεία μιας SIP τηλεφωνικής υπηρεσίας είναι ο Registar εξυπηρέτης. Αν ο επιτιθέμενος καταφέρει να παραλύσει τον registar, για παράδειγμα στέλνοντας ένα μεγάλο όγκο αιτημάτων εγγραφής, μπορεί εύκολα να προκαλέσει DoS. Η κατάσταση αυτή, μπορεί να αποφευχθεί μόνο αν ο SIP εξυπηρέτης δεν δέχεται τα μηνύματα που προέρχονται από άγνωστους κόμβους. Όπως προαναφέρθηκε μια αίτηση εγγραφής μπορεί να σχετίσει μια SIP διεύθυνση ενός χρήστη με μια ή περισσότερες διευθύνσεις επικοινωνίας, έτσι ώστε ο χρήστης να αξιοποιήσει την παρεχόμενη υπηρεσία τηλεφωνίας. Συνεπώς, όταν ο επιτιθέμενος στέλνει μεγάλο όγκο register αιτημάτων προσπαθεί να: Μαντέψει τον κωδικό ενός χρήστη. Ή να προκαλέσει DoS στο συγκεκριμένο εξυπηρέτη. Μια τέτοια επίθεση μπορεί να επιτευχθεί χρησιμοποιώντας διαφορετικούς τρόπους αποστολής ενός SIP μηνύματος, κάθε φορά αλλάζοντας ελάχιστες παραμέτρους. Για παράδειγμα ένας επιτιθέμενος μπορεί να προσπαθήσει να δείξει ότι ένας κανονικός χρήστης είναι εκτός δικτύου (de-register) προκαλώντας DoS. Η μόνη διαφορά στην διαδικασία σύνδεσης (register) και αποσύνδεσης (de-register) είναι η τιμή EXPIRES (χρόνος λήξης) που περιέχεται στην κεφαλίδα του μηνύματος. Η τιμή αυτή τίθεται στο μηδέν όταν ένας πράκτορας χρήστη θέλει να τερματίσει μια σύνοδο (de-register). Με αυτό τον τρόπο ο επιτιθέμενος μπορεί να παρακάμψει τα υπάρχοντα αντίμετρα. Και στις δύο διαδικασίες ο επιτιθέμενος χρειάζεται να μαντέψει τον κωδικό του κανονικού χρήστη. Αυτός ο τύπος επίθεσης μπορεί να έχει και κατανεμημένη μορφή. Για παράδειγμα, πολλαπλοί επιτιθέμενοι μπορούν να προσπαθήσουν να μαντέψουν τον κωδικό ενός κανονικού χρήστη ή να διακόψουν την παρεχόμενη υπηρεσία στέλνοντας μεγάλο όγκο REGISTER μηνυμάτων στον registar εξυπηρέτη, καθώς η διαδικασία αυθεντικοποίησης θεωρείται υπολογιστικά ακριβή. Επίθεση πλημμυρίδας στον Proxy Server και στο τερματικό του χρήστη Ένα από τα πιο αξιοποιήσιμα μηνύματα που επεξεργάζεται από τους SIP proxy εξυπηρέτες είναι το INVITE (μήνυμα πρόσκλησης). Όπως προαναφέρθηκε, αυτό το μήνυμα χρησιμοποιείται για την εγκαθίδρυση μια σύνδεσης μεταξύ δύο ή περισσότερων συμμετεχόντων σε μια σύνοδο. Μέχρι την εγκαθίδρυση της σύνδεσης όμως, ο SIP 63

72 εξυπηρέτης πρέπει να κρατά τη δήλωση σύνδεσης, γεγονός που τον καθιστά ευάλωτο σε flooding επιθέσεις. Σύμφωνα με το RFC 3261[17], κατά την διάρκεια της προώθησης του μηνύματος από τον proxy εξυπηρέτη τίθεται χρόνος απάντησης το πολύ 3 λεπτά. Από τη στιγμή που ο χρόνος λήξει, ο χρήστης για τον οποίο προοριζόταν το μήνυμα θεωρείται μη διαθέσιμος. Επίσης, μετά την προώθηση του μηνύματος μη απάντησης (non-200 response) από τον server στον αποστολέα του μηνύματος, ο εξυπηρέτης περιμένει ένα ACK μήνυμα και ξαναστέλνει την αίτηση ανα περιόδους των 64 * 500 msec. Αν ο εξυπηρέτης έχει στείλει το αίτημα σε άλλους εξυπηρέτες, θα πρέπει να κρατά ένα αντίγραφο του αιτήματος όπως και αντίγραφα των απεσταλμένων αιτημάτων. Αν ο εξυπηρέτης δεχτεί μια αίτηση ανακατεύθυνσης του μηνύματος, θα πρέπει να ξεκινήσει ο ίδιος την διαδικασία ανακατεύθυνσης. Σε αυτή την περίπτωση θα πρέπει να διατηρήσει τη δήλωση μέχρι να δεχθεί απάντηση ότι η δοσοληψία ανακατεύθυνσης έχει ολοκληρωθεί. Ο αντίστοιχος εξυπηρέτης θα πρέπει να αναμεταδίδει περιοδικά μια απόκριση της μορφής 2xx, αφού δεν μπορεί να εγγυηθεί μια αξιόπιστη σύνδεση από όλα τα μέρη. Ο επιτιθέμενος μπορεί να διεξάγει μια τέτοια επίθεση αξιοποιώντας τα INVITE μηνύματα όχι μόνο ενάντια σε ένα proxy εξυπηρέτη αλλά και στα τερματικά των χρηστών. Για παράδειγμα, αφού οι συσκευές των χρηστών έχουν σχεδιαστεί κυρίως για να απαντούν κάτω από κανονικές συνθήκες, συνεπάγεται ότι έχουν την ικανότητα να επεξεργάζονται ταυτοχρόνως μικρό πλήθος εισερχόμενων μηνυμάτων. Έτσι αν ο επιτιθέμενος παριστάνει έναν κανονικό χρήστη μπορεί να δημιουργήσει μεγάλο όγκο INVTE μηνυμάτων χωρίς να περιμένει κάποια απάντηση προσπαθώντας να παραλύσει το θύμα του. Επιπρόσθετα, ο χρήστης χρησιμοποιεί τον proxy εξυπηρέτη για να ενισχύσει την διαδικασία αποστολής των μηνυμάτων του. Ένα άλλο πιθανό σενάριο επίθεσης συμβαίνει όταν ο επιτιθέμενος παριστάνει έναν πράκτορα χρήστη. Με αυτόν τον τρόπο μπορεί να δοκιμάσει διαφορετικά INVITE μηνύματα για να προκαλέσει DoS στον proxy ή στο τερματικό του χρήστη, προσπαθώντας να αποφύγει τους μηχανισμούς αντιμέτρων ή αναγνώρισης της ταυτότητας του Επιθέσεις στους μηχανισμούς ανάλυσης και αναγνώρισης των SIP μηνυμάτων Το SIP είναι ένα πρωτόκολλο στο οποίο, τα μηνύματα έχουν την μορφή αρχικού κειμένου με υψηλούς βαθμούς ελευθερίας, οπότε χρειάζεται ένας έξυπνος μηχανισμός ανάλυσης των μηνυμάτων. Ωστόσο, ακόμη και ένα συμβατό μήνυμα μπορεί να δημιουργηθεί με τρόπο τέτοιο, ώστε να εμποδίσει την κατάλληλη ανάλυση. Για παράδειγμα, ένας επιτιθέμενος μπορεί να δημιουργήσει πολύ μεγάλα μηνύματα, συνθέτοντας αρκετά απλούστερα π.χ. προσθέτοντας πολλαπλές κεφαλίδες και μεγάλου όγκου σώματα μηνύματος. Πολλά από τα SIP μηνύματα περιέχουν σώματα μηνύματος αν και αυτό δεν είναι πάντοτε αναγκαίο στα συγκεκριμένα μηνύματα. Εκτός από την κατανάλωση μεγάλης επεξεργαστικής ισχύος, τα μεγάλα σε όγκο μηνύματα καταναλώνουν μνήμη και άλλους διαδικτυακούς πόρους. Για να είναι μια τέτοια επίθεση 64

73 πραγματοποιήσιμη κάποιος, θα πρέπει να σχηματίσει, κατάλληλα μηνύματα που τηρούν τις προδιαγραφές του πρωτοκόλλου. Σε μερικές περιπτώσεις, οι πελάτες πρέπει να στέλνουν μηνύματα χρησιμοποιώντας ένα πρωτόκολλο ελέγχου συμφόρησης, που γενικά οδηγεί στην χρήση του TCP. Η συνθήκη αποφυγής του κατακερματισμού ισχύει αν ένα αίτημα έχει μέγεθος το πολύ 200 bytes του MTU μονοπατιού, ή αν είναι μεγαλύτερο από 1300 bytes και το μονοπάτι MTU είναι άγνωστο. Παροτρύνοντας την αποδοχή TCP συνδέσεων σε έναν εξυπηρέτη, αυτόματα τον καθιστούμε ευάλωτο σε επιθέσεις DoS στο ΤCP. Για την αποφυγή τέτοιων ενδεχόμενων οι οντότητες του SIP θα πρέπει να ρυθμίζονται, έτσι ώστε να μην υποστηρίζουν μηνύματα TCP. Επιπρόσθετα, σύμφωνα με το SIP, οι κεφαλίδες που έχουν πολλαπλές τιμές μπορούν να διαχωριστούν σε μεμονωμένες κεφαλίδες, έτσι ώστε κάθε μια να περιέχει μια μόνο τιμή. Εάν, πολλαπλές κεφαλίδες του ιδίου πεδίου εμπεριέχονται σε ένα μήνυμα, περιπλέκουν την ανάλυση του μηνύματος. Επίσης, επειδή κάποια πεδία στις κεφαλίδες είναι σημαντικότερα από κάποια άλλα, δυσκολεύουν την ανάλυση του μηνύματος, αν τα πεδία αυτά τοποθετηθούν στο τέλος. Οι επιθέσεις στους μηχανισμούς ανάλυσης των SIP μηνυμάτων μπορούν να αντιμετωπιστούν, υλοποιώντας αποτελεσματικούς μηχανισμούς ανάλυσης. Για παράδειγμα αναλύοντας μόνο τα πεδία που χρειάζονται για την κάθε διαδικασία ξεχωριστά. Γενικότερα, εξυπηρέτες που υπερφορτώνονται από μηνύματα, αποτελούν ενδείξεις ενός κακοσχεδιασμένου μηχανισμού ανάλυσης των μηνυμάτων Επιθέσεις που βασίζονται στην σηματοδότηση του SIP Ο επιτιθέμενος μπορεί να εκμεταλλευτεί διάφορα σημεία ευπάθειας που υπάρχουν στα πρωτόκολλα και στις διαδικτυακές εφαρμογές προκειμένου να αξιοποιήσει τις αδυναμίες του SIP, λόγω των ευπαθειών της ασφάλειας που υπάρχουν στο ίδιο το πρωτόκολλο. Η προδιαγραφή του SIP περιγράφει μεθόδους για τον τερματισμό μιας συνόδου, την ακύρωση μιας πρόσκλησης, της ανακατεύθυνσης μιας κλήσης και την ανανέωση μιας συνόδου. Είναι πολύ πιθανό ότι ο επιτιθέμενος θα προσπαθήσει να εκμεταλλευτεί κάθε σημείο ευπάθειας στην ασφάλεια των προαναφερόμενων μεθόδων, έτσι ώστε να προκαλέσει DoS στην υπηρεσία. Ο κυριότερος λόγος που ο κακόβουλος χρήστης θα προσπαθήσει να δημιουργήσει τέτοιες επιθέσεις χρησιμοποιώντας τα μηνύματα, είναι η απουσία κατάλληλων μηχανισμών αυθεντικοποίησης. Μέχρι στιγμής, οι προδιαγραφές του SIP δεν χρησιμοποιούν αυθεντικοποίηση για τις μεθόδους που αναφέρθηκαν παραπάνω. Πιο συγκεκριμένα, για κάθε μια από τις παραπάνω μεθόδους μπορούν να συμβούν οι αντίστοιχες επιθέσεις: BYE ATTACK: Το αίτημα BYE χρησιμοποιείται για τον τερματισμό μιας ήδη εγκαθιδρυμένης συνόδου. Ένας επιτιθέμενος μπορεί να εκμεταλλευτεί το αιτήματα BYE για να τερματίσει τη σύνοδο. Για να πραγματοποιήσει αυτή την επίθεση κάποιος θα πρέπει να γνωρίζει μερικά από τα χαρακτηριστικά της συνόδου (π.χ. Session-ID, RTP port,κλπ). Αυτό μπορεί να πραγματοποιηθεί είτε παρακολουθώντας το δίκτυο ή πραγματοποιώντας μια επίθεση MITM για να 65

74 εισάγει το μήνυμα BYE στην σύνοδο. Ωστόσο μια τέτοια επίθεση μπορεί να πραγματοποιηθεί μόνο αν απουσιάζει κάποιος μηχανισμός αυθεντικοποίησης, έτσι ώστε ο επιτιθέμενος να μην μπορεί να ανακαλύψει τις παραμέτρους της συνόδου. Αναλογιζόμενοι την εμπιστευτικότητα, η προστασία αυτών των σημαντικών παραμέτρων, θεωρείται αναγκαία. Όπως προαναφέρθηκε, μπορούμε να εκμεταλλευτούμε πρωτόκολλα όπως το IPsec ή το TLS. Επιπρόσθετα, η αυθεντικοποίηση του BYE μηνύματος θα πρέπει να διαβεβαιωθεί αξιοποιώντας είτε τον αλγόριθμο σύνοψης HTTP, είτε το TLS. CANCEL ATTACK: Όπως αναφέρει και το όνομα αυτής της επίθεσης, χρησιμοποιείται για την ακύρωσης προηγούμενων αιτημάτων που έχει στείλει ένας χρήστης. Πιο συγκεκριμένα, ενημερώνει τον server που δέχτηκε το μήνυμα να ακυρώσει την επεξεργασία του αιτήματος και να αποκριθεί με μήνυμα σφάλματος για την συγκεκριμένη αίτηση. Έτσι ένας επιτιθέμενος μπορεί να επέμβει και να ακυρώσει κάποιο INVITE μήνυμα, ενός κανονικού χρήστη. Τα αιτήματα CANCEL θα πρέπει να στέλνονται μόνο για την ακύρωση IΝVITE μηνυμάτων. Συνεπώς, όταν ένας εξυπηρέτης λάβει ένα CANCEL μήνυμα για οποιαδήποτε άλλο αίτημα, δεν θα πρέπει να επεξεργαστεί το μήνυμα, αλλά να αποκριθεί με μήνυμα σφάλματος. Επιπρόσθετα, αν το αρχικό μήνυμα έχει λάβει μια τελική απόκριση, πάλι τα CANCEL αιτήματα δεν θα πρέπει να τυγχάνουν επεξεργασίας. Θα πρέπει να σημειωθεί ότι, τα CANCEL αιτήματα δημιουργούνται ανά hop και δεν μπορούν να ξαναυποβληθούν. Παράλληλα, μηνύματα CANCEL που καταφθάνουν από διαφορετικά domains αποτελούν ένα ανοικτό πρόβλημα. Re-INVITE ATTACK: Από τη στιγμή που έχει ξεκινήσει ένας διάλογος μέσω μηνυμάτων, μπορούν να σταλούν αιτήματα για να αλλάξουν τις παραμέτρους της συνόδου (π.χ. αλλαγή της πόρτας των εισερχόμενων μηνυμάτων). Άρα κάθε μη εξουσιοδοτημένη αλλαγή που δεν ακολουθείται από νέο INVITE αίτημα μπορεί να προκαλέσει DoS. UPDATE ATTACK: Η μέθοδος UPDATE παρέχει στους συμμετέχοντες δυνατότητες όπως, τοποθέτηση της κλήσης σε αναμονή, αναγνώριση των ιδιοτήτων της κλήσης και διαπραγμάτευση νέων συνόδων, όπως με το Re- INVITE μήνυμα. Η μόνη διαφορά είναι ότι το Re-INVITE μήνυμα χρησιμοποιείται σε ήδη εγκαθιδρυμένες συνόδους, ενώ το UPDATE χρησιμοποιείται για να αλλάξει τις παραμέτρους μιας συνόδου πριν αυτή εγκαθιδρυθεί. Παρόμοια με την προηγούμενη περίπτωση ένας επιτιθέμενος μπορεί να προκαλέσει DoS αλλάζοντας τις παραμέτρους της συνόδου. INFO ATTACK: Σε πολλές περιπτώσεις τα SIP δίκτυα μπορούν να χρησιμοποιηθούν σαν μεσολαβητές για την διασύνδεση PSTN δικτύων. Σε μια τέτοια περίπτωση, χρησιμοποιούνται τα τηλέφωνα του SIP, για την μεταβίβαση του σήματος του PSTN δικτύου από την μια μεριά στην άλλη και το αντίστροφο. Η μέθοδος αυτή προτείνεται και χρησιμοποιείται για πολλές λειτουργίες μερικές από τις οποίες παρουσιάζονται στην συνέχεια: 1. Να διατηρεί τα ενδοδικτυακά μηνύματα σήματος του PSTN μεταξύ των πυλών του PSTN. 2. Να διατηρεί τα DTMF (Dual tone multi frequency) ψηφία που δημιουργούνται κατά την διάρκεια μιας SIP συνόδου. 3. Να διατηρεί πληροφορίες για τους λογαριασμούς του χρήστη. 66

75 Το σώμα μηνύματος ενός INFO μηνύματος μπορεί να κρυπτογραφηθεί για λόγους ιδιωτικότητας. Ωστόσο, δεν υπάρχει πρόταση μηχανισμού ασφάλειας που να παρέχει ακεραιότητα και αυθεντικότητα σε αυτή τη μέθοδο. Άρα συνεπάγεται, ότι μια κακόβουλη αλλαγή αυτού του μηνύματος μπορεί να προκαλέσει σημαντικά προβλήματα για τους χρήστες που επικοινωνούν μεταξύ τους, όπως μη εξουσιοδοτημένη πρόσβαση σε μια κλήση, DoS για το μήνυμα INVITE, λάθη στον λογαριασμό χρέωσης του χρήστη και άλλα. 67

76 ΚΕΦΑΛΑΙΟ 4 - ΤΟ ΟΝΤΟΛΟΓΙΚΟ ΜΟΝΤΕΛΟ 4.1 Εισαγωγή στο Οντολογιακό Μοντέλο Περιγραφής του SIP Στο προηγούμενο κεφάλαιο παρουσιάστηκε μέσω της προδιαγραφής του SIP η αρχιτεκτονική του και εξετάσαμε διάφορους μηχανισμούς ασφάλειας που μπορούν να χρησιμοποιηθούν για να παρέχουν στο SIP εμπιστευτικότητα ακεραιότητα και ιδιωτικότητα. Ωστόσο, όπως προαναφέρθηκε η χρήση αυτών των μηχανισμών είναι αρκετά δύσκολη και δεν μπορούν να εξασφαλίσουν έναν από τους πιο σημαντικούς παράγοντες που οι πάροχοι VoIP υπηρεσιών πρέπει να διασφαλίζουν, την ακεραιότητα. Πέρα από τις αποτυχίες των δικτύων, είναι ευρέως αποδεκτό ότι η διαθεσιμότητα του VoIP δεν επηρεάζεται μόνο από ελαττώματα ασφάλειας που επέρχονται από την διαδικτυακή αρχιτεκτονική, αλλά και από νέες εξεζητημένες επιθέσεις ή από τα σημεία ευπάθειας που υπάρχουν στα VoIP πρωτόκολλα, κυρίως κατά την διάρκεια εγκαθίδρυση μιας συνόδου. Συνεπώς, οι πάροχοι VoIP υπηρεσιών θα πρέπει να λάβουν υπόψιν τις διάφορες απόψεις για τα θέματα ασφαλείας σε διαφορετικές διαδικτυακές αρχιτεκτονικές έτσι ώστε να παρέχουν ασφάλεια, εμπιστοσύνη και σταθερές υπηρεσίες. Μέχρι στιγμής, οι περισσότερες έρευνες, επικεντρώνονται σε γενικές προτάσεις και οδηγίες για την παροχή ασφάλειας σε μια VoIP υποδομή. Καμία όμως από τις έρευνες αυτές (από όσο γνωρίζουμε τουλάχιστον) δεν στοχεύει στην παροχή οδηγιών και συγκεκριμένων πολιτικών για την αντιμετώπιση των ελαττωμάτων της ασφάλειας στο VoIP. Παράλληλα, η απουσία ενός κοινού πλαισίου δεν δίνει τη δυνατότητα στους πάροχους να συνεργάζονται αποτελεσματικά και να εντοπίσουν την ύπαρξη κάποιας επίθεσης έτσι ώστε να την αποκρούσουν. Στη συνέχεια του κεφαλαίου αυτού θα παρουσιαστεί και θα αναλυθεί ένας οντολογιακός φορμαλισμός, που παρέχει οδηγίες και τρόπους που θα πρέπει να ακολουθούνται σε ολόκληρη τη διάρκεια ανάπτυξης μιας VoIP υπηρεσίας, έτσι ώστε, να βελτιωθεί η αξιοπιστία της ασφάλειας. Αν και επικεντρωνόμαστε μόνο στο πρωτόκολλο SIP, αξίζει να σημειωθεί ότι μόνο ελάχιστες αλλαγές θα πρέπει να γίνουν για τα υπόλοιπα πρωτόκολλα σηματοδοσίας. Επιπρόσθετα, οι πάροχοι VoIP υπηρεσιών μπορούν να αξιοποιήσουν την οντολογία όχι μόνο για την περιγραφή μιας αμυντικής πολιτικής αλλά και για την αξιολόγηση της ασφάλειας στην υποδομή τους. Για τη δημιουργία της οντολογίας που προαναφέρθηκε, αξιοποιήθηκαν οι δυνατότητες και η εκφραστικότητα της OWL που περιγράφτηκε αναλυτικά στο πρώτο κεφάλαιο. Επίσης, στη συνέχεια με την βοήθεια της SWRL (και της SQWRL) αναπτύχθηκαν κανόνες, που 68

77 ενδυναμώνουν το οντολογικό μοντέλο και το καθιστούν ικανό να αντιμετωπίζει ή να κατατάσσει πιθανές επιθέσεις, που δεν μπορούν να αντιμετωπιστούν από τους μηχανισμούς ασφαλείας που αναφέρθηκαν στο προηγούμενο κεφάλαιο. 4.2 Επισκόπηση Οντολογικού Μοντέλου περιγραφής του SIP για την ασφάλεια VoIP υποδομών Μέχρι στιγμής, υπάρχουν διάφορα Intrusion Detection Systems (IDS) και γλώσσες που περιγράφουν κυρίως ελαττώματα ασφάλειας για συγκεκριμένα συστήματα, γεγονός που καθιστά σχεδόν κάθε δίκτυο διαφορετικό από τα υπόλοιπα. Η ετερογονία λοιπόν, των δίκτύων δεν διευκολύνει την δημιουργία μιας συγκεκριμένης πολιτικής ασφάλειας και τη δημιουργία κανόνων που θα λειτουργούν σε κάθε VoIP δίκτυο. Συνεπώς, η δημιουργία μιας ομοιόμορφης και συμβατής περιγραφής οδηγιών ασφάλειας είναι αναγκαία. Ένα οντολογιακό μοντέλο μπορεί να προσφέρει αυτή την ομοιομορφία και παρέχει τη δυνατότητα διαμοιρασμού των ίδιων σημασιολογικών, από διαφορετικά domains. Στη συνέχεια περιγράφεται και αξιοποιείται μια οντολογία η οποία καθιστά εφικτή την επαναχρησιμοποίηση του ιδίου μοντέλου στο ίδιο αλλά και σε διαφορετικά δίκτυα παρόχων υπηρεσιών. Επιπρόσθετα, η ίδια περιγραφή μπορεί να χρησιμοποιηθεί από διάφορες εφαρμογές, έτσι ώστε να προσφέρει: Κανόνες ασφάλειας ως κανονική υπηρεσία. Ελέγχους ασφάλειας για τα εμπλεκόμενα συστήματα. Ένα εργαλείο αναγνώρισης ελαττωμάτων ασφάλειας για τον έλεγχο των VoIP αρχείων ημερολογίου. Η οντολογία αποτελείται από δυο επιμέρους οντολογίες. Η πρώτη ονομάζεται SIP-Message και η δεύτερη SIP-Attack. Για την κατασκευή της οντολογίας του SIP-Message ακολουθήσαμε την προδιαγραφή του SIP[17] για τον τρόπο κατασκευής των μηνυμάτων (βλ. Κεφάλαιο 3). Πιο συγκεκριμένα, η κλάση SIP-Message αποτελείται από τις ακόλουθες υποκλάσεις : First_Line: Η κλάση αυτή παρουσιάζει την πρώτη γραμμή του μηνύματος SIP. Τα μηνύματα στο SIP κατηγοριοποιούνται σε δύο κατηγορίες τα αιτήματα (Request) και αποκρίσεις (Response). Άρα, αντίστοιχα η κλάση First_Line αποτελείται από δυο υποκλάσεις από τις οποίες λαμβάνει τιμές: 69

78 1. Request: Χρησιμοποιείται για την αναπαράσταση των αιτημάτων που μπορεί να κάνει ένας χρήστης. Έχει την ιδιότητα method_type που μπορεί να πάρει τιμές INVITE, REQUEST, ACK, BYE, CANCEL, OPTIONS και SUBSCRIBE, την ιδιότητα Version για την εισαγωγή της έκδοσης του SIP που χρησιμοποιείται (συνήθως έχει την τιμή SIP/2.0) και την ιδιότητα Request_SIP-URI για την εισαγωγή του URI του αποστολέα. Όλες αυτές οι ιδιότητες είναι τύπου δεδομένων (Datatype). 2. Response: Χρησιμοποιείται για την αναπαράσταση των αποκρίσεων των χρηστών. Αντίστοιχα, έχει την ιδιότητα Version και την ιδιότητα response_type που παίρνει τιμές της μορφής 1xx, 2xx κλπ. Οι ιδιότητες αυτές είναι τύπου δεδομένων (Datatype). Η κλάση First_Line έχει τις ιδιότητες αντικειμένων (Object Property) includes για να δείχνουν ότι περιέχει τιμές από τις 2 υποκλάσεις της και την ιδιότητα is_included_in που υπαγορεύει ότι αποτελεί τμήμα ενός SIP μηνύματος. Επίσης η κλάση έχει τον περιορισμό owl:oneof που υποδηλώνει ότι η κλάση μπορεί να πάρει κάθε φορά τιμές μόνο από μια από τις υποκλάσεις της. Δηλαδή, κάθε First_Line είναι είτε Request, είτε Response. Header: Η κλάση αυτή αποτελεί την κεφαλίδα ενός SIP μηνύματος. Έχει τις ιδιότητες δεδομένων Content-Lentgh, Content-Type και Max-Forwards που αποτελούν τα αντίστοιχα πεδία μιας SIP κεφαλίδας όπως αυτά παρουσιάζονται στην προδιαγραφή του SIP[17]. Τα υπόλοιπα υποχρεωτικά πεδία που χρειάζονται για την δημιουργία μιας SIP κεφαλίδας αποτελούνται από τις παρακάτω κλάσεις : Via: Αναπαριστά το αντίστοιχο πεδίο της κεφαλίδας και έχει τις ιδιότητες δεδομένων, Via-IP για την εισαγωγή της IP ή του SIP-Uri που ο χρήστης περιμένει να λάβει τις απαντήσεις στα μηνύματά του και Branch-ID για την αναγνώριση της δοσοληψίας. To: Αναπαριστά το αντίστοιχο πεδίο της κεφαλίδας και έχει την ιδιότητα δεδομένων,username για την εισαγωγή του username του παραλήπτη του μηνύματος η οποία παίρνει τιμές από την κλάση SIP-URI που θα περιγραφεί στην συνέχεια. From: Αναπαριστά το πεδίο με τα στοιχεία του αποστολέα του μηνύματος. Έχει τις ιδιότητες UserName για την εισαγωγή του username του αποστολέα η οποία παίρνει τιμές από την κλάση SIP-Uri. Τέλος την ιδιότητα From-tag για την εισαγωγή του τυχαίου αλφαριθμητικού που παράγεται από το τηλέφωνο του χρήστη. 70

79 CSeq: Αναπαριστά του πεδίο CSeq της κεφαλίδας του SIP μηνύματος. Έχει τις ιδιότητες δεδομένων Method-type που παίρνει τις τιμές που αναφέρθηκαν στην αντίστοιχη ιδιότητα της κλάσης Request. Επίσης, την ιδιότητα CSeq_number για τον ακέραιο αριθμό που περιέχεται σε αυτό το πεδίο. Call-ID: Χρησιμοποιείται για την αναπαράσταση του αντίστοιχου πεδίου της κεφαλίδας. Έχει την ιδιότητα Call-ID-identifier για την εισαγωγή ενός τυχαίου αλφαριθμητικού και το όνομα του εξυπηρέτη ή την IP διεύθυνση του λογισμικού τηλεφώνου. Εκτός από τις ιδιότητες δεδομένων που έχει η κλάση Header έχει και τις Object Properties has_call-id, has_from, has_to, has_cseq, has_via, με τις οποίες δείχνουμε ότι κάθε κεφαλίδα αποτελείται από ένα από αυτά τα πεδία. Οπότε οι ιδιότητες αυτές και οι ιδιότητες δεδομένων δημιουργούν μια ολοκληρωμένη κεφαλίδα. Authenticate: Η κλάση αυτή δείχνει αν το SIP μήνυμα χρειάζεται αυθεντικοποίηση ή όχι. Συνεπώς αποτελείται από μια ιδιότητα δεδομένων needs_authentication που εκφράζει την χρήση αυθεντικοποίησης. Επίσης έχει την ιδιότητα αντικειμένου authentication_is_needed_for που συσχετίζει αντικείμενα αυτής της κλάσης με τα SIP μηνύματα. Event: Η κλάση αυτή εκφράζει το περιστατικό που δημιουργεί το SIP μήνυμα και έχει υποκλάση την: 1. State: Που εκφράζει την εντολή που πυροδοτείται. Επίσης κάθε SIP μήνυμα συσχετίζεται με την κλάση Time που δείχνει την στιγμή που στάλθηκε το κάθε μήνυμα. Η κλάση αυτή, θα έπρεπε να ήταν υποκλάση της SIP-Message αλλά προκειμένου να μπορούμε να χρησιμοποιήσουμε τις λειτουργίες της OWL που προσφέρονται για κλάσεις χρόνου την έχουμε ορίσει ως υποκλάση της κλάσης temporal:validinstance. Η διαδρομή που ακολουθείται για να φτάσουμε στην κλάση Time είναι η owl:root temporal:entity temporal:validtime temporal:validinstance Time, τις οποίες μπορούμε να βρούμε χρησιμοποιώντας το namespace με το prefix temporal, που δηλώνει ότι η οντολογία μας κληρονομεί τις ιδιότητες της κλάσης temporal. Η κλάση SIP-Attack εκφράζει τις επιθέσεις που μπορούν γίνουν σε ένα VoIP δίκτυο. Η κλάση αυτή αποτελείται από τις εξής υποκλάσεις: 71

80 Target: Η κλάση αυτή δείχνει το στόχο της επίθεση. Δηλαδή, αν στοχεύει σε έναν χρήστη, σε έναν Registat εξυπηρέτη, ή έναν proxy εξυπηρέτη. Consequence: Η κλάση αυτή χρησιμοποιείται για την περιγραφή των επιπτώσεων που μπορεί να επιφέρει μια επίθεση στο SIP και την υποδομή του. Mallformed: Η κλάση αυτή χρησιμοποιείται για τις επιθέσεις που χρησιμοποιούν μηνύματα που δεν συμμορφώνονται με την προδιαγραφή των μηνυμάτων του πρωτοκόλλου και με την γραμματική των μηνυμάτων έτσι ώστε να προκαλέσουν αστάθεια στην παρεχόμενη υπηρεσία. Η κλάση αυτή δεν χρειάζεται κάποιες συγκεκριμένες ιδιότητες, αναλογιζόμενοι ότι κάθε μήνυμα που δεν ικανοποιεί τις ελάχιστες απαιτήσεις πεδίων που χρειάζονται στο SIP είναι αυτόματα μέλος αυτής της κλάσης. Signaling: Η κλάση signaling χρησιμοποιείται για κακόβουλα μηνύματα που προσπαθούν να τερματίσουν μια σύνοδο χωρίς την συγκατάθεση των χρηστών. Οπότε κάθε μήνυμα της μορφής BYE ATTACK που δεν μπορεί να αυθεντικοποιηθεί θεωρείται κακόβουλο και απορρίπτεται. Flood: Όπως και το όνομα της εκφράζει, η κλάση αυτή τυποποιεί τις συγκεκριμένες επιθέσεις. Μάλιστα, όπως προαναφέρθηκε οι επιθέσεις αυτές υποκατηγοριοποιούνται σε επιθέσεις από πολλαπλές πηγές και επιθέσεις από μια πηγή οπότε υποκλάσεις της κλάσης Flood είναι οι εξής : 1. Single-Source: Μονή πηγή επίθεσης. o Ref-Syndrome o Syn-Syndrome 2. Multi-Source: Πολλαπλές πηγές επιθέσεων. o New-Req o Same-Req 72

81 Το μοντέλο παρουσιάζεται σχηματικά στην εικόνα 5: Εικόνα [5] Το οντολογικό μοντέλο περιγραφής Ασφαλών VoIP υποδομών 73

82 Στον πίνακα [3] παρουσιάζονται αναλυτικά οι ιδιότητες των κλάσεων και σε παρένθεση οι επιτρεπόμενες τιμές που μπορεί να πάρει η κάθε ιδιότητα. Οι ιδιότητες SubClassOf() που παρουσιάζονται στην εικόνα[5] σχήμα με μπλε γραμμή παραλείπονται. Owl:Class Object Property DataType Property sented(time) has_header(header) includes(first_line) SIP-message creates(event) needs_authentication(authentication) is_used_for(sip-attack) Header Call-ID CSeq belongs_to(sip-message) has_via(via) has_from(from) has_to(to) has_call-id(call-id) has_cseq(cseq) Content-Type(string) Max-Forwards(int) Content-Length(int) Call-ID-Identifier(string) Cseq_number(int) From from_sip-uri(sip_uri) To to_sip-uri(sip-uri) Via From_tag(int) UserName(string) UserName(string) Branch-Id(int) Via-IP(string) First_Line Request Response Event State Authenticate is_included_in(sip-message) one_of(request,response) owl:cardinality Is_Created(SIP-Message) Triggers(State) Is_Triggered(Event) Authentication_is_needed_for(SIPmessage) 74 Version(string) Method_type(REGISTER, INVITE, SUBSCRIBE, BYE, ACK, CANCEL, OPTIONS) Version(string) Response-type(string)

83 SIP-URI Sip-uri-domain(string) Sip-uri-name(string) SIP-Attack Consequence Target Time Launched(Time) Uses(SIP-message) Directs(Target) Causes(Consequence) Is_caused_by(SIP-Attack) Is_directed_from(SIP-Attack) Launched_on(SIP-Attack) Sented_on(SIP-message) Πίνακας [3] Ιδιότητες των κλάσεων του μοντελου, σε παρενθεση φαίνονται οι αντίσοιτχες τιμές που μπορεί να λάβει κάθε μια 75

84 4.3 Κατασκευή της Οντολογίας Για την κατασκευή της οντολογίας υπάρχουν δυο πιθανοί τρόποι οι οποίοι αναλύονται στα επόμενα: 1) The Protégé Ontology Editor and Knowledge Acquisition System: Το Protégé[26] είναι μια δωρεάν πλατφόρμα ανοιχτού κώδικα που προσφέρει σε μια διαρκώς αυξανόμενη κοινότητα χρηστών μια σουίτα εργαλείων για την κατασκευή μοντέλων και εφαρμογών που βασίζονται στη γνώση μέσω οντολογιών. Στον πυρήνα του Protégé εφαρμόζεται ένα πλούσιο σύνολο δομών και ενεργειών διαμόρφωσης της γνώσης που υποστηρίζουν τη δημιουργία, την απεικόνισή και τον χειρισμό των οντολογιών με κατάλληλα σχήματα. Το Protégé υποστηρίζει μηχανισμούς για την δημιουργία μοντέλων γνώσης και την εισαγωγή δεδομένων σε αυτά. Επιπρόσθετα το Protégé μπορεί να επεκταθεί μέσω plug-in αρχιτεκτονικής και μέσω Java διεπαφών για την δημιουργία εργαλείων και εφαρμογών που βασιζόμενων στη γνώση. Μέσω του Protégé, ένας χρήστης χωρίς ιδιαίτερες γνώσεις υπολογιστών είναι ικανός να δημιουργήσει το δικό του οντολογιακό μοντέλο, καθώς παρέχει ένα αρκετά φιλικό περιβάλλον και αρκετά παραδείγματα χρήσης για την κατανόηση του τρόπου λειτουργίας του και για πειραματισμό. Επίσης, η πληθώρα των εργαλείων που παρέχεται βοηθά στην οπτική απεικόνιση, και ευκολότερη κατανόηση των λαθών. Επιπρόσθετα, προσφέρεται η δυνατότητα εισαγωγής κανόνων και ερωτημάτων γλωσσών όπως η SWRL[27] και η SPARQL[28]. Τέλος, υποστηρίζεται η εξαγωγή ενός μοντέλου από την OWL στην RDF και σε XML Schema. Για τη δημιουργία του μοντέλου οντολογίας του SIP, επιλέχτηκε το Protégé, γεγονός που βοήθησε στην κατανόηση ελλείψεων που είχαμε αρχικά καθώς και στην εισαγωγή κατάλληλων συσχετίσεων και κανόνων ώστε να επιτύχουμε την διαδραστικότητα του μοντέλου που επιθυμούσαμε. Στο παράρτημα 2 παρουσιάζεται μέρος του αρχείου SIP-Ontology.owl που περιέχει μόνο την περιγραφή της δομής της οντολογίας που χρησιμοποιήθηκε. Ολόκληρο το αρχείο βρίσκεται στον ψηφιακό δίσκο που εμπερικλείεται στην εργασία. 76

85 2) Κατασκευή μοντέλου μέσω Java Όπως προαναφέρθηκε το Protégé είναι ένα εργαλείο ανοικτού κώδικα και βασίζεται στην Java. Μέσω των βιβλιοθηκών που παρέχονται από το ίδιο το πρόγραμμα υπάρχει η δυνατότητα κατασκευής ενός μοντέλου μέσω Java. Για να χρησιμοποιήσει κανείς τις συναρτήσεις και τους μηχανισμούς λειτουργίας του Protégé θα πρέπει να εισάγει στο CLASSPATH του υπολογιστή του όλες τις βιβλιοθήκες που βρίσκονται στον φάκελο plugins\edu.stanford.smi.protegex.owl που δημιουργείται με την εγκατάσταση του προγράμματος. Επίσης θα πρέπει να προστεθούν στο CLASSPATH οι βιβλιοθήκες lax.jar, looks jar, Unicode-panel.jar και protégé.jar που βρίσκονται στον αρχικό φάκελο εγκατάστασης. Για περισσότερες πληροφορίες, σχετικά με την χρήση των κατάλληλων συναρτήσεων, έτσι ώστε να κατασκευαστεί μια οντολογία μέσω της Java συνιστούμε στον αναγνώστη να διαβάσει το Protégé Developers Guide[29]. Επίσης για τη διευκόλυνση του αναγνώστη ένα επιπλέον παράδειγμα απλού οντολογικού μοντέλου παρέχεται στο παράρτημα Εισαγωγή Δεδομένων Για την εισαγωγή των δεδομένων υπάρχουν όπως ήδη αναφέρθηκε, δύο τρόποι. Δηλαδή, χρησιμοποιώντας μέσω Java τις κατάλληλες συναρτήσεις που προσφέρονται από τις βιβλιοθήκες του Protégé, ή αξιοποιώντας την επιφάνεια εργασίας του προγράμματος. Επίσης, υπάρχει και η δυνατότητα εισαγωγής πολλαπλών δεδομένων από αρχείο, μέσω κατάλληλων μηχανισμών που προσφέρονται στο Protégé. Για την εισαγωγή των δεδομένων του μοντέλου μας επιλέξαμε να εργαστούμε από το πρόγραμμα καθώς οι πολλές συσχετίσεις δυσκόλεψαν την εισαγωγή του μέσω της Java. Για την ακρίβεια προκειμένου να ελέγξουμε την λειτουργικότητα του μοντέλου μας εισαγάγαμε 10 μηνύματα μερικά από τα οποία ήταν συμβατά με το SIP και τα υπόλοιπα παραμετροποιήθηκαν έτσι ώστε να φαίνεται ότι τα δημιούργησε ένας κακόβουλος χρήστης Εισαγωγή κανόνων Προκειμένου να ελέγξουμε την λειτουργικότητα του μοντέλου μας και την διαδραστικότητα του στα SIP μηνύματα, θα πρέπει να δημιουργηθούν κανόνες ελέγχου των μηνυμάτων ή αντίστοιχα κατηγοριοποίησης. Για τη δημιουργία των κανόνων χρησιμοποιήθηκε η γλώσσα SWRL[13] (βλ. Κεφάλαιο 2), επίσης αξιοποιήθηκαν κάποιες από τις ιδιότητες των κλάσεων και οι συσχετίσεις μεταξύ τους. Τέλος χρησιμοποιήθηκαν κάποιοι από τους ενσωματωμένους κανόνες της SWRL και της SQWRL για την εξαγωγή των αποτελεσμάτων. Οι κανόνες που χρησιμοποιήθηκαν περιγράφονται αναλυτικότερα στη συνέχεια. 77

86 Κανόνας 1 ος Στον πρώτο κανόνα θέλουμε να ελέγξουμε τα μηνύματα που είναι μη συμβατά με την προδιαγραφή του SIP. Πιο συγκεκριμένα, θεωρούμε ότι ένα επιτρεπτό μήνυμα στο SIP έχει τιμή στο πεδίου Content-Length, δηλαδή μικρότερη ή ίση με 140 bytes. Αναλυτικότερα, το μέγεθος του σώματος του μηνύματος έχει μέγεθος μικρότερο των 141 bytes, οπότε κάθε μήνυμα με σώμα μηνύματος μεγαλυτέρου μεγέθους από 140 bytes θεωρείται ότι αποσκοπεί να βλάψει την υπηρεσία VoIP καταναλώνοντας επεξεργαστική ισχύ και μνήμη στον proxy εξυπηρέτη. Ο κανόνας εκφράζεται στην SWRL ως εξής : SIP-message(?x) ^ has_header(?x,?o) ^ Content-length(?o,?k) ^ swrlb:greaterthan(?k, 140) sqwrl:select(?x) Ο προηγούμενος κανόνας εκφράζει ότι επιλέγουμε κάθε SIP μήνυμα x, που έχει κεφαλίδα o (has_header), η οποία με τη σειρά της έχει Content-Length k, το οποίο έχει τιμή στο πεδίο αυτό μεγαλύτερη του 140. Δεδομένου ότι τα μηνύματα μας δεν είναι real time, επιλέχθηκε η επιλογή των μηνυμάτων έτσι ώστε να έχουμε αποτελέσματα στην οθόνη. Αν θέλαμε να κατηγοριοποιήσουμε τα μηνύματα αυτά ως μη συμβατά (Malformed) σε ένα real time περιβάλλον θα έπρεπε να αλλάξουμε την κεφαλίδα του κανόνα ως εξής: SIP-message(?x) ^ has_header(?x,?o) ^ Content-length(?o,?k) ^ swrlb:greaterthan(?k, 140) malformed(?x) Αντίστοιχα, αν κάποια υποδομή VoIP επιτρέπει μηνύματα με σώμα μεγαλύτερου μεγέθους η μικρότερου δεν έχουμε παρά να αλλάξουμε το μέγεθος στην ιδιότητα του κανόνα swrlb:greaterthan(?k, επιτρεπτό μήνυμα μεγέθους), έτσι ώστε να επιλέγουμε τα μη συμβατά μηνύματα σύμφωνα με την υφιστάμενη υποδομή. Οι ενσωματωμένοι κανόνες που επιλέχθηκαν είναι οι swrlb:greaterthan(,) και sqwrl:select(). Κανόνας 2 ος Αναλογιζόμενοι ότι ένας κανονικός χρήστης, έχει την ικανότητα να αποστείλει μεμονωμένα μηνύματα τα οποία με τη σειρά τους έχουν μοναδική ώρα αποστολής δημιουργήσαμε τον δεύτερο κανόνα. Αναλυτικότερα, ένας κανονικός χρήστης που χρησιμοποιεί λογισμικό τηλέφωνο για τις κλήσεις του μέσω του SIP δεν έχει τη δυνατότητα να στείλει μηνύματα την ίδια χρονική στιγμή. 78

87 Όποτε, αν κάποιος χρήστης υπερβεί αυτόν τον περιορισμό θεωρείται κακόβουλος και προσπαθεί να επιφέρει στο δίκτυο DoS με flood επιθέσεις ή spam κλήσεις, στοχεύοντας στους εξυπηρέτες και στους χρήστες αντίστοιχα. Ο κανόνας εκφράζεται βάση του μοντέλου μας στην SWRL ως εξής: SIP-message(?x) ^ SIP-message(?y) ^ differentfrom(?x,?y) ^ has_header(?x,?h1) ^ has_from(?h1,?f1) ^ from_sip-uri(?f1,?uri1) ^ Sip-uri-name(?uri1,?name1) ^ has_header(?y,?h2) ^ has_from(?h2,?f2) ^ from_sip-uri(?f2,?uri2) ^ Sip-uriname(?uri2,?name2) ^ sented(?x,?time1) ^ sented(?y,?time2) ^ hasvalidtime(?time1,?valid1) ^ hasvalidtime(?time2,?valid2) ^ swrlb:matches(?valid1,?valid2) ^ swrlb:matches(?name1,?name2) sqwrl:select(?x,?valid1,?name1,?y,?valid2,?name2) Πριν επεξηγηθεί ο κανόνας αναλυτικότερα, θυμίζουμε ότι η OWL ενστερνίζεται αντίληψη ανοιχτού κόσμου (βλ. Κεφαλαιο 1) και δεν υποστηρίζεται η αντίληψη μοναδικών ονομάτων. Βάση αυτών των δύο κάθε αντικείμενο περίπτωση στην OWL θεωρείται όμοιο με κάθε άλλο αντικείμενο προσωπικότητα της ιδίας κλάσης ανεξάρτητα από το αν έχουν διαφορετικά ονόματα. Για παράδειγμα, δύο SIP μηνύματα μπορεί να έχουν διαφορετικά περιεχόμενα και διαφορετικό όνομα, δεν παύουν όμως να έχουν την μορφή ενός SIP μηνύματος, δεν μπορούμε να αποφανθούμε ότι είναι διαφορετικά, χωρίς να ελέγξουμε τα δεδομένα τους. Για τον λόγο αυτό, πριν χρησιμοποιήσουμε τον παραπάνω κανόνα, θέτουμε στην OWL ότι τα αντικείμενα των κλάσεων που θα χρησιμοποιηθούν είναι διαφορετικά μεταξύ τους. Για να το επιτύχουμε αυτό χρησιμοποιούμε την ιδιότητα owl:alldifferents, στις κλάσεις που εμπεριέχονται στον κανόνα. Έτσι, ζητάμε δυο διαφορετικά SIP μηνύματα το μήνυμα x και το μήνυμα y. Η διαφορετικότητα των μηνυμάτων επιτυγχάνεται χρησιμοποιώντας τον ενσωματωμένο κανόνα differentfrom(,). Στη συνέχεια από κάθε SIP μήνυμα οδηγούμαστε μέσω της κεφαλίδας του (has_header) στο πεδίο from και από το πεδίο from διαλέγουμε το SIP-URI του αποστολέα του μηνύματος. Επίσης, ζητάμε για κάθε μήνυμα τον χρόνο αποστολής του. Αν τώρα, βρεθεί κάποιος συνδυασμός μηνυμάτων που στάλθηκαν από το ίδιο SIP-URI, την ίδια χρονική στιγμή τότε επιλέγουμε αυτά τα μηνύματα, τον χρόνο αποστολής τους και το όνομα από την διεύθυνση URI του αποστολέα. Δεδομένου ότι, ζητάμε συνδυασμούς μηνυμάτων είναι σίγουρο το ενδεχόμενο, ότι θα έχουμε διπλο-εγγραφή στα αποτελέσματα του κανόνα αν αυτά υπάρχουν. Στον κανόνα γίνεται χρήση των ενσωματωμένων κανόνων hasvalidtime, ιδιότητα που κληρονομεί η κλάση Time και του swrlb:matches(,) που ελέγχει αν οι δύο τιμές ταιριάζουν μεταξύ τους. 79

88 Αν θέλαμε να τρέξουμε τον κανόνα σε ένα real time περιβάλλον και να κατηγοριοποιούνται αυτά τα μηνύματα αυτόματα ως επιθέσεις flood, τότε θα πρέπει απλά να αλλάξουμε την κεφαλίδα του μηνύματος από sqwrl:select(), σε flood(). Επιπλέον, ο κανόνας μπορεί να επεκταθεί για συνδυασμούς τριών, τεσσάρων ή και παραπάνω μηνυμάτων. Κανόνας 3 ος Στον 3 ο κανόνα θέλαμε να δημιουργήσουμε ένα χρονικό κατώφλι για την αποστολή των SIP μηνυμάτων. Έτσι ο κανόνας εμφανίζει ως αποτέλεσμα τα μηνύματα που έχουν σταλεί από τον ίδιο χρήστη σε διάρκεια 10 δευτερολέπτων μεταξύ τους, γεγονός που φαντάζει σαν επίθεση flood σε μια υποδομή VoIP. Και σε αυτόν τον κανόνα ζητάμε συνδυασμούς μηνυμάτων, οπότε είναι αναγκαία η χρήση του ενσωματωμένου κανόνα differentfrom και ισχύει για τα αντικείμενα ότι είναι διαφορετικά μεταξύ τους. Ο κανόνας στην SWRL είναι ο εξής : SIP-message(?x) ^ SIP-message(?y) ^ differentfrom(?x,?y) ^ has_header(?x,?h1) ^ has_from(?h1,?f1) ^ from_sip-uri(?f1,?uri1) ^ Sip-uri-name(?uri1,?name1) ^ has_header(?y,?h2) ^ has_from(?h2,?f2) ^ from_sip-uri(?f2,?uri2) ^ Sip-uriname(?uri2,?name2) ^ sented(?x,?time1) ^ sented(?y,?time2) ^ hasvalidtime(?time1,?valid1) ^ hasvalidtime(?time2,?valid2) ^ swrlb:matches(?name1,?name2) ^ temporal:duration(10,?valid1,?valid2, temporal:seconds) sqwrl:select(?x,?valid1,?name1,?y,?valid2,?name2) Αρχικά, ζητάμε από τον κανόνα δύο διαφορετικά SIP μηνύματα και τον αποστολέα από την κλάση from της κεφαλίδας του μηνύματος. Στη συνέχεια, παίρνουμε τον χρόνο αποστολής του μηνύματος. Τέλος, αν τα ονόματα αποστολής ταιριάζουν και ο χρόνος αποστολής των μηνυμάτων είναι ανά 10 δευτερόλεπτα τότε επιλέγουμε το μήνυμα, τον χρόνο αποστολής και το όνομα του αποστολέα. Επειδή πάλι, αναζητούμε συνδυασμούς αποτελεσμάτων θα έχουμε διπλο-εγγραφές στα αποτελέσματα. Για τον κανόνα αυτό, χρησιμοποιούνται οι ενσωματωμένοι κανόνες swrlb:matches(,) για το έλεγχο των ονομάτων που ταιριάζουν μεταξύ τους. Ο κανόνας sqwrl:select() για την επιλογή των αποτελεσμάτων και ο κανόνας temporal:duration( period,instance1,instance2, temporal:value ) μια ιδιότητα που κληρονομεί η κλάση Time από την κλάση temporal:validtime. Αντίστοιχα με τον δεύτερο κανόνα, αν θέλαμε να κατατάξουμε τα μηνύματα αυτά σε ένα real time περιβάλλον μιας SIP υποδομής, θα έπρεπε να αλλάξουμε την κεφαλίδα του κανόνα σε flood(). 80

89 4.4 Εξαγωγή Αποτελεσμάτων Για την εξαγωγή των αποτελεσμάτων ο χρήστης μπορεί να επιλέξει πάλι μέσω δύο μεθόδων. Είτε, χρησιμοποιώντας το SWRLTab[27] που βρίσκεται στο Protégé, είτε καλώντας τους κανόνες μέσω Java. Παρέχονται επίσης, δυο μηχανισμοί στο Protégé που μπορούν να χρησιμοποιηθούν και στην Java. Ο μηχανισμός Jess[30] χρησιμοποιείται για κανόνες που δεν περιέχουν sqwrl ενσωματωμένους κανόνες, ενώ ο μηχανισμός SQWRLQuery[28] χρησιμοποιείται για τους υπόλοιπους και δεν μπορεί να επιστρέψει αποτελέσματα για κανόνες που δεν έχουν κάποιο πρόθεμα sqwrl στην κεφαλίδα. Ο κώδικας του αρχείου της Java που διαβάζει το owl αρχείο και επιστρέφει τα αποτελέσματα παρέχεται στο παράρτημα 1. Αποτελέσματα 1 ου κανόνα Στην εικόνες[6] και στην εικόνα[7], μπορούμε να δούμε τα αποτελέσματα του κανόνα που παράγονται από το μοντέλο μας. Η πρώτη εικόνα, εμφανίζει τα αποτελέσματα μέσω του Protégé και η δεύτερη από το Command Line : Εικόνα[6] - Αποτελέσματα 1 ου κανόνα μέσω Protégé Εικόνα[7] - Αποτελέσματα 1 ου κανόνα μέσω Java Και στις δύο περιπτώσεις παρατηρούμε ότι τα μηνύματα που υπερβαίνουν το όριο των 140 bytes στο σώμα μηνύματος, είναι τα μηνύματα G_Message, F_Message, B_Message και E_Message. O χρόνος εκτέλεσης του ερωτήματος όπως παρατηρούμε είναι 580 χιλιοστά του δευτερολέπτου μέσω Java, πολύ μικρότερος του χρόνου απόκρισης του Protégé. 81

90 Αποτελέσματα 2 ου κανόνα Αντίστοιχα για τον δεύτερο κανόνα παράγονται και από τους δυο τρόπους τα παρακάτω αποτελέσματα: Εικόνα[8] - Αποτελέσματα 2 ου κανόνα μέσω Protégé Εικόνα[9] - Αποτελέσματα 2 ου κανόνα μέσω Java Στα αποτελέσματα αυτά, παρατηρούμε ότι ο χρήστης με όνομα bob έχει τη δυνατότητα να αποστείλει παραπάνω από ένα μηνύματα την ίδια χρονική στιγμή. Συγκεκριμένα έχει στείλει επιτυχώς δύο μηνύματα τη χρονική στιγμή 00:00:01 στις , οπότε μπορούμε να υποθέσουμε ότι είναι κακόβουλος χρήστης και μπορεί να επιχειρήσει επιθέσεις flood. Όπως μπορούμε να διακρίνουμε στην εικόνα[9] ο χρόνος εξαγωγής των αποτελεσμάτων είναι 594 χιλιοστά του δευτερολέπτου. 82

91 Αποτελέσματα 3 ου κανόνα: Τέλος, στις εικόνες[10],[11] παρουσιάζονται τα αποτελέσματα που παράγονται από την εφαρμογή του τρίτου κανόνα: Εικόνα[10] - Αποτελέσματα 3 ου κανόνα μέσω Protégé Εικόνα[11] - Αποτελέσματα 3 ου κανόνα μέσω Java Παρατηρούμε ότι η χρήστης με όνομα Alice έχει αποστείλει 3 μηνύματα με διαφορά 10 δευτερολέπτων αναμεταξύ τους. Αντίστοιχα, μπορούμε να υποθέσουμε ότι και αυτός ο χρήστης έχει επιχειρήσει flood επίθεση στην VoIP υποδομή μας. Αναλύοντας περισσότερο τα αποτελέσματα, παρατηρούμε μέσω του μοντέλου μας ότι τα μηνύματα αυτά χρησιμοποιούσαν την μέθοδο REGISTER. Έτσι, είναι πολύ πιθανό η Alice να έψαχνε για τον κωδικό κάποιου χρήστη. Ο κανόνας αυτός εκτελέστηκε σε χρόνο 500 χιλιοστών του δευτερολέπτου. 83

92 ΚΕΦΑΛΑΙΟ 5 - ΣΥΜΠΕΡΑΣΜΑΤΑ ΚΑΙ ΜΕΛΛΟΝΤΙΚΗ ΕΡΓΑΣΙΑ Στο πρώτο και το δεύτερο κεφάλαιο, είδαμε και αναλύσαμε την γλώσσα OWL και την SWRL αντίστοιχα. Ο συνδυασμός αυτών των δύο γλωσσών μας άφησε θετικές εντυπώσεις. Αυτό συμβαίνει γιατί, η OWL προσφέρει δυνατότητες περιγραφής ενός πραγματικού ή μη μοντέλου, τόσο σε έναν υπολογιστή, όσο και σε έναν άνθρωπο. Επίσης, η χρήση των κανόνων της SWRL προσφέρει διαδραστικότητα στο μοντέλο, αντικατοπτρίζοντας πραγματικές συνθήκες με έναν απλούστατο τρόπο. Η εξέλιξη και η ανάπτυξη του σημασιολογικού ιστού, θα καταστήσει τον συνδυασμό αυτών των δυο γλωσσών στις πιο σημαντικές στην επιστήμη των υπολογιστών και αργά η γρήγορα η SWRL θα προτυποποιηθεί. Ωστόσο, κάποιες ατέλειες ακόμα υφίστανται. Η πιο απλή που αντιμετωπίσαμε ήταν ότι ενώ είχαμε την δυνατότητα να ορίσουμε συγκεκριμένες τιμές για τις ιδιότητες των κλάσεων (π.χ. τιμές ακεραίων, αλφαριθμητικά κ.α.) δεν μπορούσαμε να ορίσουμε το μέγεθος των τιμών του πεδίου, όσον αφορά τα ψηφία. Το Protégé, αποτελεί ένα από τα καλύτερα προγράμματα σύνταξης οντολογιών. Το γεγονός ότι διανέμεται δωρεάν, είναι ανοιχτού κώδικα, έχει υλοποιηθεί σε Java καθώς και η μεγάλη ψηφιακή κοινότητα που έχει δημιουργηθεί από τους χρήστες του, θα βοηθήσει πολύ στην επέκταση του. Επίσης, αναμένεται στο μέλλον η ενσωμάτωση ακόμα περισσότερων εργαλείων σε αυτό, προσφέροντας ακόμα περισσότερες δυνατότητες στους χρήστες. Η επιλογή του SIP για την μοντελοποίηση του στην OWL, έγινε καθώς το πρωτόκολλο αυτό φαίνεται να ξεπερνά, όλα τα υπόλοιπα πρωτόκολλα σηματοδοσίας που έχουν σχεδιαστεί για την διαδικτυακή τηλεφωνία. Αυτό είναι γεγονός γιατί το SIP έχει υιοθετηθεί από διάφορους οργανισμούς προτυποποίησης όπως η IETF[31], η ETSI[32] και η 3GPP[33] ως το κυρίαρχο πρωτόκολλο για τα ενσύρματα και ασύρματα δίκτυα των επόμενων γενεών. Όπως παρατηρήθηκε, παρά τη χρήση μηχανισμών ασφαλείας από άλλα πρωτόκολλα, το SIP παραμένει ευάλωτο σε επιθέσεις που αποσκοπούν να θίξουν την διαθεσιμότητά του και αφήνει όλα τα στοιχεία της αρχιτεκτονικής του ευάλωτα. Η αξιοποίηση του προτεινόμενου μοντέλου μπορεί να βοηθήσει σε αρκετούς τομείς μια SIP υποδομή, τόσο σε offline αλλά και real time περιβάλλον. Συγκεκριμένα στη συνέχεια παρουσιάζονται αναλυτικά τα χαρακτηριστικά που μπορούν να υιοθετηθούν από τους παρόχους SIP υπηρεσιών μέσω ενός τέτοιου μοντέλου: 84

93 Η οντολογική δομή και αρχιτεκτονική του συγκεκριμένου μοντέλου βοηθά τους μηχανισμούς ανάλυσης και ανάγνωσης μηνυμάτων (parsers), διευκολύνοντας την λειτουργία τους. Έτσι, γίνονται αποδεκτά μόνο τα μηνύματα που καλύπτουν τους περιορισμούς που έχουμε θέσει στο μοντέλο όπως αυτά αναλύθηκαν στο κεφάλαιο 3. Επίσης με αυτόν τον τρόπο μειώνεται αισθητά, ο κίνδυνος από κακόβουλους χρήστες που προσπαθούν να εκμεταλλευτούν την ευπάθεια αυτών των μηχανισμών στέλνοντας ασύμβατα μηνύματα. Ως αποτέλεσμα τα μη συμβατά με την προδιαγραφή του SIP[17] μηνύματα αγνοούνται και απορρίπτονται άμεσα. Παράλληλα, το μοντέλο εξασφαλίζει στους σχεδιαστές αυτών των μηχανισμών ένα ασφαλές και ευέλικτο πρότυπο σχεδιασμού. Η λειτουργία των κανόνων όπως άλλωστε είδαμε από τα αποτελέσματα του προηγούμενου κεφαλαίου, βοηθά στην καταπολέμηση των επιθέσεων επάνω στις οποίες βασιστήκαμε για την δημιουργία των κανόνων. Αναλυτικότερα, αντιμετωπίστηκαν επιτυχώς τα μηνύματα που διατηρούν την προδιαγραφή του SIP, αλλά υπερβαίνουν το όριο του σώματος μηνύματος. Επίσης, επιθέσεις flood από μοναδική πηγή και επιθέσεις ανακάλυψης του κωδικού κάποιου χρήστη. Καταφέραμε να δημιουργήσουμε ένα κατώφλι χρονικού ορίου για τη συνεχόμενη αποστολή μηνυμάτων, καταπολεμώντας επιθέσεις flood που δύναται να παρέχονται από διαφορετικές πηγές. Όλα αυτά μόνο με τη λειτουργία τριών κανόνων. Σίγουρα, μπορούν να σχεδιαστούν περισσότεροι κανόνες για τη διασφάλιση του SIP, ενώ ακόμα και η επέκταση των προτεινόμενων κανόνων μπορεί να βοηθήσει στην αποτροπή περισσότερων καταστάσεων επίθεσης. Τα μικρό κόστος σε χρόνο για την εκτέλεση των ερωτημάτων και την εξαγωγή των αποτελεσμάτων, καθώς και η υλοποίηση τους σε Java αφήνει ανοιχτό το ενδεχόμενο εφαρμογής ενός τέτοιου μοντέλου σε κανονικές VoIP υποδομές που χρησιμοποιούν το SIP. Ένα τέτοιο παράδειγμα μπορούμε να δούμε στην εικόνα[12] που αναπαριστά μια αρχιτεκτονική SIP με ένα σύστημα ανίχνευσης επιθέσεων (IDS), που βασίζεται στην προτεινόμενη οντολογία. Εικόνα[12] - Αρχιτεκτονική SIP-IDS βασιζόμενη σε οντολογικό μοντέλο 85