Op verzoek heb ik de openingspost behoorlijk aangepast en uitgebreid. De uitgeklede vraag kan hier worden gevonden. De openingspost geeft nu hopelijk een beter beeld van wat ik wil bereiken en waarom het een redelijk complex systeem is.
"What is the influence of Information Services supported by Formal Semantics on Human decision making".
Het laatste is denk ik duidelijk (denk aan speed, quality, satisfaction and confidence). Bij Information services moet je denken aan kleine stukken software die de Human Decision Maker (HDM) van informatie voorzien. Dit kan bijvoorbeeld Google Maps zijn, maar ook een beurstracker of software die live energieprijzen doorgeeft.
Formal Semantics is de beschrijving van objecten (simpel gezegd). Dit kan je doen met een tafel (heeft vier poten, is van hout/staal/glas etc en kan X kg dragen) maar je kan het ook met software doen. Wanneer je software omschrijft (denk aan input, output en wijze van communiceren) kan je dankzij deze omschrijving software automatisch aan elkaar koppelen.
Met mijn onderzoek ben ik bezig software die binnen mijn onderzoeksgroep in een gesloten omgeving werd gebruikt om te zetten naar een versie die in de buitenwereld gebruikt kan worden. In plaats van services binnen de eigen software die aan elkaar worden gekoppeld probeer ik dit te doen voor online services (stukken software met een eenvoudige API).

Het meest eenvoudige voorbeeld is wanneer je het weer op wilt vragen dat met de huidige services de BB de volgende gedachtestappen maakt: Voor het weer heb ik een plaatsnaam nodig, een plaatsnaam kan ik halen vanuit Google Maps, daarvoor heb ik of Lengte & Breedtegraad of een Locatie nodig, Lengte & Breedtegraad heb ik niet maar Locatie kan ik vinden in Google Calendar.
Vervolgens gaat het dus de data uit Google Calendar halen, bewerkt deze ruwe data, slaat deze op en gaat naar Google Maps, haalt de data op, verwerkt de data en gaat naar WeatherOnline om daar het weer op te halen. Let op deze services zijn voor mij een testscenario en zouden elke willekeurige service kunnen zijn zolang ik ze maar omschrijf in een XML-bestand hoe de Input, Output & Communicatie gaat.
Elke keer dat de BB naar de volgende service toe gaat komt dit omdat het een seintje krijgt dat alle variabelen aanwezig zijn. Daarna maakt een aparte functie de datasets klaar die gebruikt moeten worden om de service van de juiste info te voorzien. Deze scheiding van data ophalen & opslaan is gemaakt om het zo robuust mogelijk te maken.
Vrijwel alle problemen die ik had zijn opgelost in de zin dat ik bijna een werkend systeem heb behalve het dynamisch opslaan van de gegevens. Dit probleem heb ik uitgelegd in deze post
Thesis Topic
Voor mijn master thesis ben ik de volgens research question aan het onderzoeken:"What is the influence of Information Services supported by Formal Semantics on Human decision making".
Het laatste is denk ik duidelijk (denk aan speed, quality, satisfaction and confidence). Bij Information services moet je denken aan kleine stukken software die de Human Decision Maker (HDM) van informatie voorzien. Dit kan bijvoorbeeld Google Maps zijn, maar ook een beurstracker of software die live energieprijzen doorgeeft.
Formal Semantics is de beschrijving van objecten (simpel gezegd). Dit kan je doen met een tafel (heeft vier poten, is van hout/staal/glas etc en kan X kg dragen) maar je kan het ook met software doen. Wanneer je software omschrijft (denk aan input, output en wijze van communiceren) kan je dankzij deze omschrijving software automatisch aan elkaar koppelen.
Met mijn onderzoek ben ik bezig software die binnen mijn onderzoeksgroep in een gesloten omgeving werd gebruikt om te zetten naar een versie die in de buitenwereld gebruikt kan worden. In plaats van services binnen de eigen software die aan elkaar worden gekoppeld probeer ik dit te doen voor online services (stukken software met een eenvoudige API).
Software
Onderstaand is een vereenvoudigde versie van de architecture te zien. Als eerste laad de Black Box (BB) alle beschrijvingen van de services die aanwezig zijn (een voorbeeld kan je hier vinden). Vervolgens kan het een request van buitenaf krijgen voor bepaalde informatie. Aan de hand van de beschrijvingen gaat het dan kijken welke informatie het nodig heeft om aan deze informatie te voldoen en combineert aan de hand van deze info de verschillende services.
Het meest eenvoudige voorbeeld is wanneer je het weer op wilt vragen dat met de huidige services de BB de volgende gedachtestappen maakt: Voor het weer heb ik een plaatsnaam nodig, een plaatsnaam kan ik halen vanuit Google Maps, daarvoor heb ik of Lengte & Breedtegraad of een Locatie nodig, Lengte & Breedtegraad heb ik niet maar Locatie kan ik vinden in Google Calendar.
Vervolgens gaat het dus de data uit Google Calendar halen, bewerkt deze ruwe data, slaat deze op en gaat naar Google Maps, haalt de data op, verwerkt de data en gaat naar WeatherOnline om daar het weer op te halen. Let op deze services zijn voor mij een testscenario en zouden elke willekeurige service kunnen zijn zolang ik ze maar omschrijf in een XML-bestand hoe de Input, Output & Communicatie gaat.
Elke keer dat de BB naar de volgende service toe gaat komt dit omdat het een seintje krijgt dat alle variabelen aanwezig zijn. Daarna maakt een aparte functie de datasets klaar die gebruikt moeten worden om de service van de juiste info te voorzien. Deze scheiding van data ophalen & opslaan is gemaakt om het zo robuust mogelijk te maken.
Vrijwel alle problemen die ik had zijn opgelost in de zin dat ik bijna een werkend systeem heb behalve het dynamisch opslaan van de gegevens. Dit probleem heb ik uitgelegd in deze post
[ Voor 91% gewijzigd door Rainmaker1987 op 19-10-2011 10:53 . Reden: Verduidelijking situatie ]