RDF driven Environment services
- RDF and REST HATEOAS
- Contexts
- Rules
- Interaction patterns
- REST service and technology stack
- AngularJS app
- Questions ..
RDF and REST HATEOAS
RDF:
- Lends itself to a distributed ontology structure, merging different documents
- Can be integrated with Natural Language
- A more meaningful representation of data, encapsulating the knowledge
- High-level English verbs (comprising low level REST calls) can be modelled as OWL predicates
REST HATEOAS constraint:
- “Follow your nose” approach to navigate data
- May be applied to RDF representations as well, through serialization formats such as JSON-LD
- In this example though, we stick to upholding HATEOAS using AtomLinks (this is not the best approach though)
Contexts
A “context” usually specifies an environment setting. In this example, the context specifies the following facts in RDF —
“Smart-mart” is a store that contains a section on “Whole foods”. This section displays a form on “Wholly nutritious foods”, which lists “Peanut butter”, “cheese” and “almonds”. Buying each of those from the shelf results in a tweet which describes the small discount offered upon tweeting the purchase. Further, as Smart-mart is inside a certain airport (YVR), there is a sensor that has subscribed to the departing flight count at YVR.
These facts are stated in the graph below. Contexts can be crowdsourced.
Rules
A “rule” specifies the behaviour resulting out of each component of the above context. In that sense, rules, defined as subject-nodes in the below graph/TTL may be the predicate nodes of the context graph above. Rules may themselves be bound to endpoints, which are loosely-coupled. Those endpoint invocations will accept parameters, whose values will be sourced from the context graph above, at runtime. In this example, the following rules have been described in the generated-graph below –
“contains”, “subscribes”,”consists”,”displays”,”tweets”
Rules can be crowdsourced.
Interaction Patterns
Finally, there is a third RDF document that describes how a user chooses to interact with the context. This adds a third degree-of-freedom to our configuration.
In this example, the interaction sequence is described as follows:
- The user enters Smart-mart, thereby also passively subscribing to the WotKit sensor for YVR airport departure-counts.
- The user proceeds to Whole foods section
- The user sees the display of Wholly nutritious foods
- The user proceeds to buy one or several items among – Peanut butter, cheese, almonds, thereby tweeting his purchases automatically
The interaction patters are described in the graph below
REST service and technology stack
We create a REST service upholding the HATEOAS constraint using Atomlinks, wherein we simply crawl the “Interaction pattern” described before, thereby using SPARQL to join these disparate documents in the process, with as little out-of-band data (eliminating the out-of-band data is a challenge!)
- One of the out-of-band data is the way the join happens between contexts and rules. This needs to be parameterized.
- In general, there needs to be a join between the way these RDFs are built and how they’re queried in SPARQL. This maybe done through an overarching RDF or a factory-API
The technologies used for this prototype are {RDF, SPARQL, Apache Jena, WotKit Sensor API, Twitter API, AngularJS}
AngularJS app
Finally, an AngularJS app is built to crawl the REST HATEOAS service and simply display and navigate to/from each “Step” that is defined in the “Interaction Pattern” RDF. That makes the client app very lightweight. Shown below are the AngularJS and Twitter screenshots, and the first step also shows the data obtained from the WotKit sensor.
Questions
Questions mainly revolve around how to API-fy/parameterize the “glue code” in the SPARQL query. To that, this is an excellent article — http://www.markus-lanthaler.com/research/hydra-a-vocabulary-for-hypermedia-driven-web-apis.pdf
so i wrote 