Changes for document General approach

Last modified by Arjan Loeffen on 2015/06/01 09:28

Content · Comments (2) · Attachments (2) · History · Information

From version 13.2

edited by Hans Nijssen
on 2014/10/01 12:13

To version 14.1

edited by Arjan Loeffen
on 2015/05/29 22:50

Change comment: There is no comment for this version

Metadata changes

Document author: XWiki.HArjan~~sNijss~~Loeffen

Content changes

@@ -1,39 +1,27 @@
--**===THIS SECTION IS UNDER REVIEW**
++The [[open world assumption>>3. Modeling Guide.Modeling Approach#H4.3.1OpenWorldAssumption28OWA29]] implies that the CB-NL specifies known features of constructs. It allows other features to be valid even though they have not been defined (yet). Only if new features are specified that contradict the CB-NL, the new features may be "rejected".
--The [[open world assumption>>3. Modeling Guide.Modeling Approach#H4.3.1OpenWorldAssumption28OWA29]] implies that the CB-NL specifies known features of constructs. It allows other features to be valid even though they have not been defined (yet).
++This means that querying the CB-NL for information on any construct will provide a basic set of information,  which may not be sufficient for building a useable, complete “form”, which is intended to specify any instance of the construct. This is so, because the domain of interest, the application of the CB-NL information, is undetermined. For any "use case" a different set of data, and therefore different models, may be required.
--This means that querying the CB-NL for information on any construct will provide a basic set of information,  which may not be sufficient for building a “form”, which is intended to specify any instance of the construct.
++As a methaphor, you cannot build sentences with a dictionary only.
--For example, the CB-NL defines a concept **Building**. It specifies that there exists a property **Height**.  It does not specify that a Building has a property Height or that it has a **Roof**. This is the consequence of our intent to support an Open World Assumption: the world around the CB-NL has more to say about Buildings, each in a particular context, and  therefore the CB-NL does not contain relations between concepts and properties. The CB-NL does define the constructs Building and Roof, but does not link these together. It is left to the context ontology to introduce these constraints, if needed.
++For example, the CB-NL defines a concept **Building**. It also defines a property **Height**.  It however does //not// specify that a Building has a property Height or that it has a **Roof**. This is the consequence of our intent to support an Open World Assumption: the world around the CB-NL has more to say about Buildings, each in a particular context, or use case, and  therefore the CB-NL does not contain relations between concepts and properties. The CB-NL does define the constructs Building and Roof, but does not link these together. It is left to the context ontology to introduce these constraints, if needed.
  In short: the CB-NL describes the fundamental constructs, but does not prescribe that a construct must (only) be used in the context of another construct.
  == Interaction between CB-NL, contexts and client systems ==
--[[image:notities2.png||height="380" width="635"]]
++We will explain how the CB-NL may be integrated assuming a software application approach.
++Let's consider the following architecture.
--First consider situation (A).
++TODO
--~1.      The CB-NL exists as an ontology. A web application provides services for accessing the CB-NL.
++1. The CB-NL exists as an ontology. A (web) application provides services for accessing the CB-NL. Such services may cover querying, inferencing, validation, testing, viewing, conversion...
++1. A client system uses a vocabulary. This is not the CB-NL but any standard vocabulary. The relation between that vocabulary and CB-NL is made explicit using a Mapping.
++1. A client system aims to comply to CB-NL. It therefore interacts with the (web) application.
++1. The application is requested to return the information it has on any identified construct., e.g. Building. The client system uses this information to certify that its own realisation of Building is in accordance with the CB-NL. Alternatively, the client may build a representation of the information already in store. This is then passed to the application, in order to validate the information passed against the CB-NL.
++1. Any organization (read: standard, or common vocabulary) may augment the CB-NL by introducing new constructs, or expanding  / specifying features of existing CB-NL constructs. New Building subtypes are introduced, or a Building is further specified in line with the domain of interest, such as “design” or “construction” by adding kinds of properties. This is a context ontology. This ontology may therefore introduce part-of relations or enforce that a Building must have a Height.
++1. When any system uses two or more such vocabularies (and many systems do!), and when these vocabularies have a common ground ("pump" is a concept that occurs in all vocabularies), the application may provide the glue between these vocabularies, allowing all information on the concept ("pump") to be merged. A full overview of what the concept entails is created. Also,
--2.      A client system aims to comply to CB-NL. It therefore interacts with the web application.
++This approach is founded on the Open world assumption (OWA). CB-NL only records what //must// be stated about a construct, and avoids constraining the statements. As a sideline: the CB-NL does not use domains or ranges (in the OWL sense), as these limit the applicability of a relation (realized as an OWL ObjectProperty).
--3.      The web application is requested to return the information it has on any identified construct., e.g. Building. The client system uses this information to certify that its own realisation of Building is in accordance with the CB-NL. One of the ways this is done it by building a form.
--
--4.      Alternatively, the client may build a representation of the information already in store. This is then passed to the web application, in order to validate the information passed against the CB-NL.
--
--Now consider situation (B)
--
--5.      Any organisation extends the CB-NL by introducing new constructs, or expanding  / specifying features of existing constructs. New Building subtypes are introduced, or a Building is further specified in line with the domain of interest, such as “design” or “construction”. This is a context ontology.
--
--6.      A client system focuses on the specific domain (“design”).
--
--7.      The web application may serve information on the construct, extended with the context information.
--
--8.      The web application may validate any extended information against the full info based on CB-NL and the selected context.
--
--The relation between 5 and 1 is supported by adapting the open world assumption (OWA). CB-NL only records what //must// be stated about a construct, and avoids constraining the statements.
--
--As a result, the CB-NL does not use domains or ranges, as these limit the applicability of a relation (realized as an OWL ObjectProperty). This is a drawback of OWL; it does not allow any ontology to extend the domain or range of a relation.
--