• The purpose of this page is to explain how knowledge data is represented on the dynamic web.

• There are four phases that need to be considered individually because they have distinct requirements as set out below.

• What remains constant throughout is strict adherence to the principle that all information on the dynamic web is broken into elements that are regarded as "indivisible and immutable versions which are semantically complete and have their own provenance".

Specification Phase

• Before information can be stored on the dynamic web its meaning must be expressed in terms that are unambiguous on a global scale. This is quite a challenge. Just to contemplate devising, publishing and getting agreement to a whole range of ontologies is truly daunting - especially since participating sites are volunteers with their own needs, ideas and aspirations. For this reason the only way to build a global ontology is through standards devised to ensure that contributions from all comers will fit together without agreement.

• For this job we need a language that meets the following two criteria:
• Many publishers, working without reference to anyone else, must each be able to express in their own terms the full meaning of the information they provide.
• Many subscribers, working through their own free acceptance of offers must be able to collate any information from the dynamic web into their own documents without risk of confusion or ambiguity as to meaning even though this information may have arisen from many different sources without any overall control.

• The selection of features for this language is crucial to the success of the dynamic web. The required features are set out on the page called "Representation of Knowledge Data on the Dynamic Web - Specification Phase".

• Knowledge Data on the dynamic web is entered either:
• Through forms within pages downloaded to clients in the usual way and uploaded to the host site for storage in the site knowledge store and distribution to other sites as required.
• Through PHP, Java etc code using the appropriate API.

• The forms through which assertions are entered must conform to a standard so that they will be recognized by dynamic web server-side software that will convert each value into an assertion for addition to the local site knowledge store.

• Further detail of the features required in the standard for dynamic-web knowledge entry forms is provided on the page called "Representation of Knowledge Data on the Dynamic Web - Entry and Uploading Phase".

• Before a site can participate in the dynamic web it must be equipped with a site knowledge store. This comprises some ten or so tables that are not linked other than through URIs contained in the constituent data. The current implementation employs MySQL to hold these tables but they could be held in simple files or any RDF store since there are no foreign keys to worry about.

• The schema for these site knowledge stores is very simple and does not contain 'meta data' as in a conventional relational database. This is because the meaning of each assertion is expressed by reference to a property definition that is itself held as an individual resource within the dynamic web rather than by the specification of the table/file in which it resides.

• The knowledge data itself is held in an assertions table/file. This operates like a buffer in that assertions are appended on arrival, never updated and deleted when no longer required. These assertions arrive either through a dynamic-web knowledge entry form (or equivalent API) on the site concerned or in a message from a publisher site. They are deleted only by a routine purging process working on criteria supplied by the site owner through a standard dynamic-web knowledge entry form.

• In addition to the assertions table/file there is a pub-sub offer/contract table/file, records of the locally held ontological resources classes, class specializing schemes, and properties. and a local resource management table/file. The purpose of the offer/contract table/file is to hold instructions that control replication across the Web while the purpose of the local resource management table/file is to hold instructions that control how the local assertions file is managed - such as the criteria for deleting assertions when no longer required.

• The logical format of both files needs to be controlled by a standard so that all site knowledge stores are fully compatible. However, the software at each site can use any physical structure it choses. Further detail of the requirement for these site knowledge stores is to be found on the page called "Representation of Knowledge Data on the Dynamic Web - the Site Knowledge Store ".

• This fourth and final phase does not apply to use of the dynamic web by web applications but is a key part of direct access to knowledge data through simple web pages. It covers the process by which it is contrived that pages downloaded to clients always express the most appropriate version that is then available at the host site for the page converned. This phase performed by a server-side process which may be embedded within a web application or configured as a generic facility as explained below.

• The generic facility envisioned here is a site-based service that will intercept every request for download of a page and scan the HTML looking for references to dynamic knowledge data. The purpose of this scan is that all references to dynamic knowledge data will be replaced by the most appropriate version that can be found within that site's own site knowledge store. Further detail of the way in which assertions are incorporated into pages can be found on the page called "Representation of Knowledge Data on the Dynamic Web - Download Phase".