NetworkedPlanet Blog » Theory and Practice

SDShare Presentation

Graham Moore — Fri, 16 Dec 2011 08:32:11 +0000

I recently gave a presentation on the SDShare protocol. The slides from that presentation can now be downloaded.

LOS on data.networkedplanet.com

Graham Moore — Thu, 03 Mar 2011 08:41:25 +0000

The service at data.norge.no provides metadata about data sets that are published by a variety of organisations and aims to facilitate the sharing and reuse of data and vocabularies. The service at data.norge.no is very well put together allowing developers and organisations to find out about data sets that may be of use to them. However, the quality and way in which the organisations listed expose the actual data sets could be better and doesn’t make it easy for third parties to utilise the data.

Consider the LOS hierarchy for example. This simple hierarchy of concepts and topics is described at data.norge.no and the actual data set resides at difi.org. The LOS hierarchy is category scheme and suggested navigation structure for local government in Norway. The data, sadly, is published as an open document format spreadsheet file.

So, with data.networkedplanet.com and the Web3 Platform we have tried to demonstrate how organisations should publish data for it to be useful and easy for others to work with. To accompany the service we describe the key principles that have guided us.

1) Give unique persistent identifiers in the form or URLs to the terms in a vocabulary or ontology. E.g. http://data.networkedplanet.com/difi/los/themes/Arbeid. Is the immutable URI we have assigned to the concept for ‘work’ in the theme hierarchy.

2) Have human and machine representations for all the ‘things’ being published. Again consider the Arbied concept in Los. If developers creating mashups want to make use of the term in an application why would they want to create and store and manage a static copy when it is intended to be a common data set? At data.networkedplanet.com using the Web3 Platform we expose both human and machine representations of all concepts. See http://data.networkedplanet.com/difi/los/themes/Arbeid?format=rdf for the data representation of the Arbied/Work concept.

3) Make the data searchable. Developers and other users (CMS editors perhaps) want to know if certain terms exist. Exposing a full text concept search allows them to find the concepts that are interesting to them.

4) Make the data queryable. Full text search is useful for looking up, or checking that a given term is there. But structured data queries are what developers need to be able to best make use of the data. The Web3 Platform allows SPARQL queries to be run to explore and query the data. To see a list of all themes in LOS the follow URL encoded query can be used …

data.norge.no provides a great hub to discover data sets published by different organisations, but the value of the data they publish is only as good as the tools they offer to users to make use of that data. Networked Planet’s Web3 Platform allows organisations to quickly and easily publishing Linked Open Data in a way that is robust, long lasting and provides developers with data the way they want it.

Networked Planet Linked Data Article

Graham Moore — Tue, 01 Mar 2011 07:24:16 +0000

A recent article about Linked Data has been published at Business Computing World.

REST in the Web3 Platform

Graham Moore — Fri, 24 Sep 2010 07:16:59 +0000

One of the goals of the Web3 Platform was to adhere to as many of the architectural principles of REST that was possible. In our minds the key things were that:

1) Given a start URI and a description of all the content types and valid transitions a client could interact with the topic map store.

Yep, there is only that one point.

Given the URI of a topic map a client that is aware of the different content types that can be returned can interact with the entire topic map without guessing at, or constructing URIs.

For the Web3 Platform we introduced a new syntactic representation for Topic Maps because XTM is an interchange syntax for Topic Maps and not an effective Hypertext representation for the TMDM.

I'll walk through some interactions starting from a topicmap URL to demonstrate why we introduced the new syntax and how a client behaves.

Starting with the topicmap URL:

GET http://localhost/web3/topicmaps/e518129d-b458-4171-99cc-5e4941dafc7b?format=xml

When addressing Web3 Resources content negotiation can be done through accept headers or via a format parameter. The above GET returns the following representation.




  
    Films

There are a couple of things to notice in this representation.

We use full URLs for everything, no Ids that need turning into URLs based on some defined URL space.
We are exposing the collections of Topics and Associations as resources in their own right. This allows clients to POST to these collections to create new Topics and Associations and also to fetch these collections. (The full representation documentation also specifies the allowed query parameters for these resources).

Now a client can navigate the topic collection using:

GET http://localhost/web3/topicmaps/e518129d-b458-4171-99cc-5e4941dafc7b/topics?format=xml

This returns the following collection:




  
    
      
        Harrison Ford
      
      
    
    
      
        Witness
      
      
    
    
      
        Star Wars

The interesting things in the snippet above are:

We have introduced a generic list container for topics, in fact topic refs. This gives us control over thing like collection size and paging.
We have introduced a lightweight topic reference structure for use in listing topics. This is a subset of the full topic representation and is used in many places.
We are explicit about the topic's web address.
We provided explicit links to navigate through the collection

All of the above means that a client who understands this content type can navigate to a topic, and find more results or the previous page of results.

Following a link to a topic using:

GET http://localhost/web3/topicmaps/e518129d-b458-4171-99cc-5e4941dafc7b/topics/2a8a2182-f8b7-427a-9f7f-ef206b775606?format=xml

Returns the following XML



  
    Harrison Ford
  
  
  
    
      
        Person
      
      
        

http://localhost/web3/schemas/0df562f3-f86b-4fbb-a4d3-66679f2df0fa/types/16f22191-5fd7-4f15-8014-f4fc28b1563e

        
        

http://www.myfilms.com/types/person

        
      
    
  
  
    
      
        
          Biography
        
        
          

http://www.myfilms.com/types/biography

          
          

http://localhost/web3/schemas/0df562f3-f86b-4fbb-a4d3-66679f2df0fa/types/45ba8b1a-a80c-40c6-8fb6-7d1692c0da7b

          
        
      
      Born in the 1940's

Points of interest in the above snippet are:

The link to the associations for the topic. With this we have created a resource that can be navigated to return the associations in which the topic plays a role. (There are optional query parameters on this as well.)
We use inline topic ref elements to minimise round trips for common things, such as property types and topic types.
All contained resources, property (is name or occurrence) and identity expose their web address.
We have also included version information to help with ETag processing.

Finally, following the associations link using:


http://localhost/web3/topicmaps/e518129d-b458-4171-99cc-5e4941dafc7b/topics/2a8a2182-f8b7-427a-9f7f-ef206b775606/associations?format=xml

We get back the following XML structure:



  
    
      
        
        
          http://psi.topicmaps.org/iso13250/model/type-instance
        
      
      
      
        
          
            
              Harrison Ford
            
            
          
          
            
            
              http://psi.topicmaps.org/iso13250/model/instance
            
          
        
        
          
            
              Person
            
            
              http://localhost/web3/schemas/0df562f3-f86b-4fbb-a4d3-66679f2df0fa/types/16f22191-5fd7-4f15-8014-f4fc28b1563e
              http://www.myfilms.com/types/person
            
          
          
            
            
              http://psi.topicmaps.org/iso13250/model/type

So the key things we wanted to do was to create a set of content types that along with a description allowed a client to interact with a Topic Map without the need to refer to or know how to generate ANY URIs.

The examples above have shown how we have updated the core TMDM items, topic, association, occurrence etc to be better REST citizens, and we have also introduced new resources for collections of things in the topic map model. These collections are key to connecting together the basic topic map building blocks.

The full content type descriptions, including update semantics, are available as part of the Web3 Documentation which can be downloaded from http://www.networkedplanet.com/Products/Web3/

We also recently posted about how we support transactions in a RESTful way. This can be seen here.

Using HTTP Verbs to describe Server Side Transactions

Graham Moore — Fri, 30 Jul 2010 07:21:14 +0000

One of the challenges of putting together a REST service is how to let clients make transactional updates that involve two or more resources. One approach to this problem is to create a resource that is 'a collection of transactions'. A client can post a representation of a new transaction to this resource. The transaction becomes a 'child' of the 'transactions' resource and can be accessed via a returned URL.

Making the transaction explicit is good as it allows the transaction to be addressed and its status checked, it also allows for the service to return immediately and process the transaction in the background.

This basic pattern is good but it has a drawback in that for each different system you build you need to define the transaction language.

Our solution to this is to use HTTP verbs, URIs and resource representations as the building blocks of our transaction language. A transaction representation contains a number of operations. Each operation contains information about its Method, e.g. POST, PUT, DELETE, the resource URI to operate on and the request body.

.. more operations

The server processes a transaction by looking at each operation construct and operating on it as though the request has come from a client. The only difference is that all of the operations listed occur in a single transaction.

Each operation has a local id. When an operation completes the return URL from the operation is bound to that identifier. The identifier can then be used later in the transaction. This is especially useful when you want to create two new resources and then associate them together all in the same transaction.

After a transaction is processed the representation can be retrieved. The representation contains the URLs of newly created resources, as well as an errors information that occurred when processing the transaction.

This is a very powerful model that removes the need to create a domain specific transaction language for different applications, can reuse existing resource processing code and is very descriptive.

For more information about this approach, download and review the REST service documentation for the Web3 Platform

Making Topic Maps SPARQL

Kal — Mon, 09 Nov 2009 15:25:08 +0000

The focus of this article is on the implementation of the SPARQL query language on top of a topic map repository. I'm not going to get down into implementation issues but instead will describe what has motivated this work and the way in which we have addressed the various incompatibilities between the graph-based data model for which SPARQL was designed and the aggregate association model of topic maps.

Motivation and Goals
Approach
Limitations of TMSPARQL
Conclusions
Further Examples

Motivation and Goals

The principle motivation behind this work has been the need for topic maps repositories to be active participants in the Linked Data Web. It is relatively trivial to expose topic map data as RDF but just providing a bunch of addressable RDF resources isn't really enough. A true Linked Data repository really must also support a query interface that allows clients to search and filter the data provided by the repository. It is clear (from even a cursory inspection of the various linked data repositories that exist out there) that SPARQL is the preferred query language for Linked Data clients. Therefore if a topic maps repository is to be a full and useful participant in the Linked Data web it is important that it can provide a SPARQL query service endpoint.

A second, weaker, motivation has been the progress and direction of the ISO TMQL standard. At the time of writing the TMQL standard is still under development and while it is not clear just yet exactly how the query language will look, it is my opinion that the final language will not be palatable to those outside the topic maps community. It is hoped that by providing a SPARQL query implementation on top of a topic maps repository it would be possible to provide a simpler query language that perhaps meets the 80/20 rule leaving the 20% of really heavy lifting in topic maps query to TMQL.

The main goal of this project is to enable the implementation of a SPARQL query endpoint, but it is also important that this should be an endpoint that is usable by any Linked Data client. In particular the SPARQL query endpoint should be queryable by a client that does not know (and does not need to care) that the underlying repository is using topic maps as its core data model rather than RDF. Ideally a client should be able to send the same query to both RDF and Topic Maps based repositories and, assuming there is some consistent mapping of identifiers to resources, retrieve equivalent results. For example, if I have a topic map that stores social network data using the FOAF ontology, it should be possible for a client to query that data using exactly the same SPARQL queries it would use to query an RDF store of FOAF data.

We have called this project TMSPARQL.

Approach

A SPARQL query is expressed as a graph pattern that (in its most basic form) consists of a set of triples where the subject, predicate, or object of those triples may be either an RDF node or a variable. The query result returns the collection of bindings of values to the variables that result in a match of the pattern against the data store. TMSPARQL takes a SPARQL query and converts it into a set of matches against a topic map data store. It is important to point out that the data being queried is stored using a conventional topic maps data model - no conversion or intermediate form of data is required nor is any configuration or mapping of identifiers.

For the purpose of explanation I'm going to use some very simple sample data. This is the data being queried in CTM notation:

person http://www.networkedplanet.com/ontology/employment/person .
company http://www.networkedplanet.com/ontology/employment/company .
worksFor http://www.networkedplanet.com/ontology/employment/worksFor .
employer http://www.networkedplanet.com/ontology/employment/employer .
employee http://www.networkedplanet.com/ontology/employment/employee .
hourlyWage http://www.networkedplanet.com/ontology/employment/hourlyWage .
alf
isa person
hourlyWage 14.50 .
bert
isa person
hourlyWage 25.40 .
xyz isa company .
worksFor(employee: alf, employer: xyz)
worksFor(employee: bert, employer: xyz)

Mapping URIs to Topics

The first stage of the TMSPARQL process is to bind all URIs in the triples of the graph pattern to topics. The URI may be one of a small number of special predefined URIs (primarily used as predicates for explicit traversals of the topic map data model), otherwise the URI is used to look up topic map items by item identifier or subject identifier (for topic items). Under this rule it is possible for a single topic to be referenced by different resource URIs in a SPARQL query, but this has no negative effect on the construction or execution of queries. If a topic map item cannot be found for a particular URI, then the triple containing that URI cannot be matched. For example given the query:

PREFIX ont: 
SELECT ?person ?employer ?wage WHERE {
?person ont:employer ?employer .
?person ont:hourlyWage ? wage
}

only the predicates of the triples in the graph pattern are bound to URIs. The TMSPARQL engine must, then, find the topic map items identified by the URIs http://www.networkedplanet.com/simpleOntology/hourlyWage and http://www.networkedplanet.com/simpleOntology/employer.

Implicit Data Model Traversals

If the predicate of a triple in the SPARQL graph pattern does not match any of the predefined URIs for the explicit data model traversals, then there are a number of possible traversal options that the TMSPARQL processor must consider. In each case, the predicate specifies a typing topic that acts as a filter on the traversal.

Topic Property Value Traversal

The Topic Property Value Traversal binds topic items to the subject of the triple and literals to the object of the triple. The triple predicate must be a name or occurrence type and specifies the type of name or occurrence that must be present on the topic bound to the subject with a literal value equal to that bound to the object.

In our example query the triple ?person ont:hourlyWage ?wage executes as a Topic Property Value Traversal because the topic with the subject identifier http://www.networkedplanet.com/simpleOntology/hourlyWage is used as an occurrence type in our sample data set.

Using our example data again, the query:

SELECT ?person, ?wage { ?person ont:hourlyWage ?wage }

will result in the following variable bindings:

?person	?wage
alf	14.50
bert	25.40

Handling Traversal Options

It should be noted that it is not possible to determine from the predicate URI of a triple which implicit data model traversal should be followed. Our current implementation uses the other triples in the query to help narrow down the traversal options. For example the single triple in the query:

SELECT ?person ?wage WHERE {  ?person ont:hourlyWage ?wage }

Could be either a related topics traversal (in which case ?wage must bind to a topic) or a topic property value traversal (in which case ?wage must bind to a literal). However the query:

SELECT ?person ?wage WHERE {
?person ont:hourlyWage ?wage .
?wage a ont:monetaryValue
}

has a second triple that implies that ?wage cannot be a literal value (because it has a type specified by the topic referenced by ont:monetaryValue) so only a related topics traversal is appropriate. Alternatively the query:

SELECT ?person ?wage WHERE {
?person ont:wage ?wage .
FILTER (?wage > 50)
}

uses ?wage in a filter comparison with a numeric which therefore implies that ?wage must be bound to a literal value and so the traversal in the first triple must be a topic property value traversal.

If the predicate is already bound to a topic at query time, it is also possible to handle this problem by inspection (looking at the topic map to see how the topic that binds to the predicate is used for typing purposes) or by reference to a TMCL schema (by looking at how the predicate topic is declared for use in the schema). However these approaches do not help when the predicate of a triple is itself a variable. In some cases it may be necessary to execute both traversal options and combine the results.

Explicit Data Model Traversals

TMSPARQL predefines a number of URI identifiers for specific traversals of the topic maps data model. Whenever a triple is encountered in the SPARQL query that uses one of these URIs as the predicate of the triple, then the corresponding data model traversal is invoked. Each of these traversals also imply a restriction on the type of item referenced by the subject and object of the triple. The table below summarises these predicates using CURIEs where the prefix rdf maps to the URI http://www.w3.org/1999/02/22-rdf-syntax-ns# and the prefix tms maps to the URI http://www.networkedplanet.com/tmsparql.

Identifier (CURIE)	Traversal Description	Subject Item Type	Object Item Type
rdf:type	The type-instance traversal. From a typed topic map item to the topic(s) that specify its type(s).	Topic, Association, Role, Name, Occurrence	Topic
tms:reifier	Item -> Reifier traversal. From a topic map item to the topic that reifies that item.	Association, Role, Name, Occurrence	Topic
tms:role	Association -> role traversal. From an association item to its child role items.	Association	Role
tms:player	Role -> player traversal. From a role item to the topic item that is the value of the role player property	Role	Topic
tms:topicProperty	Topic -> occurrence or name traversal. From a topic item to its child name and occurrence items	Topic	Name, Occurrence
tms:scope	Scoped item -> themes traversal. From a scoped topic map item to the topics in its scope property.	Association, Name, Occurrence	Topic
tms:value	Property -> value traversal. From a name or occurrence item to its value literal.	Name, Occurrence	Literal

It is important to note that these traversals also carry implications on the type of object referenced by the subject and object of the triple. If a variable is present in multiple triples in the pattern its actual item type must be the intersection of all item types implied by the triples it is in. If that intersection is the empty set, the query cannot bind the variable at all.

Importing RDF and Querying with TMSPARQL

One of the goals of this design has been to make it possible to import RDF into a topic map store and then execute the same SPARQL query against it as you would if the data had been stored in an RDF store. This is the reason behind the choice of the implicit traversals described above. A number of papers on importing RDF into topic map data stores have been written (and many of which are summarised in the W3C Working Group Note "A Survey of RDF/Topic Maps Interoperability Proposals") and it is not the purpose of this paper to rehash those issues. However our design of the implicit traversals does impose some restrictions on how RDF properties map to types in the topic map data store. If the object of the RDF triple is a resource, then the assumption is that the subject and object of the triple both map to topics in the topic map store, and the predicate URI must be the subject (or item) identifier of the topic that defines the role played by the topic mapped to the triple object in an association with the topic mapped to the triple's subject. If the object of the RDF triple is a property, then the assumption is that the subject of the triple must be imported as a topic in the topic map store, the predicate URI must be the subject (or item) identifier of the topic that defines the type of a new property on the topic mapped to the subject of the predicate and the object of the triple must be used as the value of that new property. An ontology-based mapping approach such as Ontopia's RTM should have no difficulty in meeting these requirements.

It should also be noted that TMSPARQL doesn't care about any reverse mapping from the topic map back out to RDF, as SPARQL results sets are simple tabular values. Where a variable binds to a topic map item, the TMSPARQL implementation simply returns a suitable identifier for the item (typically a system-specific item identifier). Of course those identifiers should then be resolvable to return RDF data, but how that RDF data is generated is not constrained by TMSPARQL itself. It should also be noted that the CONSTRUCT form of SPARQL query can be used by SPARQL clients to define exactly what RDF the SPARQL endpoint returns.

Limitations of TMSPARQL

Many of the limitations of TMSPARQL are actually limitations in SPARQL itself. For example, querying for the non-presence of specific topics is not terribly easy requiring some contortions with the bound() filter. Reification isn't handled natively (because it isn't handled natively in SPARQL despite the fact that RDF makes heavier use of reification than topic maps). As we chose not to extend SPARQL syntax, if you want to do more with your topic map than traverse related topics and filter on / retrieve type and property information you are force to use some "magic" identifiers - but we feel this is a worthwhile trade-off for interoperability.

The TMSPARQL language as presented here does not have direct support for variants (this is due to the mapping performed in our underlying topic map system that converts names, occurrences and variants into "topic property" items). A truly TMDM-compliant version of the language might add support for variants by adding a tms:variant predicate type and defining an appropriate traversal (from name item or variant item to variant item).

Conclusion

TMSPARQL shows some promise for helping topic map repositories easily act as full citizens on the Linked Data Web providing a SPARQL query endpoint which, with only a little careful ontology mapping can be made to appear exactly like an RDF data store. The advantages here are primarily for the consumers of linked data - giving them only one query language to learn (SPARQL) and the ability to combine query results from both topic maps and RDF repositories as well as the various databases and other data stores that now expose SPARQL endpoints.
As well as the obvious interoperability benefits, TMSPARQL is also a clean small query language that is relatively easy to learn to write and to reason about which, we hope, should be able to cope with the majority of real-world topic map query use cases.

Further Examples

Here are a few additional sample queries to give a feel for how SPARQL can be used to query a topic map. For compactness I haven't included the PREFIX declarations.

Filtering Values

The FILTER construct in SPARQL can be used to restrict the results set in various ways. E.g.

SELECT ?person ?age WHERE {
?person ont:age ?age .
FILTER ((?age<40 && ?age > 18) || (?age = 50))
}

Find all people aged between 18 and 40 or exactly 50 years old.

SPARQL includes a number of predefined filter functions including URI validation and regular expression pattern matching. E.g.

SELECT ?person ?website WHERE {
?person ont:web ?website .
FILTER isuri(?website)
}

Find all ont:person topics with an ont:web property whose value is a URI.

SELECT ?person ?site WHERE {
?person a ont:person
OPTIONAL {
?person ont:website ?site
}
FILTER (regex(?site, "^http://"))
}

Find all ont:person topics with an ont:web property whose value starts with the string "http://".

Optional Matches

The OPTIONAL construct in SPARQL means that not all variables need to be bound by a pattern match:

SELECT ?person ?site WHERE {
?person a ont:person
OPTIONAL {
?person ont:website ?site
}
}

Find all topics of type ont:person and return the value of their ont:website property if they have one.

The OPTIONAL construct can also be combined with the bound() FILTER function:

SELECT ?person ?site WHERE {
?person a ont:person
OPTIONAL {
?person ont:web ?site
}
FILTER (!bound(?site))
}

Find all topics of type ont:person that do not have an ont:website property.

TMDM Queries

Using the special predefined TMSPARQL predicates it is possible to query the topic map data model at a more detailed level.

Reification

SELECT ?ageProperty ?ageValue ?ageReifier WHERE {
?ageProperty a ont:age .
?ageProperty tms:value ?ageValue
OPTIONAL { ?ageProperty tms:reifier ?ageReifier }
}

Find all names and occurrences of type ont:age, returning the item itself, the value and the reifying topic of the property if it is reified.

Associations

SELECT ?assoc, ?assocType, ?roleType WHERE {
?assoc a ?assocType .
?assoc tms:role ?rolePlayed .
?rolePlayed tms:player inst:12345 .
?rolePlayed a ?roleType
}

Find all associations in which the topic identified by the CURIE inst:12345 is a role player, returning the association item, the association type and the type of role played by the inst:12345 topic.

Scope

SELECT ?place, ?name WHERE {
?place a ont:place .
?place tms:topicProperty ?prop .
?prop a tm:displayName .
?prop tms:scope lang:de
}

Find all topics of type ont:place that have a property of type tm:displayName scoped by lang:de.

Context is King!

Graham Moore — Mon, 10 Mar 2008 14:45:23 +0000

I recently did an interview for Tassilo Pellegrini from the Semantic Web Company. We talked about Topic Maps and the upcoming conference in Oslo. You can see the full interview here.

Ontology-driven Application Design with the NPCL Schema Editor

Kal — Tue, 14 Aug 2007 10:23:49 +0000

With the new release of the NPCL Schema Editor, the focus of our developer tool set is now moving around to ontology-driven application design. This post is to explain a little more about what that concept involves and how we think it can provide real benefit to system architects and developers alike.

Ontology and Information Management

Our key focus has always been on Information Management - enabling organizations to better organize the information that they work with to make it more accessible, more relevant to key processes and better connected to the concepts that drive the business. Adding ontologies into the mix strengthens the connections between information assets and concepts by enabling the business concepts to be made as concrete as the documents and databases that are part of the business. An ontology can also provide a means for expressing the common consensus on "what exists in our business", "what do we do" and "what are our key business drivers, goals and concepts" - in that alone the development of an ontology can be a key part of examining and improving business processes.

An Ontology-based Application Development Process

There are many stages of the application development life-cycle where ontologies can play a key role. These are the principle ones that we have seen from our exeperience in developing information management solutions using topic maps.

Design To Ontology

An ontology represents a concrete specification of the classes of concepts and relationships that are involved in a particular system architecture. By creating an ontology with "Person", "Company", "Document" and other topic types we are explicitly saying that these concept classes are a key part of the system architecture. In many cases these conceptual classes will persist all the way down into the data layer. Of course, in the old days that meant creating database tables, but with topic maps the possibility of a more flexible approach is opened up.
Furthermore with a constraint language for topic maps such as NPCL, we can take the high-level concept classes and encode them directly in a syntax that the topic map processor can understand and act on. In this way we can really start the process of coding a system by writing the ontology - it is the first step on the road to making our conceptual designs a concrete reality.
A constraint language also allows us to express more about our model than a simple system of types. Constraints enable us to specify how those types interact and combine and impose minimum requirements for data integrity.

Ontology to Code

Ontology and code can interface in many different ways.

Code Access To Ontology

At the simplest you can use code to acess the ontology information. In TMCore, this feature is provided by the NPCL library and the supporting database views that enable running code to query and traverse ontology information. In this way code can be written that is designed to work flexibly with different domain models by allowing the ontology to specify how it behaves. A simple example of this is the UI for populating a topic with occurrence values. An ontology-unaware application will have to prompt the user to search for the occurrence type and will have no way of validating that the occurrence type and its value make sense for the topic (specifying two Age occurrences with different values on a Person topic for example). An ontology-aware application could know that a Person topic is only allowed one Age occurrence, that the value for this occurrence must be a non-negative integer and that the value must be less than 130.
Ontology-Driven Queries
An ontology specifies both the types and the relationships between them. Therefore it is easy to see that it should be possible to create ontology-driven query interfaces that allow users to develop queries that traverse an topic map instance based on the types and relationships specified in the ontology and without the need for a lot of specialised knowledge about how that information is stored. ISO is working on a standardised query language for topic map queries known as TMCL, but even this is working from the principle of being ontology-unaware. An ontology-aware application will ensure that users only ever create "meaningful" queries (queries that could possibly return at least one result) and can avoid the need for users to know the underlying identifiers assigned to the types in the ontology. We have already implemented an initial version of this idea in the TMCore SharePoint Module where a simple web-form UI allows a user to construct a query as a series of "hops" through the topic map with optional filtering at each stage of the hop. The ontology-aware query editor form ensures that the user can only select an appropriate relationship type for the next hop based on the type(s) returned by the previous hop.
Ontology-based Code Generation
An initial version of our ideas on code generation was shown at the TMRA conference last year (and is written up in the book "Leveraging the Semantics of Topic Maps". Code generation holds many promises - not least of which is reducing the burden on the application developer by removing (or reducing) the need to write the classes that represent the key entities in the solution and allowing them instead to focus on the business logic. Combine this with the ability of a flexible schema language like NPCL to allow domain-specific constraints to be expressed in the schema itself and gradually it should be possible to move more and more of the commonly coded elements of solutions into simple configuration of properties in a schema.

Ontology to UI

I have already mentioned how an ontology-aware user interface can provide input validation, but the advantages of ontology-based application development do not stop there. As many of our applications tend to be web-based and/or forms-based, the ontology can be used as the intial specification of the layout of the various presentational forms. We will shortly be releasing an example of this for the TMCore SharePoint Module which uses the annotated ontology to generate SharePoint content types and fields which in turn automatically produces the forms representations for those items in the SharePoint interface.
Future work in this area will also look at the possibility of auto-generating all kinds of page layouts and windows forms as well as web forms.

Conclusion: The Future For Ontology-Driven Applications

The release of the NPCL Schema Editor is the first step in enabling the vision of speeding up the development of complex information management solutions through the application of simple topic map schemas. By building on a solid base of Topic Maps, TMCore, NPCL and now the visual editor tool we will be bringing our developer community more and better tooling to help in code generation, query generation, application and UI configuration. To keep apprised of what we are doing, be sure to subscribe to this blog!

Topic Map Objects Research Paper

Graham Moore — Wed, 18 Jul 2007 15:28:50 +0000

While this paper has been presented at TMRA and Extreme we thought it would be good to publish it here as well.
This paper is important as it points at the next level of topic map based productivity tools and utilities. For the topic map market to grow the tool and product creators need to enable developers and information architects to more rapidly build and deploy Topic Maps based applications.
This paper describes a C# framework for mapping TMDM data into domain specific classes. In somes ways it can be considered as a serialisation technology. However, TMObjects goes beyond that to provide update capabilites through the domain specific objects.
We are currently looking into how to improve the performance of the tmobjects read capability and also how the C# binding classes can be generated from NPCL (Networked Planet Constraint Language) structures. All this will lead to development environments that have all the flexibility and power of topic maps but with the comfort and support found with Visual Studio and a domain object model.
The full paper can be found here : Download file