Wiki source code of General approach

Last modified by Arjan Loeffen on 2015/06/01 09:28
Content · Comments (2) · Attachments (2) · History · Information
Hide line numbers
 1: The [[open world assumption>>3. Modeling Guide.Modeling Approach#H4.3.1OpenWorldAssumption28OWA29]] implies that the CB-NL core specifies known features of constructs. It allows other features, defined in a separate ontology, to be valid even though they have not been defined (yet). Only if new features are specified that contradict the CB-NL core, the new features may be "rejected" by any system that takes both ontologies into account.
 2: 
 3: 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.
 4: 
 5: As a methaphor, you cannot build sentences with a dictionary only.
 6: 
 7: 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.
 8: 
 9: 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.
10: 
11: == Interaction between CB-NL, contexts and client systems ==
12: 
13: The CB-NL core exists only to allow separate ontologies to be linked to each other, and subsequently to integrate software systems that are founded on these ontologies. We must distinguish between identity, type relations and structural similarity between two or more ontologies.
14: 
15: 1. Let assume that some client system uses two separate, domain specific ontologies. The relation between those ontologies is made explicit using mappings. Each concept in each ontology is mapped onto the CB-NL core. As a result the CB-NL is a collection of core concepts and mappings onto concepts, that are managed outside the CB-NL. The mapping is available and updated and released frequently.
16: 1. The CB-NL may at any time be queried for any URI taken from any context. As a result, it can produce the URI of any context concept in any other domain, and information on how this concept is related to the URI passed. In the simplest case, the URI for **Bridge** in domain 1 (domain1/bridge) may be linked as "identical" to the core **Bridge** (core/bridge), which in turn is linked as identical to some other domain 2 **Overpass** (domain2/overpass). Information on that second domain **Overpass** can be retrieved by accessing the ontology for the second domain. The CB-NL provides a direct "pointer" into that ontology (by URI).
17: 1. Of course, the most powerful link is that of "identity". CB-NL also supports "subtype". This relation is less easy to apply. It is there for human inspection, as the exact nature of the relation between two concepts is fuzzy. For example: The URI for **House** in domain 1 (domain1/house) may be linked as "subtype of" the core **Building** (core/building), which in turn is linked as "supertype of" some other domain 2 **Mansion **(domain2/mansion). In what way the relation between **House** and **Mansion** should be understood is open for analysis. However, once this relation is established (by human inspection) action can be taken locally or on within CB-NL core level to align these concepts through identity.
18: 1. The CB-NL core may (and will) thus be augment by introducing new constructs, or expanding  / specifying features of existing CB-NL constructs. New **Building **subtypes are introduced, to allow context to introduce identity mappings, the most powerful mapping relation.
19: 1. Note that within a context ontology a **Building **may be further specified in line with the domain of interest, such as “design” or “construction” by adding all kinds of properties. The context ontology may introduce part-of relations or enforce that a **Building **must have a **Height**. The CB-NL does not support identity of these information structures, but only of the constructs that make up these structures: the concepts (OWL classes) and the relations (OWL object properties). Again, as a metaphor, "the CB-NL mappings do not  match sentences, they match words".
20: 
21: The way the CB-NL is constructed 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).
22: 
23: == Software access ==
24: 
25: Taking the nature of the CB-NL as a mix of core concepts and context mappings into account, the question remains on how to access the CB-NL.
26: 
27: It should be understood that the CB-NL is a formal OWL specification, not a software system or a server. So, first and foremost, it may be downloaded as a file. This typically takes the form of an OWL RDF file ([[http:~~/~~/api.cbnl.org/sparql/CBNL/statements>>http://api.cbnl.org/sparql/CBNL/statements||title="Getch the full ontology as a RDF file"]]). This ontology then in integrated into more elaborate RDF/OWL contexts, local to any application.
28: 
29: As the specification evolves (additional contexts added, concepts changed, added, removed) new releases are created. Such releases are notified.
30: 
31: In general, in a linked data world, it is good practice to keep the information where it is maintained; there should be one point of reference for any knowledge base. Technically this means that the CB-NL should be served from a single triple store. This triple store is available as [[http:~~/~~/api.cbnl.org/sparql>>http://api.cbnl.org/sparql||rel="__blank" title="Access the SparQL API"]] and may be accessed using SPARQL, passing queries in a REST fashion. The SPARQL queries may access graphs that conform to a specific release.
32: 
33: Currently not all software engineers are familiar with OWL or RDF. The need for an XML and JSON interface has been formulated. Therefore, any release is also available using a REST interface which serves XML or JSON on request ([[http:~~/~~/api.cbnl.org/xml/1.0>>http://api.cbnl.org/xml/1.0||rel="__blank" title="Open de XML API overview page"]]). This API provides access to the OWL specification, but the information is modelled in accordance with an information model expressed in UML.
34: 
35: Again, as the CB-NL is not a service or software system, the availability of these services (OWL, XML, or JSON) is not fully guaranteed.