Personal tools
You are here: Home / Eagle / Core Components

Core Components

We will use the term "components" rather than "services", to enforce the idea that the system parts are re-usable and exchangeable.

Content Management

We will use Plone as the reference content management system, although all information modeling will be done in OWL and RDF so that any other system may be used in preference.  We will augment Plone with open source products (either existing or of our own making) as necessary to implement the core standards:

  • A SPARQL interface to the Plone catalog, allowing authorized search and access to content metadata.  All object identifiers are naturally given as absolute URLs.
  • SPARQL as a first class query language available to Zope/Plone products, in a similar fashion to ZSQL methods.
  • A range of content types for declaring local or remote ontologies, services, generic RDF instances and a simple method for generating content types from a frame based view of OWL ontologies.
  • Make the RDF graph representation available to Zope Page Templates (e.g. RDF Grabber).

User Management

We will use OpenLDAP to store users and user information, which again will be based on concrete ontologies.  As well as the standard LDAP interface, a SPARQL interface will be implemented using e.g. Virtuosso or Squirrel RDF.

Distributed SPARQL

An implementation of a SPARQL gateway which offers up a SPARQL endpoint which uses ontology driven (semantic) query interpretation to deconstruct and cascade SPARQL queries to automatically discovered SPARQL endpoints.  Current name for this is the Ontology Driven Distributed SPARQL component: ODDS.

Browser Client

We will implement an AJAX style ontology and instance browser which will use all of the above components to offer the user an ontology backed interface for searching, browsing and reasoning over distributed heterogeneous information.  The user interface will be hard coded to understand and present only the core OWL concepts and properties to the user in a way that the user will naturally understand them.  Any further hard coding will be done using plugins.  What this means is that the user interface should always be useful as long as there are ontologies describing the underlying information, while further functionality (e.g. maps, images, calendars, etc.) will be made available as plugins which will be coupled with specific ontologies describing their GUI terminology.

Document Actions