CDMS Article for SFSW2007
March 12th, 2007
This article is being prepared by Richard Hancock for the 3rd Workshop on Scripting for the Semantic Web. The workshop is part of the fourth European Semantic Web Conference which is being held from 3-7th, June 2007 in the Tyrol region of Innsbruck, Austria.
Task Verification on the Semantic Web
Abstract
Limitations with the resource linking capabilities of a conventional web based mobile phone application has led an appraisal of a new semantic-web architecture. The current application provides the construction industry with the ability to verify at the job site that work has been completed to a satisfactory standard, i.e. that it complies with the mandated standards and regulations. The semantic web architecture aims to improve the linking of project team members, site locations, referenced documents and project tasks. A generic ontology is being developed to support the on site verification and the raising of followup actions for non-compliant work items. While much application development work remains to be done, already it can be seen that the semantic-web architecture provides a road map for the future, opening up possibilites in related areas.
Compliance Specification
In general compliance is the requirement that a piece of work is completed to a satisfactory level, as mandated in a specification, standard, law or regulation etc.. Usually the specification provided by regulatory authorities is at a relatively abstract level and an organisation needs to define a compliance specification specific to their own requirements. Alternately there may be a suitable industry recognised specification that can be adopted as is or with minor changes. Changes would include applying the specification in the context of a specific site, eg. close proximity to the corrosive elements of the ocean may mandate the use of stainless steel bolts on a construction site.
Thinking more generically, compliance can also be extended to include the monitoring of the state of an object. In this case an object complies while its state remains within a given range of values and fails to comply when its state moves out of that range.
The first steps in compliance are determining what the compliance specifications are and the specific situations in which compliance will be checked.
Compliance Applications
The verfication process and the raising of followup actions is common to the range of applications described below.
Compliance Management
Fully managed compliance is performed in the context of a project or a business process. In an initial design phase users specify what needs to be verified and the criteria which will form the basis of the verification. A compliance plan is produced which lists the items to be inspected, the compliance criteria and who has been allocated the inspection tasks. During the inspection process when an item can’t be deemed compliant a followup action is raised. The generated list of outstanding followup actions is monitored, with each action being managed to a successful resolution.
The application on which this article is based, the Compliance Data Management Service (CDMS), is an example of a “Compliance Management” application.
CDMS allows on-site inspections to be performed using a mobile phone web based application.
Defect Recording
A defect recording application operates in a similar manner to the compliance management application in the sense that work is inspected and followup actions can be raised to indicate that the work is not of an acceptable standard, however the defect recording application operates in a more adhoc fashion. The work is not verified as per a pre-defined compliance plan. Defects are raised on items as they are encountered by the person performing the inspection.
Automated Error Detection
Automated error detection refers to an automated system where an agent monitors the state of an object and raises a followup action when the object moves beyond its desired state. An example of this type of application would be a building secruity system which raises an alarm when the normal resting state is disturbed, e.g. if there was an intruder, and the followup action would be to notify the security firm to perform an onsite security check.
Main Work Flows
The main work flows for a compliance application are outlined below.
- Compliance Specification is the task of defining the steps which need to be taken to validate the state of specific items. The outcome is a “Compliance Plan” which lists “Verification Points” that need to be deemed valid or not as per a given set of “Criteria”. The “Compliance Plan” is used in the “Project Design” workflow. The “Compliance Specification” workflow is a potential candidate for implementation as a semantic-wiki to encourage the development of community based “Best Practice” compliance plans.
- Project Design is the task of defining a project in terms of one or more “Compliance Plans” which are applied in specific contexts, deemed “Worklots”. A “Job” is the pairing of a “Compliance Plan” with a “Worklot”. The “Job” consists of a set of Verifications, each Verfication matching a “Verification Point” defined in the “Compliance Plan” and applied in the specific context of the assigned “Worklot”. A Verfication is the smallest unit of work which can be assigned to an individual. The individual would perform the verification using the criteria defined against the Verification Point of the Compliance Plan.
- Compliance Validation is a ubiquitous activity supported by a web based application that is accessible in the field by a mobile phone and in the office by a standard web browser. The web application provides the means to validate work or raise followup actions.
- Project Management is also ubiquitous supported, providing report generation and RSS feeds to assist in project management.
The main interactions between the “Project Design”, “Compliance Validation” and “Project Management” workflows are shown in the diagram below. In this case “Compliance Specification” has been merged with “Project Design” and the “Compliance Plans” created as part of “Project Design”.
Stakeholders, Users and Roles
Project stakeholders are typically organisations with their associated users performing project tasks according to the roles assigned to them.
The main types of organisations are currently “Construction Contractors” and “Project Owners”.
The main roles are currently “Project Designer”, “Project Manager”, “Checker” and “Guest”.
Future organisations participating via a semantic-wiki to create compliance specifications could include “Industry Organisations” and “Product Manufacturers” who provide instructions on how their products should be installed. These users would participate with a role of “Compliance Specifier”.
Common Features
The common features of compliance applications is the raising of followup actions and forwarding that action to someone or thing to be monitored and actioned. The action raised need to be linked to the resources required to resolve it.
The “compliance management” and “defect recording” applications share a similar mechanism for associating criteria with an item for evaluating that the item complies with that criteria.
The staff management aspects of the “compliance management” and “defect recording” applications are also similar.
Semantic Web Advantages
The semantic web allows resources to be easily linked together. When combined with mobile phone technology adhoc inspections can be linked to resources to enable the on-site information to be recorded in it’s correct context. This can include location information plus problem related photos taken on site.
Defining The OWL Compliance Ontologies
Defining OWL ontologies suitable for compliance applications and also leveraging the resource linking capabilities of the semantic web brings together information and concepts from the following three main sources :
- Concepts unique to a compliance application, the central ones being “Compliance Plan”, “Verfication Point”, Criterion/Criteria and “Followup Action”.
- Information gleaned from online sources which can be referenced by compliance specifications. This includes legislation, regulations and standards, work classifications and industry groupings, product specifications, project specifications, geographical information, land title and address information, .
- Existing related OWL ontologies, especially those describing projects, workflows, collaborating online communities and geograhical locations.
Survey of Related Ontologies
The following existing ontologies provide a base for the compliance ontologies.
- DC Dublin Core provides metadata concepts for describing documents.
- FOAF (Friend of a Friend) provides the concept of a Person.
- SIOC provides the concept of an online User acting in a Role (uses FOAF).
- Geo represents latitude, longitude and altitude information.
- Geonames provides geographical information (uses Geo).
- SKOS provides specifications and standards to support thesauri, classification schemes, subject heading systems and taxonomies.
- Project Vocabulary Danny Ayers started a Project Vocabulary which specifies a vocabulary for describing projects independently of the project domain (e.g. software product development, fundraising, painting the garage). The intended architecture is primarily goal-oriented, that a project will consist of goals that may be broken down into subgoals. It includes definitions for Project, Task, Agent.
danny666@virgilio.it
- WorkFlowOntology Tim Berners Lee wrote out a WorkFlowOntology with Tasks, states and state transitions. It uses http://www.w3.org/2000/10/swap/pim/doc#Work
Bug Tracking Ontology Blog Item
baetle – Bug And Enhancement Tracking LanguagE
DOAP DOAP is a project to create an XML/RDF vocabulary to describe open source projects
While these ontologies described some of the concepts identitied in the Entity Summary none of them adequately described the concept of an agent, human or otherwise, verifying that a work task has been performed satisfactorially or that an entity is in an appropriate state in relation to its current context and raising a followup action that needs to be resolved befor befor the work task or entity can be deemed to comply with a required standard or specification.
The Compliance Ontology
Below is an outline of the proposed Compliance Ontology.
- Followup Action
- Criterion/Criteria
- Job
- Project
- Specification (Compliance Plan / Inspection Test Plan). A specification defines how a specific task or group of tasks should be performed or carried out. The specification itself may be based on defined standards, such as those maintained by a Standards Organisation. Additionally the specification may also be based on the laws, regulations or policies acting at international, national, regional, or organisational levels. A specification contans one or more Verfication Points which are points at which work done on the task up to that point is verfied. A specification may be an industy best practice and reside outside of any specific project, for example as an industry best practice or it may full defined for a specific project. Alternatively an industry best practice may be customised for a specific project.
- Task
- CompliancePoint/VerficationPoint.
- Verification
- Worklot
Candidate Architecture
The candidate architecture is based on a Semantic Web architecture that will allow data to be shared and reused across the various application, enterprise, and community boundaries. In particular the goal is to use the resource linking capabilities of RDF/OWL to link in extracts from standards documents and use the social networking capabilities being developed in projects such as SIOC (Semantically-Interlinked Online Communities), FOAF (Friend of a Friend) and OpenId ( Single Sign On) to link together the different groups of people who come together to work on our projects. Weaving this together will be a project management OWL ontology that will define the allocation of tasks to people (foaf:Person) and the steps required to validate that the tasks are complete or that followup actions are required, etc…
Architectural Components
The application is based on a number of existing ontologies and identifies the need for some additional ontologies.
RDF Triple Store
Jena,
“Joeski”: http://www.joseki.org/ HTTP engine that supports the SPARQL Protocol and the SPARQL RDF Query language.
Active RDF and Ruby On Rails
Gleaning Resources
RDF-izing existing applications
Locked within the standards documents produced by the standards organisations are key elements of information that need to be incorporated.
It addresses issues of data integration, identity and security, open standards, device independence, community-based social networks, emergency planning and notification
Semantic Wiki
“A semantic wiki is a wiki that has an underlying model of the knowledge described in its pages. Regular wikis have structured text and untyped hyperlinks (such as the links in this article). Semantic wikis allow the ability to capture or identify further information about the pages (metadata) and their relations. Usually this knowledge model is available in a formal language, so that machines can process it. The technologies developed by the Semantic Web community build the basis for reasoning about the knowledge model.
In particular, machines can calculate new facts (e.g. relations between pages) from the facts represented in the knowledge model.”
Semantic Wiki State Of The Art lists available Semantic Wiki engines.
- IkeWiki
SPARQL endpoint
- Semantic Media Wiki supports the following
- Categories are used as universal “tags” for articles, describing that the article belongs to a certain group of articles. e.g. [[Category:Example category]]
- Relations can be viewed as “categories for links.”, e.g. a “capital-relationship” [[capital of::Germany]]
- Attributes e.g. [[population:=3,396,990]]
- Datatypes and units of measurement
- Units
- Special types
- Semantic templates
- Using a query to produce wikitext for annotations
- RDF Export is based on the semantic annotations. Semantic MediaWiki generates machine-readable documents in OWL/RDF format, that can be accessed via Special:ExportRDF. A maintenance script for automatically generating complete exports of all semantic data. A recursive export exports all information about related objects. A backlink export also exports all articles that have relations to any of the exported article.
- Importing vocabularies
Java, Tomcat 5, Jena v2.1
- pOwl – created tables but not working.
Classification of Work Specifications
Defining Communities
As per the Fractal communities discussion the architecture would ideally support an overlapping set of many ontologies in a fractal distribution with several recurring patterns at different scales.
One pattern is a local integration within (say) an enterprise, which starts point-point (problems scale as n^2) and then shifts with EIA to a hub-and-spoke where the effort scales as N. Then the hub is converted to use RDF, and that means the hub then plugs into a external bus, as it connects to shared ontologies.
Key elements of the system are identity, standards, specificiations, and
Dry – “Don’t Repeat Yourself” is a process philosophy aimed at reducing duplication
Identity, Authentication, Authorization
Goal – to provide a single sign on mechanism across the participating organisations and parties who may only come together for one project.
Specfication Communities
Project Communities
Future Enhancements
- Reasoning Support
- Abstract the Checker as an agent, providing the ability for non-human agents to fullfill the role of Checker.
Summary
Lessons Learned
New Horizons
References
Developers Guide to Semantic Web Toolkits
FOAF (Friend of a Friend)
Generic Project Ontology http://dannyayers.com:88/xmlns/project/index.htm
Quick Guide to Publishing a Thesaurus on the Semantic Web
Resource Description Framework (RDF)
dbpedia.org Querying Wikipedia like a Database
Powl – Semantic Web Development Plattform
“Semantics in Business Systems by Dave McComb”:http://www.semanticsinbusiness.com/
Semantic MediaWiki Annotations
Web Ontology Language (OWL). OWL allows us to express how data sources connect together.
Wikipedia Definitions of Compliance lists a number of definitions for compliance.
cdms.mobi
March 5th, 2007
cdms.mobi is the registered domain name of the ABE Services CDMS Mobile Phone Application.
.mobi is a top-level domain (TLD) approved by ICANN, the Internet Corporation for Assigned Names and Numbers.
.mobi is unique – it is the first top level domain dedicated to delivering the internet to the mobile phone.
There are four times as many mobile phones as there are PC’s in the world. By 2008 1.3 billion people will connect to the Internet via mobile phones. (IDC Research). A goal behind the use of the .mobi domain is to ensure that these sites work well on mobile phones.
.mobi web sites must be compliant with the Web Developers Guide.
Mobile sites can be checked for compliance with the Web Developers Guide by using the Mobi Ready site listed below.
General information on .mobi is available at the dotMobi site.
Mobi Ready Analysis for Mobile Phone Site
The Mobi Ready Site provides a free analysis testing the mobile-readiness of a mobile phone site. It test the site and gives a report, evaluating the site tested using the industry best practices & standards that .mobi sites need to comply with.
The level of compliance of the CDMS Mobile Phone Application can be tested by going to the Mobi Ready Site and entering the URL www.cdms.mobi.
Mobile Emulator for Web Sites
The Mobile Emulator Site “emulates” a real mobile phone Internet browser and can be used to check how a web site looks to a typical mobile phone user.
How the CDMS Mobile Application Works
March 4th, 2007
Overview
The CDMS Mobile Application is based on XHTML Mobile Profile.
Supported Mobile Phones need to meet the Mobile Phone Baseline Requirements listed below.
Mobile Phone Baseline Requirements
The baseline requirements are based on those suggested in the Global Authoring Practices for the Mobile Web
- XHTML MP 1.0
- Support for XHTML Mobile Profile 1.0.
- GIF and JPEG
- Support for GIF and JPEG image formats.
- 256 colors
- Color device with support for a minimum of 256 colors.
- 120×120 screen
- 120×120 pixel screen or larger.
- At least 10 Kilobyte of content
- Device can manage at least 10Kb of combined mark-up, graphics and CSS content.
- Basic support for Tables
- two columns tables are supported. no ‘rowspan’ and ‘colspan’ support required.
- Picture and Link on the same Line
- Device can display a picture and a link on the same line.
- 9.6 Kbps Minimal Bandwidth
- Device and network support at least 9.6 Kbps bandwith.
Mobile Application Developer Guidelines
- Use the application/vnd.wap.xhtml+xml MIME Type
- HTTP refresh can be used in XHTML MP to instruct the WAP browser to refresh the current page periodically. See Periodic Refresh in XHTML MP
- The accesskey attribute of the anchor tag is used to set a shortcut key for an anchor link. Valid attribute values are *, #, 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9.
- Set an input mask on text fields. An input mask restricts the type and number of characters that a user can enter. To specify an input mask in XHTML MP use the -wap-input-format property of WAP CSS. For example input { -wap-input-format: “10N”} sets a limit of ten numeric characters in text fields.
- Keep CSS in-line.
References
Build multiserving Java applications, Part 1
Build multiserving Java applications, Part 2
Global Authoring Practices for the Mobile Web
Creating a Blog Article
March 2nd, 2007
The ABE Services Weblog uses Mephisto as the blog server and Textile as the markup language for creating blog articles.
Some helpful articles for creating an article in Mephisto and using Textile include: