====== Differences ====== This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
api4kb_ontologies [2015/02/28 11:16] apaschke [Terminology] |
api4kb_ontologies [2015/03/10 11:10] (current) apaschke [API4KB Architectural Elements] |
||
---|---|---|---|
Line 39: | Line 39: | ||
==== API4KB Architectural Elements ==== | ==== API4KB Architectural Elements ==== | ||
- | === Communicating Entities === | + | The API4KB architectural elements are categorized according to the following competency questions. |
- | What are the entities that are communicating in the distributed system? | + | * What are the entities that are communicating in the distributed API4KB system? => **Communicating Entities** |
+ | * How do they communicate, or, more specifically, what communication paradigm is used to communicate between API4KB entities? => **Communication Paradigms** | ||
+ | * What (potentially changing) roles and responsibilities do they have in the overall API4KB architecture? => **Communication Roles** | ||
+ | * What is the mapping of the API4KB elements into a physical distributed infrastructure? => **Communication Placement** | ||
+ | |||
+ | === Communicating Entities === | ||
* **Node**: In primitive environments such as sensor networks, operating systems does not provide any abstractions, therefore nodes communicate | * **Node**: In primitive environments such as sensor networks, operating systems does not provide any abstractions, therefore nodes communicate | ||
Line 50: | Line 55: | ||
=== Communication Paradigms === | === Communication Paradigms === | ||
- | |||
- | How do they communicate, or, more specifically, what communication paradigm is used? | ||
See communication paradigms described in [[architecture_styles|architecture styles]]. | See communication paradigms described in [[architecture_styles|architecture styles]]. | ||
Line 60: | Line 63: | ||
=== Roles === | === Roles === | ||
- | |||
- | What (potentially changing) roles and responsibilities do they have in the overall architecture? | ||
For instance, client-server, peer-to-peer, agent architecture styles. | For instance, client-server, peer-to-peer, agent architecture styles. | ||
Line 71: | Line 72: | ||
=== Placement === | === Placement === | ||
- | |||
- | What is the mapping of the API4KB elements into a physical distributed infrastructure? | ||
* **Partitioning**: API4KB services provided by multiple servers by partitioning a set of objects in which the service is based and distribute them between multiple-services | * **Partitioning**: API4KB services provided by multiple servers by partitioning a set of objects in which the service is based and distribute them between multiple-services | ||
Line 78: | Line 77: | ||
* **Caching and Proxying**: A **Cache** stores recently used knowledge resources. Caches might be co-located with each client or located in a **Proxy**. Proxy provides a surrogate or placeholder for a API4KB knowledge object to control access to it. Applications of proxies are, e.g., virtual proxy (delaying the creation and initialization of expensive objects until needed, where the objects are created on demand, e.g. via factory design pattern), remote proxy (providing a local representation for an object that is in a different address space), protection proxies (where a proxy controls access to real subject methods, by giving access to some objects while denying access to others), smart reference proxy (e.g. providing a sophisticated access to certain objects). | * **Caching and Proxying**: A **Cache** stores recently used knowledge resources. Caches might be co-located with each client or located in a **Proxy**. Proxy provides a surrogate or placeholder for a API4KB knowledge object to control access to it. Applications of proxies are, e.g., virtual proxy (delaying the creation and initialization of expensive objects until needed, where the objects are created on demand, e.g. via factory design pattern), remote proxy (providing a local representation for an object that is in a different address space), protection proxies (where a proxy controls access to real subject methods, by giving access to some objects while denying access to others), smart reference proxy (e.g. providing a sophisticated access to certain objects). | ||
* **Mobile**: Mobile (executable) code that is downloaded to a client or mobile components/agents, which are running programs (both code and data/resources + state) that travel from one computer / environment to another | * **Mobile**: Mobile (executable) code that is downloaded to a client or mobile components/agents, which are running programs (both code and data/resources + state) that travel from one computer / environment to another | ||
- | ===== Description Schemas ===== | + | ===== Descriptions ===== |
A description is a particular kind of Knowledge Resource that provides essential characteristics of an API4KB entity. | A description is a particular kind of Knowledge Resource that provides essential characteristics of an API4KB entity. | ||
- | There are several key kinds of descriptions: | + | RDF is typically sufficient to express descriptions. |
- | - Descriptions of Knowledge Resources | + | |
- | - Descriptions of Knowledge Platform | + | The API4KB ontologies define a vocabulary in the API4KB namespace for use in descriptions. |
- | - Descriptions of Knowledge Platform Managers | + | |
+ | Foreign namespaces may also be used within descriptions. | ||
- | The (draft) schemas for these descriptions are shown below in matrix form. | + | Descriptions must be consistent with the metamodel (ontology), which provides restrictions on the domain, range and cardinality of properties in the API4KB namespace. |
+ | Descriptions adopt the semantics of RDF, especially the open-world assumption. This means that "violation" of a minimum cardinality restrictions in a description does not correspond to an inconsistency, but to either a lack of knowledge or a query for a partial description. | ||
==== Descriptions of Knowledge Resources ==== | ==== Descriptions of Knowledge Resources ==== | ||
- | ^ Key ^ Value ^ | + | These codes are used in the following tables. |
+ | ^ Code ^ Value ^ | ||
| Y | Yes (exactly 1) | | | Y | Yes (exactly 1) | | ||
| Y+ | Yes (1 or more) | | | Y+ | Yes (1 or more) | | ||
Line 97: | Line 99: | ||
| I[+?*] | Inherited and Indirectly Available| | | I[+?*] | Inherited and Indirectly Available| | ||
+ | These CURIE prefixes are used in the following tables. | ||
+ | ^ Abbreviation ^ Expansion ^ | ||
+ | | : | http: API4KB namespace here | | ||
+ | | ks: | :KnowledgeSource/ | | ||
+ | | kr: | :KnowledgeResource/ | | ||
+ | | ka: | kr:Asset/ | | ||
+ | | ke: | kr:Expression/| | ||
+ | | km: | kr:Manifestation/| | ||
+ | | ki: | kr:Item/ | | ||
+ | | lang: | :Language/ | | ||
+ | | map: | :Mapping/ | | ||
+ | | xsd: | http: XSD datatype namespace here | | ||
- | ^ Property ^Range ^ ka: ^ ke: ^ km: ^ ken: ^ kio: ^ ki: ^ | + | ^ Property ^ Range ^ ka: ^ ke: ^ km: ^ ki: ^ |
- | | level |ks:Level | ASSET | EXPRESSION | MANIFESTATION | ENCODING | IO | ITEM | | + | | :hasIdentifier | :Identifier | Y? | Y? | Y? | Y? | |
- | | :hasIdentifier | :identifier| Y? | Y? | Y? | Y? | Y? | Y? | | + | | :level | ks:Level | Y | Y | Y | Y | |
- | | :usesPerformative[1]|:Performative | Y* | Y* | Y* | Y* | Y* | Y* | | + | | :usesPerformative[1]| :Operation | I* | Y* | I* | I* | |
- | | :hasLocator |:Address | Y? | Y? | Y? | Y? | Y? | Y | | + | | :hasLocator | :Address | Y? | Y? | Y? | Y | |
- | | :usesLanguage |kr:Language | I+ | Y+ | I+ | I+ | I+ | I+ | | + | | :usesLanguage | :Language | I* | Y* | I* | I* | |
- | | :usesDialect |km:Dialect | N | N | Y+ | I+ | I+ | I+ | | + | | :usesDialect | km:Dialect | N | N | Y* | I* | |
- | | :usesFormat |ken:Format | N | N | N | Y+ | I+ | I+ | | + | | :usesConfiguration |ki:Configuration| N | N | N | Y* | |
- | | :usesConfiguration |ki:Configuration | N | N | N | N | Y+ | I+ | | + | | :accordingTo |lang:Environment| Y | N | N | N | |
- | | :accordingTo |:Environment | Y | N | Y | Y | N | N | | + | | :isBasic |xsd:boolean | Y | Y | Y | Y | |
- | | :isBasic |xsd:boolean | Y | Y | Y | Y | Y | Y | | + | | :hasMetadata |kr: | Y* | Y* | Y* | Y* | |
- | | :usesIOMode |:IOMode | N | N | N | N | Y+ | N| | + | | :hasDescription[3] |kr: | Y* | Y* | Y* | Y* | |
- | | :hasMetadata |:KnowledgeResource | Y* | Y* | Y* | Y* | Y* | Y*| | + | |
- | | :selfDescription[3] |:Description | Y? | Y? | Y? | Y? | Y? | Y?| | + | |
- | [1] Possible Performative values are Assertion, Retraction, Query, Result, ... | + | [1] A Performative is an operation that is expressed directly in the knowledge resource. Languages with this capability include Prolog, RuleML and DOL. A knowledge resource containing performatives is an "executable knowledge resource". |
- | [3] A self-description (of a knowledge resource) is a descripton embedded in the knowledge resource it is describing. It naturally inherits a number of properties from the knowledge resource being described, including level. Other properties are inherited unless overriden; e.g. language, dialect, format, storeConfig, IOMode, Metadata. | + | [3] The "hasDescription" property is a means to embedded information about the description in the description itself. Note that the subject of the ":hasDescription" property is the knowledge resource that the description is about, as named by the ":hasIdentifier" property. |
==== Descriptions of Knowledge Resources Property Values ==== | ==== Descriptions of Knowledge Resources Property Values ==== | ||
^ Property ^ Language ^ Dialect ^ Format ^ StoreConfig ^ Asset Environment ^ Type ^Level ^Performative ^Metadata[2] ^ | ^ Property ^ Language ^ Dialect ^ Format ^ StoreConfig ^ Asset Environment ^ Type ^Level ^Performative ^Metadata[2] ^ | ||
Line 129: | Line 141: | ||
[2] hasMetadata is itself a KnowledgeResource, and so extends the schema of some level of Knowledge Resource. | [2] hasMetadata is itself a KnowledgeResource, and so extends the schema of some level of Knowledge Resource. | ||
- | ==== Descriptions of Applications ==== | + | ==== Descriptions of Communicating Entities ==== |
- | ^ Property ^ Proxy ^ KP Manager ^ KP ^ Component ^ | + | ^ Property ^ Range ^ Node ^ Process ^ Object ^ Component ^ Service ^ Agent ^ |
- | | hasIdentifier | Y? | Y? | Y? | Y | | + | | hasIdentifier | :Identifier | Y? | Y? | Y | Y | Y? | Y? | |
- | | hasLocator | Y? | Y? | Y? | N | | + | | hasLocator | :Address | Y | Y? | Y? | N | Y | Y? | |
- | | interactsWith (KP manager) | Y* | N | Y? | N | | + | | interactsWith | :CommmunicatingEntity| Y?| Y+ | Y? | Y? | Y? | Y? | |
- | | interactsWith (Proxy) | Y* | Y* | N | N | | + | | fillsRole | :Role | Y+ | Y+ | Y+ | Y+ | Y+ | Y+ | |
- | | manages (KP) | I* | Y* | N | N | | + | |
- | | isSupportedBy (Component) | I* | I* | Y* | N | | + | |
- | | isManagedBy (KPM) | N | N | Y | N | | + | |
- | | fillsRole | I* | Y* | N | N | | + | |
- | | delegates (PublicOperation) | Y* | N | N | N | | + | |
- | | implements (PublicOperation) | I* | Y* | N | N | | + | |
- | | delegates (InternalOperation) | I* | I* | Y* | N | | + | |
- | | implements (InternalOperation) | I* | I* | I* | Y* | | + | |
- | ==== Descriptions of Applications Property Values ==== | + | ==== Descriptions of Communicating Entities Property Values ==== |
^ Property ^ Role ^ Proficiency ^ Operation ^ Event ^ | ^ Property ^ Role ^ Proficiency ^ Operation ^ Event ^ | ||
Line 153: | Line 157: | ||
| requiresProficiency | Y* | N | N | N | | | requiresProficiency | Y* | N | N | N | | ||
| exposesOperation | I* | Y+ | N | N | | | exposesOperation | I* | Y+ | N | N | | ||
- | | isPublic | N | N | Y | I | | ||
| isComposedOf (operation)| N | N | Y* | N | | | isComposedOf (operation)| N | N | Y* | N | | ||
| hasEvent | N | N | Y? | N | | | hasEvent | N | N | Y? | N | |