Method and device for generating an ontology document

#Recent progress towards a ‘web for machines’ and an aspect web 2.0 means that many websites or domains offer access to exposed data and services via an interface such as an API (Application Programming Interface). The consumers of the resulting web applications are machines, rather than humans driving an application through a web browser.

#APIs and API support has also enabled the combination of data and services from more than one source to create derived services, mashups and desktop versions of web applications. Additionally, HTTP-based APIs have evolved as a means to support computing requirements (and not primarily to complement an existing website), for example, APIs referred to as Infrastructure-as-a-Service (IaaS) Cloud APIs. Infrastructure-as-a-Service is a mechanism by which a client computer or client network can access external or third-party computing infrastructure via the web for the performance of, for instance, processing and storage tasks.

#REST (Representational State Transfer) is an architectural style which governs the proper behaviour of participants in the web for machines. REST sets out constraints for system architectures to which conforming is described as being ‘RESTful’, the first of which is that the architecture has a client-server arrangement, with clients being separated from servers by a uniform interface. There are four guiding principles of the interface between client and server, and an interface developed in accordance with these principles can be described as ‘RESTful’. For example, an API can be written in accordance with the REST guiding principles for interfaces, and would hence be described as a ‘RESTful API’. HTTP as a protocol can be used in a RESTful manner, and RESTful HTTP is suitable for the web for machines. RESTful APIs are popular for a number of key reasons: there is simplicity of the basic protocol built on a proven foundation with solid architectural principles, and the result is approachable and usable by web developers.

#FIG. 1 is a conceptual map of an approach to producing APIs embodying the present invention;

#FIG. 2 is a diagrammatic representation of operations, types of classes, and the links between them;

#FIG. 3 illustrates a process embodying the present invention;

#FIG. 1 is a conceptual map of the approach used in a method embodying the present invention. The abstract ontology 10 does not exist in any addressable form, but is the generalised concept of an ontology (an ontology being ‘what exists’). The arrows extending from the abstract ontology 10 represent the idea that in order to move from the abstraction of ontology to an actual ontology (which could define, for example, a domain), three aspects can be considered: a domain ontology, a data structure ontology, and an operational ontology. In other words, what is present in any domain is extended by the methods embodying the present invention, and can be thought of in terms of a domain ontology, a data structure ontology, and an operational ontology. The domain ontology is the domain-specific language, items, and relationships, which may be described in some readable or usable form by a domain description. Optionally, it is the domain-specific information that is input by a user. In particular, the domain ontology may describe items within a domain as classes of items and sub-classes of items, which classes and sub-classes are related, and the nature of those relationships.

#The operational ontology and data structure ontology are domain-independent aspects which define generic relationships, rules, and assumptions for all domains. Components of the data structure ontology and operational ontology can be considered to be templates for building blocks that can be used to provide a complete information model for an extended domain.

#The data structure ontology may include the categorisation of relationships (links) between classes of items into ‘contains’, ‘accepts’, and ‘other’. That is to say, a relationship between class of items A and class of items B may be categorised as ‘contains’, i.e. meaning that A contains B. In a domain, item a (belonging to class A), and item b (belonging to class B), if linked, can be linked via the relationship ‘a contains b’. In other words, class A is a container which may contain items of class B. It may also be true to say that class of items A is linked to class of items B via a relationship categorised as ‘accepts’, and therefore that in the domain, item a can accept item b. In other words, an item of class A can accept an item of class B.