COSMOS Cultivate Resilient Smart Objects for Sustainable City Applications COSMOS-Minimal Planner Functionalities; Dependencies, instructions and code overview 2016 May 23 rd Παναγιώτης Μπουρέλος (ICCS/NTUA)
Ο Planner Στα πλαίσια του ερευνητικού προγράμματος COSMOS, η ομάδα του ΕΜΠ παρήγαγε κώδικα για ευρέσεις ομοιότητας μεταξύ αντικειμένων αποθηκευμένων σε οντολογία Ο κώδικας αυτός είναι βασισμένος σε JAVA και χρησιμοποιεί τη βιβλιοθήκη Apache Jena για την εισαγωγή ή την εξαγωγή στοιχείων από αρχείο τύπου.owl Για την προσπέλαση της οντολογίας και το fine tune χρησιμοποιήθηκε ο Protégé ontology manager Καθόλη τη διάρκεια της ανάπτυξης του κώδικα, υπήρξαν πολλές ιδέες για την τελική μορφή αλλά εν τέλει καταλήξαμε στα παρακάτω.
Ο Planner Η δομή του Planner και σε γενικότερο επίπεδο αλλά και ειδικότερα είναι στη μορφή ενός stand alone group υπηρεσιών τα οποία στήθηκαν με τη βοήθεια του Jetty server Αξίζει να τονίσουμε την επιμονή στη χρήση ελεύθερου λογισμικού ως executive απόφασης Αυτές οι υπηρεσίες βασίζονται στο πρότυπο REST και λειτουργούν ως την πύλη επικοινωνίας του Planner με τα εξωτερικά ερεθίσματα/μηνύματα Στην παρούσα μορφή του o Planner, λαμβάνει ένα σύνθετο μήνυμα της μορφής: { "payload": { "message_type": 1 or 2 (implemented 1), "problem_attributes": "hasOne#hasTwo#hasThree", "problem_values": "wow#such_blah#much_talk", "solution_attributes": "hasFour#hasFive#hasSix", "forSharing":"false", "weights":"0.5#0.4#0.1", "threshold":"1.0" }
Ο Planner Το μήνυμα αυτό αντιπροσωπεύει την περιγραφή ενός δεδομένου «προβλήματος» το οποίοι ενδέχεται να υπάρχει ή όχι στην οντολογία (μαζί με τα στοιχεία τα οποία αποτελούν τη λύση του) Το πρόβλημα περιγράφεται από τα ονόματα των ιδιοτήτων του, τις τιμές τους, τα ονόματα ιδιοτήτων λύσης, τα βάρη για τον υπολογισμό της ολικής ομοιότητας και ένα κατώφλι για το πόσο θέλουμε να ταιριάζει απόλυτα με τυχόν παρόμοιες περιπτώσεις προβλημάτων στη βάση Το μήνυμα το ίδιο είναι στη μορφή JSON και όπως παρατηρείτε οι τιμές κάθε πεδίου χωρίζονται με «#». Το parsing του μηνύματος γίνεται μέσα στον κώδικα με τη βοήθεια βιβλιοθηκών της JAVA καθώς και εξωτερικών dependencies όπως το JSON Simple
Ο Planner Οι επιλογές σας για την εισαγωγή μηνύματος στον Planner είναι η εξής μια: HTTP POST Εξαρχής χρησιμοποιείται μόνο το POST για την αποστολή μηνυμάτων μεταξύ υπηρεσιών της εφαρμογής ή και μεταξύ απομακρυσμένων κόμβων Προσφάτως ως δομή και το JSON εξ ολοκλήρου
Ο Planner Η πορεία του μηνύματος και το τι γίνεται στον minimal Planner θα αναλυθεί τώρα Αρχικά το μήνυμα λαμβάνεται από το outward looking interface του Planner ώστε να αναλυθεί και να προωθηθεί στην κατάλληλη υπηρεσία Αυτό γίνεται με τον έλεγχο της τιμής του πεδίου «message_type». Στην παρούσα φάση το μόνο το οποίο υποστηρίζεται είναι η τιμή 1 Στη συνέχεια όταν η κατάλληλη υπηρεσία λάβει το μήνυμα τότε ξεκινά η διαδικασία parsing
Ο Planner Μετά το διαχωρισμό των δεδομένων, καλείται κατάλληλη συνάρτηση Η συνάρτηση αυτή, εκτελεί ένα SPARQL Query στη βάση παραμετρικά δημιουργημένο αρχικά για την εύρεση παρόμοιου τύπου Case Κατόπιν λαμβάνονται πίσω όλες οι σχετικές εγγραφές και εντός κώδικα εκτελείται μια μέτρηση ομοιότητας
Ο Planner Η επιστροφή της διαδικασίας είναι η λύση του πιο παρόμοιου προβληματος Συγκεκριμένα κάποιο μήνυμα, μια πιθανή υπηρεσία εκτέλεσης και τυχόν ορίσματα. Πολύ βασικό στάδιο είναι η χρήση του Protégé για τη δημιουργία οντολογίας και με manual τρόπο η εισαγωγή εγγραφών προβλημάτων-λύσης(1 και 1) Προτείνεται η χρήση του αρχείου casebase.owl το οποίο είναι σεταρισμένο σε βαθμό που χρειαζεται από τον κώδικα και η προσθήκη νέων individuals για Problem-Solution ζευγων Τα naming convention πρέπει να κρατηθούν ως έχουν
Ο Planner Επίσης για την εισαγωγή νέων Datatype Properties μπορείνα γίνει χρήση του αντίστοιχου tab στο Protégé Στο σημείο αυτό θα εξηγηθεί και η δομή εντός της οντολογίας Ερωτήσεις ευπρόσδεκτες και μάλλον απαραίτητες
Thank you! Παναγιώτης Μπουρέλος ICCS/NTUA The research leading to these results has received funding from the EC Seventh Framework Programme FP7/ under Grant Agreement n°