CTS2-LE Building Blocks: Unterschied zwischen den Versionen

Aus CTS2-LE
Zur Navigation springen Zur Suche springen
(Terminology Editing and Processing)
 
Zeile 1: Zeile 1:
 
== CTS2-LE Layered Architecture ==
 
== CTS2-LE Layered Architecture ==
[[Datei:CTS2-LE Layers.png|320px|right]] CTS2-LE Terminology Server utilizes semantic technologies for representing, providing and processing CTS2 artefacts. The main benefits of this approach are
+
[[Datei:CTS2-LE Layers.png|320px|right]] CTS2-LE Terminology Server utilizes semantic technologies for representing, providing and processing artefacts. The main benefits of this approach are
 
* the conceptual nearness to the nature of the artefacts to store, namely controlled vocabularies and its derivate artefacts,
 
* the conceptual nearness to the nature of the artefacts to store, namely controlled vocabularies and its derivate artefacts,
 
* semantic processing and querying in a direct way, and
 
* semantic processing and querying in a direct way, and
 
* to be able to manage a huge amount of linked medical data.
 
* to be able to manage a huge amount of linked medical data.
  
Concretely, CTS2-LE store is based on the Jena Framework  plus additional components for searching and constraining the RDF base. The system components and its functionality are explained bottom to top with the help of the overall system architecture shown in the figure to the rigth. The persistence layer is split into two storage systems, namely a full text index for performant search (Lucene) and the RDF (quad )store (Jena-TDB) for holding all CTS2 artefacts as RDF graphs. As the system backbone the Jena Framework is used, which offers rich functionality to process and maintain the RDF graphs on a basic level.
+
Concretely, the store is based on the Jena Framework  plus additional components for searching and constraining the RDF base. The system components and its functionality are explained bottom to top with the help of the overall system architecture shown in the figure to the rigth. The persistence layer is split into two storage systems, namely a full text index for performant search (Lucene) and the RDF (quad )store (Jena-TDB) for holding all artefacts as RDF graphs. As the system backbone the Jena Framework is used, which offers rich functionality to process and maintain the RDF graphs on a basic level.
 
The Jena Framework is enhanced by some components in order to comfortably handle the (possible huge amount of) artefacts. CTS2-LE
 
The Jena Framework is enhanced by some components in order to comfortably handle the (possible huge amount of) artefacts. CTS2-LE
 
* explicitly partitions the whole RDF graph by means of the so-called named graphs feature,
 
* explicitly partitions the whole RDF graph by means of the so-called named graphs feature,
 
* contains a lightweight SPARQL template mechanism and engine, and
 
* contains a lightweight SPARQL template mechanism and engine, and
* introduces a schema language for RDF graphs together with a validation component in order to ensure that all data is valid with respect to the CTS2 information model.
+
* introduces a schema language for RDF graphs together with a validation component in order to ensure that all data is valid with respect to the FHIR/CTS2 information model.
  
  
[[Datei:Sparql and rdf.png|200px|right]]The tier above Jena (CTS2-LE-BL) contains all CTS2-specific functionality and mainly uses SPARQL-Templates. At this tier customized vocabulary loaders are located which, for instance, transform ClaML-defined vocabularies such as ICD and OPS to RDF structures. Web-CTS2-LE is the component for handling REST calls aligned to the FHIR specification. CTS2-LE provides an so-called CTS2-Navigator to browse and search vocabularies as well as retrieving similar concepts based on the vector space model of Lucene.
+
[[Datei:Sparql and rdf.png|200px|right]]The tier above Jena (CTS2-LE-BL) contains all specific functionality and mainly uses SPARQL-Templates. At this tier customized vocabulary loaders are located which, for instance, transform ClaML-defined vocabularies such as ICD and OPS to RDF structures. Web-CTS2-LE is the component for handling REST calls aligned to the FHIR specification. CTS2-LE provides an so-called Navigator to browse and search vocabularies as well as retrieving similar concepts based on the vector space model of Lucene.
  
 
The figure to the right shows some essential components. At the bottom the RDF graph is partitioned such that every vocabulary is represented by a named graph for better handling the exchange of vocabularies as a whole. Above that tier the main work is done by the Jena SPARQL engine for accessing and processing vocabularies and its corresponding artefacts such as value sets and mappings.  
 
The figure to the right shows some essential components. At the bottom the RDF graph is partitioned such that every vocabulary is represented by a named graph for better handling the exchange of vocabularies as a whole. Above that tier the main work is done by the Jena SPARQL engine for accessing and processing vocabularies and its corresponding artefacts such as value sets and mappings.  
  
So-called RDF signatures are used to define a constraining RDF schema according to the CTS2 information model.  Moreover, this F-Logic oriented RDF schema definition for CTS2 is helpful in formulating SPARQL queries, since it directly reflects the RDF graph structure. Validating store content according to these schemata is mainly done by means of the SPARQL engine. Furthermore, lightweight SPARQL templates can be defined to support reuse of queries by parameterization.
+
So-called RDF signatures are used to define a constraining RDF schema according to the FHIR/CTS2 information model.  Moreover, this F-Logic oriented RDF schema definition is helpful in formulating SPARQL queries, since it directly reflects the RDF graph structure. Validating store content according to these schemata is mainly done by means of the SPARQL engine. Furthermore, lightweight SPARQL templates can be defined to support reuse of queries by parameterization.
  
== Terminology Editing and Processing ==
+
As sketched above, CTS2-LE manages all terminology artifacts as FHIR/CTS2-compliant RDF graphs using a RDF (quad )store. By wrapping these data managing component with a powerful SPARQL engine, a generic and standards-based interface is provided that allows to place enhanced semantic data access and processing services on top of the core data managing engine. A complementary Lucene index is is utilized for gaining outstanding search performance.  
As sketched above, CTS2-LE manages all terminology artifacts as CTS2-compliant RDF graphs using a RDF (quad )store. By wrapping these data managing component with a powerful SPARQL engine, a generic and standards-based interface is provided that allows to place enhanced semantic data access and processing services on top of the core data managing engine. A complementary Lucene index is is utilized for gaining outstanding search performance.  
 
  
 
<!--
 
<!--

Aktuelle Version vom 18. Januar 2022, 18:55 Uhr

CTS2-LE Layered Architecture

CTS2-LE Layers.png

CTS2-LE Terminology Server utilizes semantic technologies for representing, providing and processing artefacts. The main benefits of this approach are

  • the conceptual nearness to the nature of the artefacts to store, namely controlled vocabularies and its derivate artefacts,
  • semantic processing and querying in a direct way, and
  • to be able to manage a huge amount of linked medical data.

Concretely, the store is based on the Jena Framework plus additional components for searching and constraining the RDF base. The system components and its functionality are explained bottom to top with the help of the overall system architecture shown in the figure to the rigth. The persistence layer is split into two storage systems, namely a full text index for performant search (Lucene) and the RDF (quad )store (Jena-TDB) for holding all artefacts as RDF graphs. As the system backbone the Jena Framework is used, which offers rich functionality to process and maintain the RDF graphs on a basic level. The Jena Framework is enhanced by some components in order to comfortably handle the (possible huge amount of) artefacts. CTS2-LE

  • explicitly partitions the whole RDF graph by means of the so-called named graphs feature,
  • contains a lightweight SPARQL template mechanism and engine, and
  • introduces a schema language for RDF graphs together with a validation component in order to ensure that all data is valid with respect to the FHIR/CTS2 information model.


Sparql and rdf.png

The tier above Jena (CTS2-LE-BL) contains all specific functionality and mainly uses SPARQL-Templates. At this tier customized vocabulary loaders are located which, for instance, transform ClaML-defined vocabularies such as ICD and OPS to RDF structures. Web-CTS2-LE is the component for handling REST calls aligned to the FHIR specification. CTS2-LE provides an so-called Navigator to browse and search vocabularies as well as retrieving similar concepts based on the vector space model of Lucene.

The figure to the right shows some essential components. At the bottom the RDF graph is partitioned such that every vocabulary is represented by a named graph for better handling the exchange of vocabularies as a whole. Above that tier the main work is done by the Jena SPARQL engine for accessing and processing vocabularies and its corresponding artefacts such as value sets and mappings.

So-called RDF signatures are used to define a constraining RDF schema according to the FHIR/CTS2 information model. Moreover, this F-Logic oriented RDF schema definition is helpful in formulating SPARQL queries, since it directly reflects the RDF graph structure. Validating store content according to these schemata is mainly done by means of the SPARQL engine. Furthermore, lightweight SPARQL templates can be defined to support reuse of queries by parameterization.

As sketched above, CTS2-LE manages all terminology artifacts as FHIR/CTS2-compliant RDF graphs using a RDF (quad )store. By wrapping these data managing component with a powerful SPARQL engine, a generic and standards-based interface is provided that allows to place enhanced semantic data access and processing services on top of the core data managing engine. A complementary Lucene index is is utilized for gaining outstanding search performance.