Skip to end of metadata
Go to start of metadata

RS-1277

Intro

Callimachus is an RDF based web application framework by 3 Round Stones (3RS) and Talis.

  • 3RS is a small US company that we've had a lot of interaction with
  • a large Ontotext client (AstraZeneca) has asked us to look into integrating Callimachus with our stuff, see Trying it Out

I looked at Callimachus on 3-4 Dec 2012:

  • read the website, watched the video tutorial, read the wiki (4h)
  • read the source of the sample apps (4h)
  • downloaded the source of the framework and browsed (4h)
  • read about AliBaba (2h)

General Info

Sample apps:

Technologies Used

  • Sesame AliBaba 2.0-rc7 (Elmo) for RDF-Java mapping. Includes features:
    • Object Repository wrapper for storing java objects (through)
    • Auditing Repository wrapper to track and record changes (provenance)
    • Optimistic Repository wrapper to improve the performance of small write operations by supporting concurrent write transactions
    • Messaging (msg ontology) for servicing requests (HTTP and internal)
      Eg http://dir.w3.org/rdf/2012/directory/directory-data.rdf is implemented as a SPARQL query in directory-data.ttl:
      :DumpDirectory rdfs:subClassOf msg:Message;
         rdfs:subClassOf [owl:onProperty msg:target; owl:hasValue <directory-data.rdf> ];
         rdfs:subClassOf [owl:onProperty msg:object; owl:allValuesFrom <java:org.openrdf.model.Model> ];
         calli:method "GET";
         calli:requires calli:reader;
         calli:type "application/rdf+xml";
         calli:header "cache-control:no-validate";
         calli:header "cache-control:max-age=3600";
         calli:header "content-disposition:inline;filename=\"directory-data.rdf\"";
         msg:sparql """
          prefix vcard: <http://www.w3.org/2006/vcard/ns#>
          prefix foaf: <http://xmlns.com/foaf/0.1/>
          prefix gr:<http://purl.org/goodrelations/v1#>
          CONSTRUCT {
            ?org a vcard:Organization.
            ?org a vcard:Organization; a gr:BusinessEntity.
            ?org a vcard:Organization; a vcard:VCard.
            ?org a vcard:Organization; gr:legalName ?legalName.
            ...
          } """.
      
  • Sesame, OWLIM or Mulgara as RDF backends
    • But many RDF are stored as files.
  • XProc (XML pipelining) through the Calabash 1.0.3 implementation
  • Jetty as HTTP server
  • RDFa in form markup (see below)
  • Unit tests (junit), including UI testing through Selenium
  • Can be deployed on Amazon EC2 and RackSpace
  • DocBook for rich text markup

Source Code

Current versions:

  • callimachus-1.0-alpha-1.zip (2 Dec 2012)
  • callimachus-0.18.zip (28 Nov 2012)

Pros

  • Good structuring of the web app into various resources (see this image for more):
    • Folders: correlated with "container resources"
    • Pages/Templates (xhtml): views for create, view, edit.
      • Use HTML5, eg <aside> element for showing things in a right column, drag & drop for adding a related resource.
      • Use RDFa for both rendering data and binding form fields to data. Extends RDFa with variables (eg "?note") and expressions (eg {rdfs:label}). Iterates HTML elements over multivalue properties.
    • Named Queries (rq): SPARQL queries that are directly requestable with a URL.
      Dataset format is compatible with Google Query and Google Charts JS libraries.
      Allow external parameters through various syntaxes:
      • Wild: optional URI (in angle brackets) or literal (in quotes)
      • Relative: required URI (no brackets)
      • Lexical: required literal (no quotes)
      • Expression:
    • menus (ttl): decribe the structure of menus and the links that are invoked
    • Service Descriptions (Messages) (ttl): describe various served requests, and how to serve them
    • XProc pipelines (xpl)
    • images (.ico, png)
    • RDF data (eg Concepts, which are used to populate lookup lists)
    • rich text (.docbook): produced with a simple stock HTML RTF editor, saved in DocBook XML
  • Each resource has a single URL that's used to render it as HTML or RDF using content negotiation
    • Uses REST
    • Implements PURLs: used to hide "URL implementation details" and control caching
    • Tabs (operations) for each resource: view, edit, discuss, describe
  • The app is bound together using RDF (application metadata)
  • Automatic generation of URIs through:
    • a concept of container (nested) resources through calli:hasComponent
    • generation of local part from the "first" (key) property of each resource.
    • Eg a Note with rdfs:label="2012-12-05" in a Journal with rdfs:label="R&D" will get URI:
      journals/R&D/2012-12-05
  • Security/authorisation by assigning user/group properties to every resource.
    Supports various roles (reader, subscriber, author, editor, administrator)

Cons

  • No generation of forms. Creating the views is very tedious (see [video tutorial]).
    • No reuse (lots of duplication) between Create and Edit views.
    • Little reuse re common elements of forms (but this is allevaited
    • Compared to Semantic Forms and Automatic Semantic Forms of SMW, that's a significant disadvantage
  • The persistence approach may be too restrictive:
    • Vaso: AliBaba fixes cardinality assumptions in your Java classes (eg whether a member is a scalar or Set). If you get "random" data from an external source (like a lot of the LLD data is), this causes runtime exceptions
    • Ilia: SAS uses Empire, which is a JPA implementation. Its major feature missing from AliBaba is lazy loading of sub-objects. Vlado: this seems essential for a graph data model
  • No developer documentation.
    • There is documentation for the creator of Callimachus apps (http://code.google.com/p/callimachus/w/list) but none if you want to change/extend the framework.
    • That doesn't mean just the Java code, but the whole framework model (the details of how RDF data binds the whole system).
      Eg consider these questions on Service Patterns (I know that's now replaced with xpl but...):
      • what's a SchemaGraph
      • Messaging interprets this owl:hasValue restriction to bind the message handler to that target.
        :DownloadCSV rdfs:subClassOf msg:Message;
           rdfs:subClassOf [owl:onProperty msg:target; owl:hasValue </download_csv> ];
        

        Similarly for owl:allValuesFrom, it binds the message handler to all reasources of the given class

      • why both steps of the pipeline (:DownloadCSV and :TransformIntoCSV) repeat the same msg:target and msg:object
      • Messaging declares extra message parameters as FunctionalProperties. So :TransformIntoCSV has parameter :sparqlResult that it gets from the previous step:
        :sparqlResult a owl:ObjectProperty; a owl:FunctionalProperty;
           rdfs:domain :TransformIntoCSV;
           rdfs:range <java:java.io.InputStream>;
           calli:type "application/sparql-results+xml".
        
  • (minor) perhaps storing more of the system Turtle files in the repo can speed up things.
    However, it'll be harder to edit them

Conclusions

Some sort of conclusions for RS:

  • Callimachus seems less relevant to RS than SMW because it cannot generate forms
  • We can learn a lot from it about:
    • Java-RDF persistance (AliBaba)
    • Implementing REST services through RDF configuration
    • structuring the application

Trying it Out

Our LifeSci group is trying Callimachus out. Track this task:
SALE-370
Setup a demo installation of Callimachus with OWLIM backend

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.