Introduction
The article was a submission to ISWC 2014 Developer Workshop
Linked data and its RDF model is known for its flexible schema less structure and integrated meta-data. Although this is great for expressiveness of the data, its is a nightmare for interface developers since all the modern interface paradigms are tree based.
The standard way of interacting with data in these user interfaces is to use application logic to interact with interface elements which needs to query the data and decide which piece of information to put in which element. Trying to push free format RDF in a tree is not a easy tasks and often results in very static interface for a specific graph structure.
Wouldn’t it be more intuitive to use the meta data in the RDF to decide which user interface element treats which property? And even more intuitive let the UI be able to decide to get more data from other linked resources without needing specific application logic ?
Traditional Model
Lets try to go through the traditional model with static data:
Data: Bart, van leeuwen, @semanticfire, //netage.nl/dir.ttl
Code: Select firstname, lastname,handle,companyprofile from data interface.firstname.setValue(resultRow.interface)
Interface: Field firstname Field lastName Field handle Field companyProfile
If any changes are made on the interface, it is up to the application logic to extract it from the interface and modify the underlying data model.
So if we get a new data structure as input we need to change both logic and interface to react to that. When we want to react to different types of input structures both the interface and logic are getting more and more complex. This is mainly due to the fact that the data is pretty ‘dumb’ we need the logic to identify various pieces of data and match them to user interface elements, the other way around is even more complex. Getting the modified data an sending it back to the underlying data model. There we need a extra step to make sure both UI and application logic are in sync with the constraints of the data store.
The traditional solution while dealing with RDF data is to use SPARQL queries to get somewhat structured data which resembles the result of the SQL query above. Although we can use traditional methods to show the data, we loose a significant part of the semantics around it, the data is ‘dumb’ again. Updating data is even more complex since SPARQL results might come from multiple endpoints and that information is not present in the SPARQL result set.
A different approach
Now how can we use the context in RDF to eliminate application logic and put all the logic in the interface. If we are able to do this it would allow us to simply be ready when the piece of information we are able to show comes by and complies to the constraints we have set on it.
During the development of some of the front ends of our system we started out with the traditional SPARQL way. One of the important reasons to use linked data in our solution is the agile nature, adding extra properties or replacing them is easy and doesn’t require large schema updates. However on the front end we were still struggling with multiple SPARQL queries for the various incarnations of our data. This should be done in a smarter way.
Introducing EnyoJS
In our search for toolkits to create mobile applications we came across EnyoJS [1] a Javascript framework which originated on the Palm Pre smart phones as a part of WebOS and evolved in a Framework for platform independent applications. The current Enyo 2.4 version is the basis for LG’s latest SmartTV Platform. The concept of EnyoJS is encapsulation, components should have no knowledge about their place in the hierarchy, they communicate with bubbling up and water-falling down events. They have no control who receives these notifications and events. There is also no limitation on which components encapsulate each other. The flow of events and notifications is left undisturbed by encapsulation, adding a extra component around another doesn’t break the chain, unless the inserted component deliberately listens and ends the event chain. Components can directly talk to elements they define but should not talk to the inner components of those elements. Neither should they directly talk to their parent components.
The EnyoJS way
The encapsulation gave us the inspiration to see if we could use this method to add a linked data property to components. By encapsulating a standard UI component with a linked data aware component we would be able to define at interface level which element should contain values of predicates.
So if we would have a UI Container C which contains a Textbox T traditionally it would look like
C1 → T
The container would use the traditional SPARQL way to get data and update the value v of T . Our approach would be that in between C and T we place a property component P which is configured to react to predicate “example:foo” and propagate the value of “example:foo” to its components.
C2 → P → T
and instead of the traditional SPARQL way we simply let C announce to its children it has a graph available, P will pick up any triple which has the “?s example:foo ?o” pattern and extracts the value ?o and propagates this to its underlying components. P will stop the waterfall. This method would still allow to insert a extra component in between, e.g. a Box B
C2_2 → P → B → T
Since B is does not have a “setvalue” called by P we will simply call T directly, remember we can call methods of defined components directly.
If the value of ?o is a URI, P will try to load that resource and announce to its components that it has a Graph. So if I would like to know “foaf:name” from someone I “foaf:knows” it would look a bit like this.
C3 → P¹ → P² → T
Where P¹ listens to “foaf:knows” which will load the graph and announces it to its components where P² which then will set the value of T to “foaf:name”
Presenting multiple properties is no problem either if I am also interested in the “foaf:mbox” value of my “foaf:knows” relations ships this would work as well.
C4 → P¹ → [ P² → T¹, P³ → T² ]
Here P³ represents “foaf:mbox”
The above example snippets can be found in the github repo [2] from the samples you can clearly see that the ‘meta-data’ stays close to the interface level and we only fetch and announce the source graph once. The snippets just give a rough overview of what is possible with this approach.
Additional possibilities
The EnyoJS platform knows the concept of repeaters, which allows components to contain a virtually unlimited amount of instance of another component. This would solve a cardinality issue.
C → P¹ → R → P² → T
Here Repeater R is used to create multiple T components from all the “foaf:knows” relations I have.
Its also possible to combine multiple components inside a repeaters, e.g. P³ listens to foaf:mbox
C → P¹ → R → [ P² → T¹ , P³ → T² ]
this would result in a list of names and emails addresses of all the “foaf:knows” relationships in my profile.
The way back.
By maintaining the ?s on the P components propagating updates back is relatively easy
C ← P ← T
if we update T, and configure P to listen to the updates ?u to value ?o while maintaining ?s related to P we can simply construct a triple out of that
?s → P:predicate → ?u
which replaces
?s → P:predicate → ?o
We now would be able to either construct a SPARQL Update, provided we know which endpoint to use, or use LDP spec to to do a patch on ?s
Of course you might want to constraint the actual execution of water-falling based on property values, e.g. only show properties which are no older then one week. And only show a certain component if there actually is data, or have property component just be responsible for containing other properties without generating any UI. It even allows to listen to the same property with different constraints.
e.g.
C → P(ex:foo >= 50 ) → Tgreen
C → P(ex:foo <50 ) → TRed
If T would be a editable field passing the threshold of 50 would in the end propagate the update up to C which would then announce a updated graph, which in turns would show the T with the right color.
For formating back and forth EnyoJS provides all sorts of transition hooks which would allow to format a xsd:DateTime to something human readable, and back to xsd:DateTime after modification
Conclusion
By using the encapsulation mechanism in EnyoJS we are able to to combine both UI description and the related RDF properties in a single place without being bothered by external code to sync the model and the interface. Although surely in its infancy the approach described here is not only a nice idea, it is practically being used in our applications.
The code is not in the public domain yet, but this is certainly something we will be doing in the near future.
Samples
The sample snippets are made available on Github [2]. Handling RDF data is done with rdflib.js [3]
This is none working code right now, I’ll assemble working samples before the conference
Current state and usage
By the time of writing the technique described in this paper is used deployed actively on several monitors at fire stations in the Netherlands
Future work
One of the more obvious additions would be language support., set a preferred language on literals so you can react to multi language RDF.
Multiple property update predicate relation, as in the example above with Tgreen and Tred, maybe a P which updates and listens to the change of ?o but also modifies another property on T, the color in this case.
Using Json-LD to define properties, this would allow the omission of full URI’s and use a context to solve them
User property definitions and constraints based on the work off the future Shape expressions Working group [4] or the Resource Shapes 2.0 submission [5]
References
[1] //enyojs.com
[2] //github.com/semanticfire/iscw2014_dev_workshop
[3] //github.com/linkeddata/rdflib.js/
[4] //www.w3.org/2001/sw/wiki/ShEx
[5] //www.w3.org/Submission/2014/SUBM-shapes-20140211/