|
CubicWeb BlogNews about the framework and its uses.
|
I attented the conference organised by IRI in a series of conferences about "Muséologie, muséographie et nouvelles formes d’adresse au public" (hashtag #museoweb). This particular occurence was about "Le Web devient audiovisuel" (the web is also audio and video content). Here are a few notes and links we gathered. The event was organised by Alexandre Monnin @aamonnz.
The technologies seen during this conference are often related to semantic web technologies or at least web standards. Some of the visualizations are quite impressive and could mean new uses of the Web and an inspiration for CubicWeb projects.
A few of the people present at the conference will be attending or presenting talks at SemWeb.Pro which will take place in Paris on the 2nd and 3rd of may 2012.
Many desktop applications offer the possibility for the user to
undo the recent changes : a similar undo feature has now been
integrated into the CubicWeb framework.
Because a semantic web application and a common desktop
application are not the same thing at all, especially as far as
undoing is concerned, we will first introduce what is the undo
feature for now.
A CubicWeb application acts upon an Entity-Relationship model,
described by a schema. This ensures some data integrity
properties. It also implies that changes are made by group called transaction : so as to insure the data integrity the transaction is completely applied or none of it is applied.
What may appear as a simple atomic action to a user can actually consist in several actions for the framework. The end-user has no need to know the details of all actions in those transactions. Only the so-called public actions will appear in the description of the an undoable transaction.
Lets take a simple example: posting a "comment" for a blog entry will create the entity itself and the link to the blog entry.
For now there are two ways to access the undo feature when
it has been activated in the instance configuration file with
the option undo-support=yes. Immediately after having done something the undo** link appears in the "creation" message.
Otherwise, one can access at any time the undo-history view
accessible from the start-up page.
This view shows the transactions, and each provides its own
undo link. Only the transactions the user has permissions to
see and undo will be shown.
If the user attempts to undo a transaction which can't be undone or whose undoing fails, then a message will explain the situation and
no partial undoing will be left behind.
The undo feature is functional but the interface and configuration
options are quite limited. One major, planned, improvement would be enable the user to filter which transactions or actions
he sees in the undo-history view. Another critical
improvement would be to selectively enable the undo feature on part of the entity-relationship schema to avoid storing too much
data and reduce the underlying overhead.
Feedback on this undo feature for specific CubicWeb applications is welcome.
More detailed information regarding the undo feature will be published in the CubicWeb book when the patches make it through the review process.
There has been a growing interest in ZMQ in the past months, due to its ability to efficiently deal with message passing, while being light and robust.
We have worked on introducing ZMQ in the CubicWeb framework for various uses :
- As a replacement/alternative to the Pyro source, that is used to connect to distant instances. ZMQ may be used as a lighter and more efficient alternative to Pyro. The main idea here is to use the send_pyobj/recv_pyobj API of PyZMQ (python wrapper of ZMQ) to execute methods on the distant Repository in a totally transparent way for CubicWeb.
- As a JSONServer. Indeed, ZMQ could be used to share data between a server and any requests done through ZMQ. The request is just a string of RQL, and the response is the result set formatted in Json.
- As the building block for a simple notification (publish/subscribe) system between CubicWeb instances. A component can register its interest in a particular topic, and receive a callback whenever a corresponding message is received. At this point, this mechanism is used in CubicWeb to notify other instances that they should invalidate their caches when an entity is deleted.
Cubicweb has had WSGI support for several years, but this support was incomplete.
The WSGI team was in charge of turning WSGI support into a full featured backend that could replace Twisted in real production scenarii.
Because we only had first class support for Twisted, some of the CubicWeb logic related to HTTP handling was implemented on the twisted side with twisted concepts. Our first task was to move this logic in CubicWeb itself. The handling of HTTP status in our response was improved in the process.
Our second task was to focus on the "non-HTTP" part of CubicWeb (because the repository also manages background tasks). The developement mode for WSGI is now able to handle and run such tasks. For this purpose we have begun a process that aims to remove server related code from the repository object.
We also Tested several WSGI middleware. One of the most promising is Firepython, integrating python logging and debugging feature with Firebug. werkzeug debugger seems neat too.
All these improvements open the road to a simple and efficient multi-process architecture in CubicWeb.
One team during the CubicWeb sprint looked at issues around monitoring benchmark values for CubicWeb development. This is a huge task, so we tried to stay focused on a few aspects:
- production reponse times (using tools such as smokeping and munin)
- response times of test executions in continuous integration tests
- response times of test instances runinng in continuous integration
We looked at using cpu.clock() instead of cpu.time() in the xunit files that report test results so as to be a bit more independent of the load of the machine (but subprocesses won't be counted for).
Graphing test times in hudson/jenkins already exists (/job/PROJECT/BUILDID/testReport/history/?) and can also be graphed by TestClass and by individual test. What is missing so far is a specific dashboard were one could select the significant graphs to look at.
By the end of the first day we had a "lorem ipsum" test instance that is created on the fly on each hudson/jenkins build and a jmeter bench running on it, it's results processed by the performance plugin.
By the end of the second day we had some visualisation of existing data collected by apycot using jqplot javascript visulation (cubicweb-jqplot):
By the end of the sprint, we got patches submitted for the following cubes :
- apycot
- cubicweb-jqplot
- the original jqplot library (update : patch accepted a few days later)
On the last hour of the sprint, since we had a "lorem ipsum" test application running each time the tests went through the continuous integration, we hacked up a proof of concept to get automatic screenshots of this temporary test application. So far, we get screenshots for firefox only, but it opens up possibilities for other browsers. Inspiration could be drawn from https://browsershots.org/
With the emergence of the semantic web in the past few years, and the increasing number of high quality open data sets (cf the lod diagram), there is a growing interest in frameworks that allow to store/query/process/mine/visualize large data sets.
We have seen in previous blog posts how CubicWeb may be used as an efficient knowledge management system for various types of data, and how it may be used to perform complex queries. In this post, we will see, using Geonames data, how CubicWeb may perform simple or complex data mining and machine learning procedures on data, using the datamining cube. This cube adds powerful tools to CubicWeb that make it easy to interactively process and visualize datasets.
At this point, it is not meant to be used on massive datasets, for it is not fully optimized yet. If you try to perform a TF-IDF (term frequency–inverse document frequency) with a hierarchical clustering on the full dbpedia abstracts dataset, be prepared to wait. But it is a promising way to enrich the user experience while playing with different datasets, for quick interactive exploratory datamining processing (what I've called the "Data fast-food").
This cube is based on the scikit-learn toolbox that has recently gained a huge popularity in the machine learning and Python community. The release of this cube drastically increases the interest of CubicWeb for data management.
For a given query, similarly to SQL, CubicWeb returns a result set. This result set may be presented by a view to display a table, a map, a graph, etc (see documentation and previous blog posts).
The datamining cube introduces the possibility to process the result set before presenting it, for example to apply machine learning algorithms to cluster the data.
The datamining cube is based on two concepts:
- the concept of processor: basically, a processor transforms a result set in a numpy array, given some criteria defining the mathematical processing, and the columns/rows of the result set to be taken into account. The numpy-array is a polyvalent structure that is widely used for numerical computation. This array could thus be efficiently used with any kind of datamining algorithms. Note that, in our context of knowledge management, it is more convenient to return a numpy array with additional meta-information, such as indices or labels, the result being stored in what we call a cw-array. Meta-information may be useful for display, but is not compulsory.
- the concept of array-view: the "views" are basic components of CubicWeb, distinguish querying and displaying the data is key in this framework. So, on a given result set, many different views can be applied. In the datamining cube, we simply overload the basic view of CubicWeb, so that it works with cw-array instead of result sets. These array-views are associated to some machine learning or datamining processes. For example, one can apply the k-means (clustering process) view on a given cw-array.
A very important feature is that the processor and the array-view are called directly through the URL using the two related parameters arid (for ARray ID) and vid (for View ID, standard in CubicWeb).
We give some examples of basic processors that may be found in the datamining cube:
- AttributesAsFloatArrayProcessor (arid='attr-asfloat'): This processor turns all Int, BigInt and Float attributes in the result set to floats, and returns the corresponding array. The number of rows is equal to the number of rows in the result set, and the number of columns is equal to the number of convertible attributes in the result set.
- EntityAsFloatArrayProcessor (arid='entity-asfloat'): This processor performs similarly to the AttributesAsFloatArrayProcessor, but keeps the reference to the entities used to create the numpy-array. Thus, this information could be used for display (map, label, ...).
- AttributesAsTokenArrayProcessor (arid='attr-astoken'): This processor turns all String attributes in the result set in a numpy array, based on a Word-n-gram analyze. This may be used to tokenize a set of strings.
- PivotTableCountArrayProcessor (arid='pivot-table-count'): This processor is used to create a pivot table, with a count function. Other functions, such as sum or product also exist. This may be used to create some spreadsheet-like views.
- UndirectedRelationArrayProcessor (arid='undirected-rel'): This processor creates a binary numpy array of dimension (nb_entities, nb_entities), that represents the relations (or corelations) between entities. This may be used for graph-based vizualisation.
We are also planning to extend the concept of processor to sparse matrix (scipy.sparse), in order to deal with very high dimensional data.
The array views that are found in the datamining cube, are, for most of them, used for simple visualization. We used HTML-based templates and the Protovis Javascript Library.
We will not detail all the views, but rather show some examples. Read the reference documentation for a complete and detailed description.
The request:
Any LO, LA WHERE X latitude LA, NOT X latitude NULL, X longitude LO, NOT X longitude NULL,
X country C, NOT X elevation NULL, C name "France"
that may be translated as:
All couples (latitude, longitude) of the locations in France, with an elevation not null
and, using vid=protovis-hist and arid=attr-asfloat
Using the notion of view, we can display differently the same result set, for example using a scatter plot (vid=protovis-scatterplot).
Another example with the request:
Any P, E WHERE X is Location, X elevation E, X elevation >1, X population P,
X population >10, X country CO, CO name "France"
that may be translated as:
All couples (population, elevation) of locations in France,
with a population higher than 10 (inhabitants),and an elevation higher than 1 (meter)
and, using the same vid (vid=protovis-scatterplot) and the same arid (arid=attr-asfloat)
If a third column is given in the result set (and thus in the numpy array), it will be encoded in the size/color of each dot of the scatter plot. For example with the request:
Any LO, LA, E WHERE X latitude LA, NOT X latitude NULL, X longitude LO, NOT X longitude NULL,
X country C, NOT X elevation NULL, X elevation E, C name "France"
that may be translated as:
All tuples (latitude, longitude, elevation) of the locations in France, with an elevation not null
and, using the same vid (vid=protovis-scatterplot) and the same arid (arid=attr-asfloat), we can visualize the elevation on a map, encoded in size/color
Another example with the request:
Any LO, LA LIMIT 50000 WHERE X is Location, X population >1000, X latitude LA, X longitude LO,
X country CO, CO name "France"
that may be translated as:
All couples (latitude, longitude) of 50000 locations in France, with a population higher than 100 (inhabitants)
There also exist some AreaChart view, LineArray view, ...
The request:
Any X,Y WHERE X continent CO, CO name "North America", X neighbour_of Y
that may be translated as:
All neighbour countries in North America
and using the vid='protovis-binarymap' and arid='undirected-rel'
If we do not want a symmetric matrix, i.e. if we want to keep the direction of a link (X,Y is not the same relation as Y,X), we can use the directed*rel array processor. For example, with the following request:
Any X,Y LIMIT 20 WHERE X continent Y
that may be translated as:
20 countries and their continent
and using the vid='protovis-binarymap' and arid='directed-rel'
For a dynamic representation of relations, we can use a force directed graph.
The request:
Any X,Y WHERE X neighbour_of Y
that may be translated as:
All neighbour countries in the World.
and using the vid='protovis-forcedirected' and arid='undirected-rel', we can see the full graph, with small independent components (e.g. UK and Ireland)
Again, a third column in the result set could be used to encode some labeling information, for example the continent.
The request:
Any X,Y,CO WHERE X neighbour_of Y, X continent CO
that may be translated as:
All neighbour countries in the World, and their corresponding continent.
and again, using the vid='protovis-forcedirected' and arid='undirected-rel', we can see the full graph with the continents encoded in color (Americas in green, Africa in dark blue, ...)
For hierarchical information, one can use the Dendrogram view. For example, with the request:
Any X,Y WHERE X continent Y
that may be translated as:
All couple (country, continent) in the World
and using vid='protovis-dendrogram' and arid='directed-rel', we have the following dendrogram (we only show a part due to lack of space)
We have also developed some machine learning view for unsupervised learning. This is more a proof of concept than a fully optimized development, but we can already do some cool stuff. Each machine learning processing is referenced by a mlid. For example, with the request:
Any LO, LA WHERE X is Location, X elevation E, X elevation >1, X latitude LA, X longitude LO,
X country CO, CO name "France"
that may be translated as:
All couples (latitude, longitude) of the locations in France, with an elevation higher than 1
and using vid='protovis-scatterplot' arid='attr-asfloat' and mlid='kmeans', we can construct a scatter plot of all couples of latitude and longitude in France, and create 10 clusters using the kmeans clustering. The labeling information is thus encoded in color/size:
Finally, we have also implement a download view, based on the Pickle of the numpy-array. It is thus possible to access remotely any data within a Python shell, allowing to process them as you want. Changing the request can be done very easily by changing the rql parameter in the URL. For example:
import pickle, urllib
data = pickle.loads(urllib.open('http://mydomain?rql=my request&vid=array-numpy&arid=attr-asfloat'))
To be decided. Some possible topics are :
- optimization (still)
- porting cubicweb to python3
- porting cubicweb to pypy
- persistent sessions
- finish twisted / wsgi refactoring
- inter-instance communication bus
- use subprocesses to handle datafeeds
- developing more debug-tools (debug console, view profiling, etc.)
- pluggable / unpluggable external sources (as needed for the cubipedia and semantic family)
- client-side only applications (javascript + http)
- mercurial storage backend: see this thread of the mailing list
- mercurial-server integration: see this email to the mailing list
other ideas are welcome, please bring them up on cubicweb@lists.cubicweb.org
This sprint will take place from in february 2012 from tuesday the 7th to friday the 10th. You are more than welcome to come along, help out and contribute. An introduction is planned for newcomers.
Network resources will be available for those bringing laptops.
Address : 104 Boulevard Auguste-Blanqui, Paris. Ring "Logilab" (googlemap)
Metro : Glacière
Contact : http://www.logilab.fr/contact
Dates : 07/02/2012 to 10/02/2012
CubicWeb is a semantic web framework written in Python that has been succesfully used in large-scale projects, such as data.bnf.fr (French National Library's opendata) or Collections des musées de Haute-Normandie (museums of Haute-Normandie).
CubicWeb provides a high-level query language, called RQL, operating over a relational database (PostgreSQL in our case), and allows to quickly instantiate an entity-relationship data-model. By separating in two distinct steps the query and the display of data, it provides powerful means for data retrieval and processing.
In this blog, we will demonstrate some of these capabilities on the Geonames data.
Geonames is an open-source compilation of geographical data from various sources:
"...The GeoNames geographical database covers all countries and contains over eight million placenames that are available for download free of charge..." (http://www.geonames.org)
The data is available as a dump containing different CSV files:
- allCountries: main file containing information about 8,000,000 places in the world. We won't detail the various attributes of each location, but we will focus on some important properties, such as population and elevation. Moreover, admin_code_1 and admin_code_2 will be used to link the different locations to the corresponding AdministrativeRegion, and feature_code will be used to link the data to the corresponding type.
- admin1CodesASCII.txt and admin2Codes.txt detail the different administrative regions, that are parts of the world such as region (Ile-de-France), department (Department of Yvelines), US counties...
- featureCodes.txt details the different types of location that may be found in the data, such as forest(s), first-order administrative division, aqueduct, research institute, ...
- timeZones.txt, countryInfo.txt, iso-languagecodes.txt are additional files prodividing information about timezones, countries and languages. They will be included in our CubicWeb database but won't be explained in more details here.
The Geonames website also provides some ways to browse the data: by Countries, by Largest Cities, by Highest mountains, by postal codes, etc. We will see that CubicWeb could be used to automatically create such ways of browsing data while allowing far deeper queries.
There are two main challenges when dealing with such data:
- the number of entries: with 8,000,000 placenames, we have to use efficient tools for storing and querying them.
- the structure of the data: the different types of entries are separated in different files, but should be merged for efficient queries (i.e. we have to rebuild the different links between entities, e.g Location to Country or Location to AdministrativeRegion).
With CubicWeb, the data model of the application is written in Python. It defines different entity classes with their attributes, as well as the relationships between the different entity classes. Here is a sample of the schema.py that we have used for Geonames data:
class Location(EntityType):
name = String(maxsize=1024, indexed=True)
uri = String(unique=True, indexed=True)
geonameid = Int(indexed=True)
latitude = Float(indexed=True)
longitude = Float(indexed=True)
feature_code = SubjectRelation('FeatureCode', cardinality='?*', inlined=True)
country = SubjectRelation('Country', cardinality='?*', inlined=True)
main_administrative_region = SubjectRelation('AdministrativeRegion',
cardinality='?*', inlined=True)
timezone = SubjectRelation('TimeZone', cardinality='?*', inlined=True)
...
This indicates that the main Location class has a name attribute (string), an uri (string), a geonameid (integer), a latitude and a longitude (both floats), and some relation to other entity classes such as FeatureCode (the relation is named feature_code), Country (the relation is named country), or AdministrativeRegion called main_administrative_region.
The cardinality of each relation is classically defined in a similar way as RDBMS, where * means any number, ? means zero or one and 1 means one and only one.
We give below a visualisation of the schema (obtained using the /schema relative url)
The data contained in the CSV files could be pushed and stored without any processing, but it is interesting to reconstruct the relations that may exist between different entities and entity classes, so that queries will be easier and faster.
Executing the import procedure took us 80 minutes on regular hardware, which seems very reasonable given the amount of data (~7,000,000 entities, 920MB for the allCountries.txt file), and the fact that we are also constructing many indexes (on attributes or on relations) to improve the queries. This import procedure uses some low-level SQL commands to load the data into the underlying relational database.
As stated before, queries are performed in CubicWeb using RQL (Relational Query Language), which is similar to SPARQL, but with a syntax that is closer to SQL. This language may be used to query directly the concepts while abstracting the physical structure of the underlying database. For example, one can use the following request:
Any X LIMIT 10 WHERE X is Location, X population > 1000000,
X country C, C name "France"
that means:
Give me 10 locations that have a population greater than 1000000, and that are in a country named "France"
The corresponding SQL query is:
SELECT _X.cw_eid FROM cw_Country AS _C, cw_Location AS _X
WHERE _X.cw_population>1000000
AND _X.cw_country=_C.cw_eid AND _C.cw_name="France"
LIMIT 10
We can see that RQL is higher-level than SQL and abstracts the details of the tables and the joins.
A query returns a result set (a list of results), that can be displayed using views. A main feature of CubicWeb is to separate the two steps of querying the data and displaying the results. One can query some data and visualize the results in the standard web framework, download them in different formats (JSON, RDF, CSV,...), or display them in some specific view developed in Python.
In particular, we will use the mapstraction.map which is based on the Mapstraction and the OpenLayers libraries to display information on maps using data from OpenStreetMap. This mapstraction.map view uses a feature of CubicWeb called adapter. An adapter adapts a class of entity to some interface, hence views can rely on interfaces instead of types and be able to display entities with different attributes and relations. In our case, the IGeocodableAdapter returns a latitude and a longitude for a given class of entity (here, the mapping is trivial, but there are more complex cases... :) ):
class IGeocodableAdapter(EntityAdapter):
__regid__ = 'IGeocodable'
__select__ = is_instance('Location')
@property
def latitude(self):
return self.entity.latitude
@property
def longitude(self):
return self.entity.longitude
We will give some results of queries and views later. It is important to notice that the following screenshoots are taken without any modification of the standard web interface of CubicWeb. It is possible to write specific views and to define a specific CSS, but we only wanted to show how CubicWeb could handle such data. However, the default web template of CubicWeb is sufficient for what we want to do, as it dynamically creates web pages showing attributes and relations, as well as some specific forms and javascript applets adapted directly to the data (e.g. map-based tools).
Last but not least, the query and the view could be defined within the url, and thus open a world of new possibilities to the user:
http://baseurl:port/?rql=The query that I want&vid=Identifier-of-the-view
We will not get into too much details about Facets, but let's just say that this feature may be used to determine some filtering axis on the data, and thus may be used to post-filter a result set. In this example, we have defined four different facets: on the population, on the elevation, one the feature_code and one the main_administrative_region. We will see illustration of these facets below.
We give here an example of the definition of a Facet:
class LocationPopulationFacet(facet.RangeFacet):
__regid__ = 'population-facet'
__select__ = is_instance('Location')
order = 2
rtype = 'population'
where __select__ defines which class(es) of entities are targeted by this facet, order defines the order of display of the different facets, and rtype defines the target attribute/relation that will be used for filtering.
The main page of the Geoname application is illustrated in the screenshot below. It provides general information on the database, in particular the number of entities in the different classes:
- 7,984,330 locations.
- 59,201 administrative regions (e.g. regions, counties, departments...)
- 7,766 languages.
- 656 features (e.g. types of location).
- 410 time zones.
- 252 countries.
- 7 continents.
We will first illustrate the possibilites of CubicWeb with the simple query that we have detailed before (that could be directly pasted in the url...):
Any X LIMIT 10 WHERE X is Location, X population > 1000000,
X country C, C name "France"
We obtain the following page:
This is the standard view of CubicWeb for displaying results. We can see (right box) that we obtain 10 locations that are indeed located in France, with a population of more than 1,000,000 inhabitants. The left box shows the search panel that could be used to launch queries, and the facet filters that may be used for filtering results, e.g. we may ask to keep only results with a population greater than 4,767,709 inhabitants within the previous results:
and we obtain now only 4 results. We can also notice that the facets are linked: by restricting the result set using the population facet, the other facets also restricted their possibilities.
Let's say that we now want more information about the results that we have obtained previously (for example the exact population, the elevation and the name). This is really simple ! We just have to ask within the RQL query what we want (of course, the names N, P, E of the variables could be almost anything...):
Any N, P, E LIMIT 10 WHERE X is Location,
X population P, X population > 1000000,
X elevation E, X name N, X country C, C name "France"
The empty column for the elevation simply means that we don't have any information about elevation.
Anyway, we can see that fetching particular information could not be simpler! Indeed, with more complex queries, we can access countless information from the Geonames database:
Any N,E,LA,LO ORDERBY E DESC LIMIT 10 WHERE X is Location,
X latitude LA, X longitude LO,
X elevation E, NOT X elevation NULL, X name N,
X country C, C name "France"
which means:
Give me the 10 highest locations (the 10 first when sorting by decreasing elevation) with their name, elevation, latitude and longitude that are in a country named "France"
We can now use another view on the same request, e.g. on a map (view mapstraction.map):
Any X ORDERBY E DESC LIMIT 10 WHERE X is Location,
X latitude LA, X longitude LO, X elevation E,
NOT X elevation NULL, X country C, C name "France"
And now, we can add the fact that we want more results (20), and that the location should have a non-null population:
Any N, E, P, LA, LO ORDERBY E DESC LIMIT 20 WHERE X is Location,
X latitude LA, X longitude LO,
X elevation E, NOT X elevation NULL, X population P,
X population > 0, X name N, X country C, C name "France"
... and on a map ...
In this blog, we have seen how CubicWeb could be used to store and query complex data, while providing (among other...) Web-based views for data vizualisation. It allows the user to directly query data within the URL and may be used to interact with and explore the data in depth. In a next blog, we will give more complex queries to show the full possibilities of the system.
Data.gouv.fr is great news for the OpenData movement!
Two days ago, the French government released thousands of data sets on http://data.gouv.fr/ under an open licensing scheme that allows people to access and play with them. Thanks to the CubicWeb semantic web framework, it took us only a couple hours to put some of that open data to good use. Here is how we mapped the french railway system.
We used two of the datasets available on data.gouv.fr:
Train stations : description of the 6442 train stations in France, including their name, type and geographic coordinates.
Here is a sample of the file
441000;St-Germain-sur-Ille;Desserte Voyageur;48,23955;-1,65358
441000;Montreuil-sur-Ille;Desserte Voyageur-Infrastructure;48,3072;-1,6741
LevelCrossings : description of the 18159 level crossings on french railways, including their type and location.
Here is a sample of the file
558000;PN privé pour voitures avec barrières sans passage piétons accolé;48,05865;1,60697
395000;PN privé pour voitures avec barrières avec passage piétons accolé public;;48,82544;1,65795
Given the above datasets, we wrote the following data model to store the data in CubicWeb:
class Location(EntityType):
name = String(indexed=True)
latitude = Float(indexed=True)
longitude = Float(indexed=True)
feature_type = SubjectRelation('FeatureType', cardinality='?*')
data_source = SubjectRelation('DataGovSource', cardinality='1*', inlined=True)
class FeatureType(EntityType):
name = String(indexed=True)
class DataGovSource(EntityType):
name = String(indexed=True)
description = String()
uri = String(indexed=True)
icon = String()
The Location object is used for both train stations and level crossings. It has a name (text information), a latitude and a longitude (numeric information), it can be linked to multiple FeatureType objects and to a DataGovSource. The FeatureType object is used to store the type of train station or level crossing and is defined by a name (text information). The DataGovSource object is defined by a name, a description and a uri used to link back to the source data on data.gouv.fr.
We had to write a few lines of code to benefit from the massive data import feature of CubicWeb before we could load the content of the CSV files with a single command:
$ cubicweb-ctl import-datagov-location datagov_geo gare.csv-fr.CSV --source-type=gare
$ cubicweb-ctl import-datagov-location datagov_geo passage_a_niveau.csv-fr.CSV --source-type=passage
In less than a minute, the import was completed and we had:
- 2 DataGovSource objects, corresponding to the two data sets,
- 24 FeatureType objects, corresponding to the different types of locations that exist (e.g. Non exploitée, Desserte Voyageur, PN public isolé pour piétons avec portillons or PN public pour voitures avec barrières gardé avec passage piétons accolé manoeuvré à distance),
- 24601 Locations, corresponding to the different train stations and level crossings.
CubicWeb allows to build complex applications by assembling existing components (called cubes). Here we used a cube that
wraps the Mapstraction and the OpenLayers libraries to display information on maps using data from OpenStreetMap.
In order for the Location type defined in the data model to be displayable on a map, it is sufficient to write the following adapter:
class IGeocodableAdapter(EntityAdapter):
__regid__ = 'IGeocodable'
__select__ = is_instance('Location')
@property
def latitude(self):
return self.entity.latitude
@property
def longitude(self):
return self.entity.longitude
That was it for the development part! The next step was to use the application to browse the structure of the french train network on the map.
Train stations in use:
Train stations not in use:
Zooming on some parts of the map, for example Brittany, we get to see more details and clicking on the train icons gives more information on the corresponding Location.
Train stations in use:
Train stations not in use:
Since CubicWeb separates querying the data and displaying the result of a query, we can switch the view to display the same data in tables or to export it back to a CSV file.
CubicWeb implements a query langage very similar to SPARQL, that makes the data available without the need to learn a specific API.
Example 1: http:/some.url.demo/?rql=Any X WHERE X is Location, X name LIKE "%miny"
This request gives all the Location with a name that ends with "miny". It returns only one element, the Firminy train station.
Example 2: http:/some.url.demo/?rql=Any X WHERE X is Location, X name LIKE "%ny"
This request gives all the Location with a name that ends with "ny", and return 112 trainstations.
Example 3: http:/some.url.demo/?rql=Any X WHERE X latitude < 47.8, X latitude>47.6, X longitude >-1.9, X longitude<-1.8
This request gives all the Location that have a latitude between 47.6 and 47.8, and a longitude between -1.9 and -1.8.
We obtain 11 Location (9 levelcrossings and 2 trainstations). We can map them using the view mapstraction.map that we describe previously.
Example 4: http:/domainname:8080/?rql=Any X WHERE X latitude < 47.8, X latitude>47.6, X longitude >-1.9, X longitude<-1.8, X feature_type F, F name "Desserte Voyageur"
Will limit the previous results set to train stations that are used for passenger service:
Example 5: http:/domainname:8080/?rql=Any X WHERE X feature_type F, F name "PN public pour voitures sans barrières sans SAL"&vid=mapstraction.map
Finally, one can map all the level crossings for vehicules without barriers (there are 3704):
As you could see in the last URL, the map view was chosen directly with the parameter vid, meaning that the URL is shareable and can be easily included in a blog with a iframe for example.
The result of a query can also be "displayed" in RDF, thus allowing users to download a semantic version of the information,
without having to do the preprocessing themselves:
<rdf:Description rdf:about="cwuri24684b3a955d4bb8830b50b4e7521450">
<rdf:type rdf:resource="http://ns.cubicweb.org/cubicweb/0.0/Location"/>
<cw:cw_source rdf:resource="http://some.url.demo/"/>
<cw:longitude rdf:datatype="http://www.w3.org/2001/XMLSchema#float">-1.89599</cw:longitude>
<cw:latitude rdf:datatype="http://www.w3.org/2001/XMLSchema#float">47.67778</cw:latitude>
<cw:feature_type rdf:resource="http://some.url.demo/7222"/>
<cw:data_source rdf:resource="http://some.url.demo/7206"/>
</rdf:Description>
For someone who knows the CubicWeb framework, a couple hours are enough to create a CubicWeb application that stores,
displays, queries and shares data downloaded from http://www.data.gouv.fr/
The full source code for the above will be released before the end of the week.
If you want to see more of CubicWeb in action, browse http://data.bnf.fr or learn how to develop your own application at http://docs.cubicweb.org/
CubicWeb 3.13 has been developed for a while and includes some cool
stuff:
- generate and handle Apache's modconcat compatible URLs, to minimize the number
of HTTP requests necessary to retrieve JS and CSS files, along with a new
cubicweb-ctl command to generate a static 'data' directory that can be served
by a front-end instead of CubicWeb
- major facet enhancements:
- nicer layout and visual feedback when filtering is in-progress
- new RQLPathFacet to easily express new filters that are more than one hop
away from the filtered entities
- a more flexibile API, usable in cases where it wasn't previously possible
- some form handling refactorings and cleanups, notably introduction of a new
method to process posted content, and updated documentation
- support for new base types : BigInt, TZDateTime and TZTime (in 3.12 actually for those two)
- write queries optimization, and several RQL fixes on complex queries
(e.g. using HAVING, sub-queries...), as well as new support for CAST() function
and REGEXP operator
- datafeed source and default CubicWeb xml parsers:
- refactored into smaller and overridable chunks
- easier to configure
- make it work
As usual, the 3.13 also includes a bunch of other minor enhancements,
refactorings and bug fixes. Please download and install CubicWeb 3.13 and report
any problem on the tracker and/or the mailing-list!
Enjoy!
|