Archive for the 'Beginners' Category

Understanding the construct.properties file

Published
by
graeme
on July 9, 2008
in Beginners and Tutorials
. 0 Comments

As the name suggests, the construct.properties file defines settings for the Construct platform. The settings cover three things: global properties for Construct, the components to be instantiated at runtime, and the individual properties of each component.

In the current release, all (bar one) of the global properties are related to logging. The other refers to the hostname of the machine running the Construct software:

Logging level The level of log messages to be recorded
The Logging limit The maximum number of bytes to write to any one log file
The logging file count The number of log files to rotate
The logging file name The base name to use for log files
The logging directory The directory in which the log files are stored
The hostname The hostname or IP address of the machine running the Construct software

The components that you wish to instantiate once the Construct framework is started are also contained in the properties file. Some components also contain properties which are specific to those components and must be declared as children of the components in the properties file. The structure of the properties file is explained further on. Below is an example of some Construct components. More thorough explanations can be found elsewhere on the Wiki.

Data Store Manager Provides a single point of access to the data store
Query Service Processes application and entity queries made in SPARQL
Data Port Accepts RDF data provided by sensors and adds them to the data store
Registry Service Stores information on registered services
Discovery Service Handles requests from clients for available Construct services
Gossiping Components Allows distribution of data store contents
Extension Components Add-on components such as a Query Viewer

Once the start button is clicked on the Construct GUI, a Component Loader is created which reads in the contents of the properties file and instantiates any components that are specified. On instantiation, each component fetches it’s properties and caters for them.

Reading and Writing to the construct.properties File

The construct.properties file is and XML encoded file in which all properties and components must be contained within the parent node, construct (i.e. it takes the form … ). Global properties must be contained directly inside the construct tags and they are indicated by a property tag. Thus, all properties take the form,

  1. <property name=“[the name here]“ value=“[the value here]“ />

Components must also be defined directly inside the construct tags. The component specific properties must be declared directly inside the opening and closing tags of the component in question. Components are scripted as follows:

  1. <component interface=“[the interface to the component here]“ implementation=“[the implementation of the component here]“>
  2. <property … />
  3. </component>

where the interface specifies the path to the interface for the component and the implementation specifies the path to the concrete implementation of the component.

There is an example properties file contained in the release of Construct. To add new properties follow the structure of the document as explained above. HTML style comments (i.e. <!– [the code to comment here] –>) can be used to prevent a property or component contained in the file from being read in. Ensure to comment the property or component by adding the opening comment (<!–) before the opening tag of the component or property and adding the closing comment (–>) after the closing tag.

Bookmark and Share
[del.icio.us] [Digg] [Google] [StumbleUpon] [Windows Live] [Yahoo!] [Email] More »
Powered by Bookmarkify™

Construct and Python - Part 3

Published
by
lorcan
on July 9, 2008
in Beginners, Python and Tutorials
. 0 Comments

This tutorial shows how to insert RDF from a file (joebloggs_foaf.rdf) into Construct. It then shows how to send a SPARQL query to query this data from Construct. The resulting QueryResults object is printed in N3 format.

  1. from construct.proxy import proxy
  2. from construct.constructservice import ServiceError
  3. from rdflib.Graph import ConjunctiveGraph
  4. # Create a new proxy object.
  5. proxy = proxy()
  6. print “Executing Script”
  7. try:
  8. # Generate a piece of FOAF RDF
  9. store = ConjunctiveGraph()
  10. store.load(“joebloggs_foaf.rdf”)
  11. data = store.serialize(format=“nt”)
  12. # Send the FOAF RDF to the data store
  13. if(proxy.insert(data)):
  14. # Now query for joebloggs web address
  15. query = “”“SELECT ?nickname WHERE{
  16. ?subject <http://xmlns.com/foaf/0.1/name> “Joe Bloggs“.
  17. ?subject <http://xmlns.com/foaf/0.1/nick> ?nickname.}
  18. ““”
  19. results = proxy.query(query)
  20. print “Here is the N3 form of the QueryResults Object:”
  21. print results
  22. except ServiceError, e:
  23. print e
  24. # Close the proxy.
  25. proxy.close()

If this script executes properly something like the following should be printed out:

Executing Script

Here is the N3 form of the QueryResults Object:

_:A6a94e801X3aX118515eda06X3aXX2dX7ffa <http://www.w3.org/2001/sw/DataAccess/tests/result-set#value> “joe” .

_:A6a94e801X3aX118515eda06X3aXX2dX7ffa <http://www.w3.org/2001/sw/DataAccess/tests/result-set#variable> “nickname” .

_:A6a94e801X3aX118515eda06X3aXX2dX7ffb <http://www.w3.org/2001/sw/DataAccess/tests/result-set#binding> _:A6a94e801X3aX118515eda06X3aXX2dX7ffa .

_:A6a94e801X3aX118515eda06X3aXX2dX7ffc <http://www.w3.org/2001/sw/DataAccess/tests/result-set#solution> _:A6a94e801X3aX118515eda06X3aXX2dX7ffb .

_:A6a94e801X3aX118515eda06X3aXX2dX7ffc <http://www.w3.org/2001/sw/DataAccess/tests/result-set#resultVariable> “nickname” .

_:A6a94e801X3aX118515eda06X3aXX2dX7ffc <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2001/sw/DataAccess/tests/result-set#ResultSet> .
This post is the final part of a python and Construct tutorial. Part 1 is here and part 2 is here.

Bookmark and Share
[del.icio.us] [Digg] [Google] [StumbleUpon] [Windows Live] [Yahoo!] [Email] More »
Powered by Bookmarkify™

Construct and Python - Part 2

Published
by
lorcan
on July 9, 2008
in Beginners, Python and Tutorials
. 1 Comment

This code demonstrates how to interact with the client proxy using the RDFLib package:

  1. from construct.proxy import proxy
  2. from construct.constructservice import ServiceError
  3. from rdflib import RDF, Namespace, Literal
  4. from rdflib.Graph import ConjunctiveGraph
  5. FOAF = Namespace(“http://xmlns.com/foaf/0.1/”)
  6. exampleNS = Namespace(“http://www.example.com/”)
  7. # Create a new Proxy object.
  8. proxy = proxy()
  9. print “Executing Script”
  10. try:
  11. # Generate a piece of FOAF RDF
  12. store = ConjunctiveGraph()
  13. store.bind(“foaf”, “http://xmlns.com/foaf/0.1/”)
  14. store.add((exampleNS["~joebloggs"], RDF.type, FOAF["Person"]))
  15. store.add((exampleNS["~joebloggs"], FOAF["name"], Literal(“Joe Bloggs”)))
  16. store.add((exampleNS["~joebloggs"], FOAF["nick"], Literal(“joe”)))
  17. store.add((exampleNS["~joebloggs"], FOAF["givenname"], Literal(“Joe”)))
  18. store.add((exampleNS["~joebloggs"], FOAF["family_name"], Literal(“Bloggs”)))
  19. data = store.serialize(format=“nt”)
  20. # Send the FOAF RDF to the data store.
  21. if proxy.insert(data):
  22. print “The following data were added correctly:”
  23. print data
  24. else:
  25. print “Problem encountered when adding the following data:”
  26. print data
  27. except ServiceError, e:
  28. print e
  29. # Close the proxy.
  30. proxy.close()

If this code has run correctly the following should be printed:

Executing Script

The following data were added correctly:

<http://www.example.com/~joebloggs> <http://xmlns.com/foaf/0.1/givenname> “Joe”.

<http://www.example.com/~joebloggs> <http://xmlns.com/foaf/0.1/nick> “joe”.

<http://www.example.com/~joebloggs> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://xmlns.com/foaf/0.1/Person>.

<http://www.example.com/~joebloggs> <http://xmlns.com/foaf/0.1/name> “Joe Bloggs”.

<http://www.example.com/~joebloggs> <http://xmlns.com/foaf/0.1/family_name> “Bloggs”.
This post is the second part of a tutorial on construct and python. Back to Part 1 of this tutorial or on to Part 3.

Bookmark and Share
[del.icio.us] [Digg] [Google] [StumbleUpon] [Windows Live] [Yahoo!] [Email] More »
Powered by Bookmarkify™

Construct and Python - Part 1

Published
by
lorcan
on July 9, 2008
in Beginners, Python and Tutorials
. 2 Comments

This post will show how to connect to a Construct Data Port and submit RDF data.

If an instance of Construct is available, this code will insert two pieces of RDF in N3 format. The first of these is good RDF, the second of these is not. The script is below, and example output beneath that again.

  1. #Import the python construct proxy.
  2. from construct.proxy import proxy
  3. from construct.constructservice import ServiceError
  4. #Create a new Proxy object.
  5. proxy = proxy()
  6. print “Executing Script”
  7. try:
  8. # Send a VALID piece of RDF to the data store
  9. insertGoodResponse = proxy.insert(“<http://hello><http://construct>\”world\”.”);
  10. print “Response to good RDF: “ + str(insertGoodResponse)
  11. # response should be “1″
  12. # Send an INVALID piece of RDF to the data store.
  13. insertBadResponse = proxy.insert(“<http://badly><http://formed>\”rd\”f\”.”);
  14. print “Response to bad RDF: “ + str(insertBadResponse)
  15. # response should be “None”
  16. except ServiceError, e:
  17. print e.value
  18. # Close the proxy.
  19. proxy.close()

If this code has executed correctly (i.e., if an instance of Construct is discovered) the following will be printed:

Executing Script

Response to good RDF: 1

Response to bad RDF: None

If the Construct proxy is not found the following will be printed:

Executing Script

Error - unable to contact an instance node of Construct (using address localhost:3826). Is the Construct Proxy running at that address?

and if no instance of Construct is discovered the following will be printed:

Executing Script

Error: No instance of Construct found. Please ensure you are within Zeroconf range of a running instance of Construct
This post is the first part of a tutorial on construct and python. Part 2 of this tutorial is here and part 3 is here

Bookmark and Share
[del.icio.us] [Digg] [Google] [StumbleUpon] [Windows Live] [Yahoo!] [Email] More »
Powered by Bookmarkify™

Construct and Java - Part 2

Published
by
graeme
on July 9, 2008
in Beginners, Java and Tutorials
. 0 Comments

In Part 1 of this series of posts, I described how to add data to Construct. This post will teach you how to get data back out again using the Query Service.

The Java libraries bundled with Construct make use Jena, and the SPARQL query language in the process of querying Construct. If you’re already familiar with Jena, then there is only a couple of additional steps to learn.

Working with Jena and SPARQL

(download the sample code)

To start, we need to open a connection to the Query Service. This is done in the same way as a connection to the Data Port, by creating a new instance of the appropriate class.

  1. final QueryServiceProxy qsProxy = new QueryServiceProxy()

The next step is to create the SPARQL query. In this example, we wish to query for the name property of the subject http://example.com/people/bob that we created in Part 1.

  1. final String query = “SELECT ?name WHERE{
  2. <http://example.com/people/bob>
  3. <http://example.com/terms#name>
  4. ?name}”;

Then we call the query() method of the proxy object, passing the query as an argument. The return value is a Jena ResultSet object corresponding to the result of the query.

  1. final ResultSet resultSet = qsProxy.query(query);

What you do with the result set is obviously dependent on your need for the data. For the purposes of this example, we’ll print the result to the console.

  1. if (resultSet.hasNext()) {
  2. final QuerySolution solution = resultSet.nextSolution();
  3. final Literal name = solution.getLiteral(“name”);
  4. System.out.println(name.toString());
  5. }

Finally, we close the connection to the query service.

  1. qsProxy.close();

That’s the basics of querying data with Construct.

Bookmark and Share
[del.icio.us] [Digg] [Google] [StumbleUpon] [Windows Live] [Yahoo!] [Email] More »
Powered by Bookmarkify™

Construct and Java - Part 1

Published
by
graeme
on July 9, 2008
in Beginners, Java and Tutorials
. 1 Comment

After you install Construct, the next thing you might want to do is add some data. This post will describe the basics.

The Java libraries bundled with Construct give you a couple of ways to contribute date: You can either pass RDF triples in directly, or work with Jena and submit a model when you’re ready to publish its contents.

Working with Triples

(download the sample code)

The first step is to create a connection to the DataPort. This is achieved by creating a new instance of the DataPortProxy class.

  1. final DataPortProxy proxy = new DataPortProxy();

Next, we call the add() method of the proxy object, passing the RDF triple as an argument. Multiple triples can be added simultaneously by separating them with a period. The return indicates whether the add operation was successful.

  1. final boolean response = proxy.add(“<http://example.com/people/bob>
  2. <http://example.com/terms#name>
  3. \”Bob Smith\”.”);

Finally, we close the connection to the data port.

  1. proxy.close();

Working with Jena

(download the sample code)

When using Jena, the process is very similar. As before you should begin by creating a new instance of the DataPortProxy object. Next, a new model should be created, and populated with data.

  1. final Model model = ModelFactory.createDefaultModel();
  2. final Resource person = model.createResource(“http://example.com/people/bob”);
  3. final Property name = model.createProperty(“http://example.com/terms#name”);
  4. person.addProperty(name, “Bob Smith”);

Then, the contents of the Jena model is added to Construct through another of the proxy object’s add() methods. Remember to close the connection as before when you are finished.

  1. final boolean response = proxy.add(model);

That’s the basics of adding data to Construct. The next post in this series will describe how to get data from Construct using the Query Service.

Bookmark and Share
[del.icio.us] [Digg] [Google] [StumbleUpon] [Windows Live] [Yahoo!] [Email] More »
Powered by Bookmarkify™

A brief overview of Construct: component by component

Published
by
steve
on July 9, 2008
in Beginners and Tutorials
. 0 Comments

In this post I’ll give a brief overview of the core components in a Construct node. It’ll be of interest to anyone adapting the way Construct works internally and developers of other middleware platforms. This is a good entry point into how we designed and built Construct.

If you want to build your own components I’m about to write some tutorials and blog posts so check back soon (or grab the RSS feed).

The Component Loader

The number and type of components in any given deployment of Construct is customisable. At runtime, each of the components defined in the construct.properties file is instantiated by the Component Loader, and indexed in a Component Registry to allow collaboration between components. The Component Loader is also responsible for the correct shutdown of the components when the software is terminated.

The Discovery Service

All components that interact directly with sensors or applications provide a self-describing manifest that contains information on how to interact with them. These manifests are maintained by the Discovery Service. This service provides the first point of contact for anyone that wishes to contact a Construct node. The Discovery Service advertises itself using Bonjour.

The Data Manager

The Data Manager is responsible for storing and maintaining an RDF model of all received data. It also contains a meta-data model which holds information describing the RDF statements stored in the first model. Currently this meta-model only stores information describing when the statement expires. The current implementation of this data store manager uses Jena to manage both the models.

The DataPort

The DataPort provides the gateway for adding new data to the Construct infrastructure. It takes the simple form of a TCP socket listening on a port for RDF expressed as a String in N-TRIPLE format. Multiple triples may be concatenated, and an expiry time may be appended to the end of the String if desired.

If you want to drop data directly into the DataPort go read the tutorial on our protocol format first.

The HttpPort

The HttpPort is a convenient way to query construct over HTTP. You can do this programmatically or via a web browser. If you ask the component loader to start the HTTP port (see the construct.properties file) and have Construct running try looking at http://localhost:8888/ to find a simple SPARQL query interface. This is a great way to interact with Construct from web applications.

The Query Service

The Query Service component is the interface that the framework provides to applications wishing to query the data store. It accepts a String from an application in the form of a SPARQL query and returns a String of results. The application can then decompose the returned String value into the variables that it queried for. Using the in-built Jena reasoner, the Query Service component first infers implicit triples from the data store contents (represented as RDF triples) so that it returns inferred results as well as explicit data to the application.

The Gossipping Service

The implementation of a gossiping algorithm takes the form of a protocol stack with three layers: the data-layer, which exchanges RDF with the data-manager; the gossiping layer, which drives the process; and the network layer which encapsulates the actual sending and receiving of raw packets of bytes.

The gossiping subsystem can be further decomposed into three components: the core gossiping protocol, the message buffer, and the peer membership manager. The core gossiping protocol is stateless. Gossiping is initiated periodically at each peer by sending their message buffer summary to a randomly selected peer from their contact list. When messages arrive they are identified and processed by type. The gossiping layer handles three types of messages: data messages, message buffer summaries, and individual message requests. Data messages are stored in the message buffer for future gossiping then passed up the protocol stack to the data-manager. Message buffer summaries contain a list of the message IDs present in the remote node’s buffer. On comparison with the local message buffer requests for messages that are not held locally are generated. These requests are fulfilled by return.

[adapted from posts by Graeme and Lorcan]

Bookmark and Share
[del.icio.us] [Digg] [Google] [StumbleUpon] [Windows Live] [Yahoo!] [Email] More »
Powered by Bookmarkify™