Towards a design for RDF, OWL, and SPARQL ontology and presentation in a Liferay web portal

In consideration of methodologies in which the Abel NGO ontologies may be well presented in a web based format, I've been considering a few available options, as in increasing order of complexity: OWLDoc, SPARQL + XSLT, or alternately, a concept of developing a portal application for the Liferay web portal framework, namely in its community edition. Considering candidly: (1) That OWLDoc's presentation of annotations onto property assertions, while straightforward, is nonetheless difficult to intuit a meaning of; (2) that SPARQL + XSLT, while novel, might not in intself present a complete solution for the concerns of web-based ontology presentation and editing; (3) that although it may be a rather involving project, to develop a web portal application for Liferay, namely for ontology presentation an edition, that nonetheless I think it is an encouraging project to pursue -- in which context: I've begun designing a web portal application for Liferay, for presentation and editing of ontology data via a Liferay web portal implementation.

My first concern, in that task, has been sketch out a simple API diagram, toward presentation of ontology data objects. This afternoon, I've developed the following UML class diagram as a baseline model for such an API. This is in using Dia, as installed via the Dia Installer [1] In thumbnail, the diagram appears as following - clicking on the graphic object will result in the display of a full-frame view of the item:

I happen to prefer Apache Jena as the OWL API for this application.

I've also sketched out a few "To Do" items for that application, namely:

1. Complete the presentation model -- esssentialy, making JSR286::Resource extensions for modeling of each "first class entity" in the Jena API, then developing one or more presentation models for those Resource objects, as namely would be implemented in a portlet 
2. Develop an integration for Jena SDB onto the Liferay database model. This might require extension of the Liferay service builder API
3. Develop an integration for the ontology data model, onto the Liferay user auth/permissions model. This might require an application, if not a new design of a means for defining access control lists directly onto the ontology data model, then integrating that implementation onto the Liferay user permissions and authorization model. Liferay, itself, would be managing the features of user authentication, in the application
4. As a lowest priority item, develop a means for tracking changes within the ontology data model. This might require a definition of a change management service, with corresponding integration onto the Liferay service builder API.
5. SPARQL integration
• Develop a SPARQL extension onto the Liferay service builder API
• Develop a presentation model for plain RDF data queried via SPARQL. 
• The presentation of the RDF format results of a SPARQL query, when possible, may be informed of additional OWL class and property data, such as would be available via the same SPARQL interface
6. Integration of inference engines onto Apache Jena and Liferay
• Inference service API / service builder integration (new)
• Dashboard configuration item? for installation and configuration of a single inference engine, within a containing Liferay web portal application
• Focus on reasoners implementing a DIG interface, as supported in Apache Jena. Referencing:
• DL Implementation Group (DIG)
• HOWTO use Jena and DIG reasoners
• Apache Jena - Reasoners and rule engines: Jena inference support

The project will be applying the CEL inference engine, in proof of concept.

Simply, I'd thought I should mark those notes out, here, before proceeding. Perhaps those linked resources may be of interest to the reader, as well.

I've thought I might name the project ArgonautKM -- though that, as a software project name, it might seem ambiguous into ArgoUML, as now I notice. The name was inspired by the title of the book, Argonauts of the Western Pacific, a very early work in cultural anthropology. Due to the possible ambiguity with regards to the name of the ArgoUML project, itself, certainly I would wish to choose another name for the project, shortly.

[1] Dia Installer and corresponding dia-installer project at SourceForge.net. See also: Diashapes

Abel NGO Core Entities Ontology 1.0.2 - Role Classes, SPARQL, and SWRL

Summary

The Abel NGO Core Ontologies, as of revision 1.0.2, are now defining a class Role -- dellimited with subclasses, Foundry Role, Leadership Role, and Membership Role -- for purpose of defining concepts of a role as a first-class object, within an ontology data model.  Those classes are defined within the Abel NGO Core Entities ontology (v1.0.2).

An additional ontology is defined, for purpose of reviewing the data model as defined in the Abel  NGO Core Entities ontology: entity-test.rdf (v1.0.2). The following illustrates a SPARQL query conducted onto the data model of entity-test.rdf (v1.0.2)

SPARQL Query

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX ent: <http://abel-ngo.github.io/km/rdf/entity.rdf#>
SELECT  ?entity ?role ?s
  WHERE { ?entity rdf:type ent:Tribe .
          ?entity ent:constRole ?role .
          ?s ent:fulfillsRole ?role .
}

SWRL Rules and Inference

Corresponding to the addition of Role classes to the Abel NGO Core Entities Ontology (v1.0.2), the same ontology now defines a set of deduction rules in SWRL. In summary, onto the namespace of the Abel NGO Core Entities Ontology.

Provided:

• Social Entity A is defined as an instance of Social Entity, or any subclasses thereof.
• Role B is defined as an instance of a class Membership Role, or any subclasses thereof
• Entity C is defined as an instance of Entity, or any subclasses thereof
• Role B is denoted as a role constituted by Entity A  (i.e B constBy A, or conversely: A constRole B)
• Role B is denoted as a role fulfilled by Entity C (i.e B fulfilledBy C, or conversely: C fullfilsRole B)

Due to the definition of the same SWRL deduction rules, it would be inferred:

• Entity C is a member of Social Entity A, i.e C memberOf A

In this model, the concept of a role is defined of a first order class, Role. This may serve to draw a conceptual distinction between entity and role. Furthermore, the construction of the data model, as such, would allow for that a SPARQL query may be constructed so to search for a particular class of role, within the ontology data model.

The matter of the deductive inference onto the memberOf property might be considered as it being a matter intended mostly for convenience in presentation of entities and roles. 

The Abel NGO Core Entities ontology v1.0.2 with its component SWRL rules has been tested in the HermiT 1.3.8 inference engine, in Protege 5.0. The SWRL rules were defined originally with Protege 3.5.