Archive for the ‘Compliance’ Category

Publishing Inspection and Test Plans as Linked Data

Saturday, February 14th, 2009

Stored in relational database tables within CDMS is a subset of information that could usefully be shared with the general building, civil engineering and construction industry to help promote a higher, uniform standard of quality.

This subset is described in more detail in the article Constructing an Ontology – Common Inspection and Test Plans.

The central concept is an Inspection and Test Plan (ITP) that identifies the points in a construction project when work of a specific type will be inspected and verified that it meets acceptance criteria.

An elegant way to share the Inspection and Test Plans is to publish them on the Semantic Web as an OWL ontology. The preferred way to doing this is to publish the Inspection and Test Plans as Linked Data, following the patterns outlined in the tutorial on How to publish Linked Data on the Web.

Once published as Linked Data the Inspection Test and Plans can be used by other building applications.

The process for doing this is to create  an owl:ObjectProperty such as the following appliesInspectionTestPlan and add it to the OWL definition of a building project.

building:appliesInspectionTestPlan
a       owl:ObjectProperty ;
rdfs:domain building:BuildingProject ;
rdfs:label “applies inspection test plan”^^xsd:string .

The  example building project  http://3kbo.com/examples/building4.rdf contains appliesInspectionTestPlan and applies it to the Breaker Bay building project as shown in the image below.

Inspection Test Plan Applied

In the example the Inspection and Test Plan referenced is contained in a data extract published at http://3kbo.com/examples/common_itps.rdf.

The D2R Server provides an easy way to publish the actual relational database tables containing the Common Inspection and Test Plans to the Semantic Web using the patterns outlined in the tutorial on How to publish Linked Data on the Web.

The Common Inspection and Test Plans are held in a MySQL database which was created by running the command:

mysql> create database common_itps character set utf8 ;

The D2R Server is installed by following the Quick Start instructions and adding the MySQL driver JAR file to the D2R Server installation /lib directory.

The mapping file was created by running the command

./generate-mapping -o mapping_common_itps.n3 -u db-user -p db-password jdbc:mysql://localhost/common_itps

and customized by removing some unnecessary database columns from the mapping file.

Also the following was added to the mapping file to explicitly define the server host and port.

@prefix d2r: <http://sites.wiwiss.fu-berlin.de/suhl/bizer/d2r-server/config.rdf#> .

<> a d2r:Server;
rdfs:label “D2R Server”;
d2r:baseURI <http://abeserver.isa.net.au:2020/>;
d2r:port 2020;
d2r:documentMetadata [
rdfs:comment "The Common Inspection and Test Plans are currently published as an experimental version. The data needs to be rationalized and the model confirmed before progressing to a draft status.";
];
.

Once the mapping file  has been generated and customized the server is started with the command:

nohup ./d2r-server mapping_common_itps.n3 &

An experimental verison of the “Common Inspection and Test Plans” can now be browsed online at http://abeserver.isa.net.au:2020/ in a web browser, ideally using Firefox with the Tabulator extension install.

Individual Inspection Test Plans can be opened directly in the browser using URLs such as http://abeserver.isa.net.au:2020/resource/inspection_test_plan/1.

Via content negotiation this request is redirected to the browser friendly page

http://abeserver.isa.net.au:2020/page/inspection_test_plan/1

The acutal RDF can be viewed directly at http://abeserver.isa.net.au:2020/data/inspection_test_plan/1.

SPARQL queries can be run using the AJAX-based SPARQL explorer http://abeserver.isa.net.au:2020/snorql/.

Why Migrate to the Semantic Web?

Saturday, November 8th, 2008

Why Migrate to the Semantic Web? has just been published at Devx.com.

It pretty much summarizes my reasons migrating the CDMS application to the semantic web.

What it doesn’t describe in detail is that for building compliance at a specific locality it is the local legislation that takes precedence. This means that Linked Data from sources such as Dbpedia is great for describing concepts but at a local level you need to refer to Linked Data derived from local legislation to explicitly clarify the criteria that forms the basis of compliance.

DBpedia Examples using Linked Data and Sparql

Monday, August 11th, 2008

Using Wikipedia, the largest online encyclopedia, users can browse and perform full-text searches, but programmatic access to the knowledge-base is limited.

The DBpedia project extracts structured information from Wikipedia opening it up to programmatic access using Semantic Web technologies such as Linked Data and SPARQL. This means that the linking and reasoning abilities of RDF and OWL can be utilized and queries for specific information can be made using SPARQL.

Simplistically the mapping from the Wikipedia HTML based web pages to the DBpedia RDF based resources can be thought of as replacing “http://en.wikipedia.org/wiki/” with “http://dbpedia.org/resource/” but in reality there are some additional subtleties which are described in the article From Wikipedia URI-s to DBpedia URI.

The Wikipedia entry for “Civil Engineering” (http://en.wikipedia.org/wiki/Civil_Engineering) is used as an example to show how specific data can be retrieved from its DBpedia equivalent (http://dbpedia.org/resource/Civil_engineering).

When both the Wikipedia entry (http://en.wikipedia.org/wiki/Civil_Engineering) and its DBpedia equivalent (http://dbpedia.org/resource/Civil_engineering) are opened in a standard web browser they display similar information, however the DBpedia equivalent has been redirected to http://dbpedia.org/page/Civil_engineering.

This redirect can be viewed in Firefox using the Tamper Data Firefox Extension as shown in the image below.

Loading the DBpedia Resource

The initial status of 303 is the HTTP response code “303 See Other“. The server replied with the HTTP response code 303 in order to direct the browser to URI http://dbpedia.org/page/Civil_engineering which is a HTML page the browser can display. The original URI http://dbpedia.org/resource/Civil_engineering is an RDF resource that would not display as well in the HTML browser.

DBpedia implements a HTTP mechanism called content negotiation in order to provide clients such as web browsers with the information they request in a form they can display. The tutorial How to publish Linked Data on the Web describe this and other Linked Data techniques that are used by applications such as DBpedia.

In order to access the RDF resource directly a web client needs to tell the server to send it RDF data. A client can do this by sending the HTTP Request Header Accept: application/rdf+xml as part of its initial request. (The HTML browser had sent an Accept: text/html HTTP header indicating that it was requesting an HTML page.)

The Firefox Addon RESTTest can be used to set Accept: application/rdf+xml in the HTTP Request Header and directly request http://dbpedia.org/resource/Civil_engineering as shown in the image below.

In this case the request to http://dbpedia.org/resource/Civil_engineering succeeded as shown by the “Response Status 200″ and a RDF document was received as shown in the “Response Text”.

In both the RDF fragment shown in the image above and in the HTML page http://dbpedia.org/page/Civil_engineering the multiple language support is visible. The SPARQL queries below show how to extract specific information for a particular language.

SPARQL

DBpedia provides a public SPARQL endpoint at http://dbpedia.org/sparql which enables users to query the RDF datasource with SPARQL queries such as the following.

SELECT ?abstract
WHERE {
{ <http://dbpedia.org/resource/Civil_engineering> <http://dbpedia.org/property/abstract> ?abstract }
}

The query returns all the abstracts for Civil Engineering, in each of the available languages.

The next query refines the abstracts returned to just the language specified, in this case ‘en’ (English).

SELECT ?abstract
WHERE {
{ <http://dbpedia.org/resource/Civil_engineering> <http://dbpedia.org/property/abstract> ?abstract .
FILTER langMatches( lang(?abstract), 'en') }
}

The SNORQL query explorer shown in the image below, provides a simpler interface to the DBpedia SPARQL endpoint. The image below shows both the query and the result returned.

Other SPARQL endpoints such as http://demo.openlinksw.com/sparql/ (shown below) can query DBpedia by specifying the FROM NAMED clause to describe the RDF dataset. E.g.

SELECT ?abstract
FROM NAMED <http://dbpedia.org>
WHERE {
{ <http://dbpedia.org/resource/Civil_engineering> <http://dbpedia.org/property/abstract> ?abstract.
FILTER langMatches( lang(?abstract), ‘en’) }
}

Other Related DBpedia Articles

RDF as self-describing Data uses DBpedia and its SPARQL support to show how RDF is essentially ’self-describing’ – there is no need to know about traditional metadata (schemas) before exploring a data set.

Linking to DBpedia with TopBraid outlines the benefit of DBpedia in terms of providing relatively stable URIs for all relevant real-world concepts, thus making it a natural place to connect specific domain models with each other using the OWL built in propery owl:sameAs ( This property indicates that two URI references actually refer to the same thing ). TopBraid Composer provides support to link domain models with DBpedia .

Querying DBpedia provides examples of using SPARQL to query DBpedia.

Adding Semantic Markup to Your Rails Application with DBpedia and ActiveRDF and
Get Semantic with DBPedia and ActiveRDF describe using ActiveRDF to integrate DBpedia resources into web based applications. ActiveRDF is a library for accessing RDF data from Ruby and Ruby On Rails programs and can perform SPARQL queries.

Constructing an Ontology – Common Inspection and Test Plans

Sunday, June 15th, 2008

ABE Services has developed a web based application, the Compliance Data Management Service (CDMS) for checking work performed on site as part of building and construction projects. These are projects undertaken by the building, construction and related industries.

The diagram below gives an overview of how CDMS works.

The three main parts of CDMS are:

  • Designing Projects by identifying the tasks to be performed and allocating those tasks to the people who will perform them.
  • Using a mobile phone on site to check that completed tasks comply with industry standards and best practice
  • Monitoring and Managing the project via the progress and status of the completed tasks, the tasks outstanding and the non-compliant tasks.

Inspection and Test Plans (ITPs) are central to the three main parts of CDMS.

An Inspection and Test Plan (ITP) identifies the inspection, testing (verification) and acceptance requirements of a particular type of task, eg brickwork. Conceptually an ITP could be thought of as a refined checklist, identifying the usual steps to be followed when undertaking a particular type of task. A specific task may also have additional requirements specific just to it.

An Inspection and Test Plan is composed of one or more:

  • Verification Point(s) which identify the parts of the task to verify. Each Verification Point is composed of one or more:
  • Criterion (plural Criteria) which define the specific requirements by which a verification point can be deemed compliant. This could include referencing specific industry standards which the task is required to comply with.

A set of commonly recurring Inspection and Test Plans (ITPs) has been identified and published on the ABE Services web site. To help promote a higher standard of work in the building and construction industries ABE Services decided to make these common Inspection and Test Plans (ITPs) freely and publicly available. Currently though the details of these common Inspection and Test Plans (ITPs) are hidden within the CDMS application. To place them in the public domain an OWL ontology, named the Common Inspection and Test Plans ontology, is being constructed based on this initial set of commonly recurring Inspection and Test Plans (ITPs).

The definition of ontology in this context is along the lines of “an ontology is a specification of a conceptualization“. In this case the specification is that which constitutes a generic Inspection and Test Plan and the more specialized Inspection and Test Plans listed in the set of common Inspection and Test Plans (ITPs). Other related definitions of ontology include the more philosophical “the study of the nature of being” and the more detailed Wikipedia definitions Ontology and Ontology (Information Science)

The Common Inspection and Test Plans ontology is being implemented using the Web Ontology Language (OWL). OWL is an ontology language that can formally describe the meaning of terminology used in Semantic Web documents (See Why OWL?). In turn the Semantic Web is about two things. It is about common formats for integration and combination of data drawn from diverse sources, where on the original Web mainly concentrated on the interchange of documents. It is also about language for recording how the data relates to real world objects. That allows a person, or a machine, to start off in one database, and then move through an unending set of databases which are connected not by wires but by being about the same thing.

In the world of building and construction projects, and activities related to Real Estate, the buying and selling of houses, house and building maintenance, and potentially in the selection of contractors to perform building work, the Common Inspection and Test Plans ontology will form one of these databases, connected by the concept of how to perform a specific type of building, construction or related task.

In the first instance the Common Inspection and Test Plans ontology has been published in a very simple draft form, listing only the Inspection and Test Plans and not the more detailed the Verification Points and Criteria.

This draft version is available at the URI: http://www.abeservices.com.au/schema/2008/05/InspectionTestPlans.rdf.

A good way to view it is to install the Tabulator rdf browser plugin for Firefox as outlined in Description of a Project

It is intended that the Common Inspection and Test Plans ontology evolve as a result of community participation. As well as general feedback it is hoped to also make available a web-based vocabulary editor which would allow for greater collaboration . (Potential options include using Neologism and OntoWiki).

The next steps are to

  • add Verification Point(s) and Criteria to the currently identified Inspection and Test Plans
  • identify additional concepts related to Inspection and Test Plans, e.g. Hold Points
  • add some worked examples

In a future article I’ll also outline how to query the Common Inspection and Test Plans ontology for specific informaton using the RDF query language SPARQL. A SPARQL end point is currently available at http://abeserver.isa.net.au:2020/ providing a SPARQL Query form .

Migrating an existing application to the iPhone and the Semantic Web

Saturday, June 30th, 2007

The “Compliance Data Management Service” for the building, construction and related industries (CDMS) is an example of a web and on-site workplace application that has been around long enough to experience the need to evolve to match the changes in underlying technologies. The iPhone and the Semantic Web are about to drive further evolutions.

Below is an overview of the current mobile phone based web application.

abe_diagram_light_02.jpg

This is the second version of the application. It supports work-place activities in real-time using mobile phones with web browsers capable of supporting XHTML-Mobile Profile web applications.

The original version of CDMS was based on Palm Pilots which operated disconnected from the network. The Palm Pilot version requires a manual synchronization step to update the CDMS application database . At the beginning and end of each day the Palm Pilot synchronizes with the CDMS application database via a desktop computer and a desktop application which passes data via a web service to the CDMS web application.

The iPhone

The iPhone represents a new class of mobile devices. As well as setting a new benchmark for ease of use and providing access to both mobile phone and wireless networks, it also sets a new benchmark for mobile web applications, reducing the gap between a standard desktop web browser and the mobile phone browser. In particular the iPhone is designed to support Web 2.0 and Ajax.

Ryan Breen sums up this evolution in his article In defense of Ajax for the iPhone when he writes “… in a few years I expect all mobile devices to provide the same browsing experience. With that, the line between traditional and mobile web development will further blur, with Ajax frameworks helping developers deliver consistent and appropriate experiences on each.”

The iPhone encourages the use of Ajax and simple intuitive interfaces. Adding these to the main CDMS web application is a good thing in itself and starts to bridge the gap with mobile phone XHTML-Mobile Profile web application. In time, as more phones move to equal the iPhones Ajax support a point may be reached where the CDMS web application and the mobile application are one and the same.

The Semantic Web

The current CDMS application is primarily a data island existing within a web of many potential external relationships. While there is currently one web service interface and more could be added, sharing data as XML still does not the relationships and their semantics to be fully expressed.

Some of the limitations of the current CDMS application are:

  1. users and organizations are forced to create yet another set of online accounts rather than using a single signon facility similar to OpenID.
  2. the relationships between people, organizations, places and things that are already established outside of CDMS need to be recreated within CDMS.
  3. CDMS uses its own internal classification schemes rather than utilizing existing publically available classification ontologies.
  4. CDMS uses an internal representation of standards that need to be complied with rather than linking to published standards (One problem for CDMS is that some of the standards are not currently freely available and not available in a suitable on-line form)
  5. CDMS uses an internal proprietary representation of organizations and their users
  6. CDMS uses an internal proprietary representation of a project structure and its tasks.
  7. constraints which could be expressed publicly within an OWL ontology are hidden internally within java source code.
  8. geographical location is not expressed in a standard manner.

The document Compliance Applications on the Semantic Web gives an overview of an alternative Semantic Web architecture for CDMS.

Future posts will start to address each of the above limitations.