Role and Use of Ontologies in the Open Semantic Framework

Ontologies are to the Open Semantic Framework what humans were to the Mechanical Turk. The hidden human in the Mechanical Turk was orchestrating all and every chess move. However, to the observers, the automated chess machine was looking just like it: a new kind of intelligent machine. We were in 1770.

Ontologies plays exactly the same role for the Open Semantic Framework (OSF): they orchestrate all and every moves for all the pieces within OSF. They are what instructs structWSF, the Semantic Components, conStruct, and all other derivate pieces of user interfaces how to behave.

In this (lengthy) blog post, I will present the main ontologies that have an impact on different parts of OSF. We will see how different ontology classes and properties, and how the description of the records indexed in the system, can impact the behaviors of OSF.

In addition to this post, Mike has also published a blog post today that overviews the overall OSF ontology modularization and architecture.

Constituent Ontologies

Let’s take a look at the core ontologies used by the Open Semantic Framework. All these ontologies have been developed in relation to OSF. These, and other external ontologies, have the same role in OSF as the human does in the Mechanical Turk: they instruct the system how to behave.

Here is the list of the core ontologies:

  1. The SCO Ontology (Semantic Component Ontology)
  2. The WSF Ontology (Web Service Framework Ontology)
  3. The AGGR Ontology (Aggregation Ontology)
  4. The irON Ontology (Instance Record an Object Notation Ontology)
  5. One or more domain ontologies, to capture the concepts and relationships for the purposes of a given OSF installation, and
  6. Possibly UMBEL or other upper-level concept ontologies, used for linkages to external systems.

(Note: the internal wiki links to each of these ontologies also provides links to the actual ontology specifications on Github.)

A useful discussion of these ontologies and their interactions in an OSF instance is provided by the ontology modularization document. This current document focuses primarily on the specific properties and roles associated with them in an OSF installation.

Depending on the specific OSF installation, of course, multiple external ontologies may also be employed. Some of the common external ones used in an OSF installation are described by the external ontologies document. These external ontologies are important — indeed essential in order to ensure linkage to the external world — but have little to do with internal OSF control structures. That is why the rest of this discussion focused on internal ontologies only.

Summary Ontology Roles

Ontologies play pivotal roles across all parts of the framework. In a broad sense, the internal OSF ontologies are used for annotations, guiding interactions or relating concepts and information to other information. In specific terms, OSF ontologies may play one or more of these dozen or so roles:

  1. Define record descriptions
  2. Inform interface displays
  3. Integrate different data sources
  4. Define component selections
  5. Define component behaviors
  6. Guide template selection
  7. Provide reasoning and inference
  8. Guide content filtering (with and without inference)
  9. Tag concepts in text documents
  10. Help organize and navigate Web portals
  11. Manage datasets and ontologies, and
  12. Set access permissions and registrations.

In the remainder of this post, for each of these roles, we will see how ontologies affect numerous different parts of the OSF framework. These sections are presented in the order above.

Define Records Descriptions

A central role of ontologies in the Open Semantic Framework is their use to describe any kind of record that gets indexed and managed by the system. Since the framework indexes everything into the RDF data model, ontologies are needed as a schema to describe these RDF resources.

The irON ontology is specifically designed for record descriptions and notations. It interacts with all of the domain and (if used, UMBEL) upper level ontologies.

Inform Interface Displays

Ontologies have an impact in most of the user interfaces that display record information. The property that has the most impact is iron:prefLabel, which is used to display the label within the user interface that refers to a record or record attributes (properties). This label can be used within text, in a list control, in a tree control, or in any other kind of control that displays references to records.

Note: there are also other properties that are considered as fallbacks to iron:prefLabel if a record has no triples using the iron:prefLabel property. These include rdfs:label, dcterms:title, foaf:name, etc.

General User Interface Labels and Descriptions

There are a few properties that have an impact on most of the components of the OSF stack, most of which come from the irON ontology. Here is the list of these irON properties that impact other parts of the system, mainly related to different user interfaces:

irON Property Impact on the different user interfaces
iron:prefLabel Preferred label to refer to an instance record or specific attribute (property)This impacts most of the user interfaces. As soon as a record is described using this property, the user interface uses it to refer to that record (as a link, in a list, as a word, etc.)
iron:altLabel Alternative label to refer to an instance record or specific attribute (property)This impacts most of the user interfaces. As soon as a record is described using this property, and that the user interface needs more than one label to refer to that record, it is displayed in the user interface (as a link, in a list, as a word, etc.)
iron:hiddenLabel Hidden label are labels that shouldn’t be displayed in any user interface, but that may be used by different systems for indexing purposesThis impacts on different indexation system such as Scones. As soon as a record is described using this property, and that a system needs more words (synonyms) to use to describe that record, but that label shouldn’t be displayed in any user interface, these hidden labels will be used.
iron:description Description of an instance record.This impacts most of the user interfaces. As soon as a record is described using this property, and that the user interface needs a description to refers to that record, it will be displayed in the user interface (as a link, in a list, as a word, etc.)
iron:prefURL Preferred URL for an instance recordThis impacts most of the user interfaces. As soon as a record is described using this property, and that the user interface needs a web page URL to refer to that record, it will be displayed in the user interface (as a link)

User Interface ‘Short’ Labels

There are a few properties that impact most of the components of the OSF stack. Here is the list of SCO properties that impact other parts of the system, mainly related to different user interfaces:

SCO Property Impact on the different user interfaces
sco:shortLabel The short label is used to display a short version of the label of an attribute/type where it has to be displayed in a restrained region of a component.This impacts multiple different kinds of user interfaces (including the semantic components) in the way that if the user interface knows that the place available to display the label is limited, it will utilize the sco:shortLabel value before any other label values that may be defined for that record.

Hierarchical Displays

The way ontologies define a class or a property structure also has an impact on different kinds of hierarchical displays. An example of this is the “Filter by Kinds” section of the structSearch and structBrowse modules. The possible filters that may be applied to a search query will be displayed to the user according to the hierarchy as defined in the ontologies.

Integrate Heterogeneous Data Sources

The principle reason why the Open Semantic Framework uses RDF and ontologies to describe all the data it indexes and manages is to facilitate data integration from multiple and heterogeneous data sources. The premise of using RDF and ontologies is:

The RDF framework, along with using ontologies as schema, is the most flexible means currently available to describe any kind of data. The RDF-ontology combination can be used to represent any data coming from any other source, data management system, format, or unstructured to structured basis for describing information. (See further the Advantages and Myths of RDF.)

This foundation leads to the extreme flexibility of the Open Semantic Framework. The rationale behind this flexibility, and its benefits, has been described in many locations within this wiki. You may also want to see this article on One of the Semantic Web's Core Added Value.

Ontologies have a dramatic — and positive — impact on the data integration and presentation tasks within an OSF instance.

Define Component Selections

A key aspect of the SCO Ontology is its use as the means to define what semantic components (or widgets) display what types of information within data records.

These assignments are done via the sControl component. The properties for this component define what components may display what type (class) of data records. Here is the list of SCO properties that impact the sControl’s behaviors:

SCO Property Impact on the sControl component
sco:displayControl Annotate a class or a property to reference it to a display control. This indicates what are the semantic components that can normally be used to display some information about a record of a certain type, or a record that is described using some property.This property impacts the behavior of the sControl component in the sense that for a given record’s description, and a given ontology, the sControl component will select different semantic controls for displays. The actual information displayed and with what widget(s) depends on the type of the record and the properties that are used to describe it.
sco:comparableWith Is is possible to specify a “comparableWith” relation between two predicates. These comparable attributes have the same allowedValue(s), and the semantics of the predicates that are deemed comparable are the same. Since the kinds of values, and their semantics, are the same, they are then considered comparable.This property is normally applied when it is desirable, for example, to plot values of different attributes describing similar records on some visualization component (for example, a linear chart).This property impacts the behavior of the sControl component in the sense that for a given record’s description, and a given ontology, the sControl component will display information about multiple input records depending if the value of some of the properties used to describe it are comparable.

Define Component Behaviors

In the Open Semantic Framework, one of the most important roles of ontologies is to define the interaction between different pieces of the system. Because of the extent of these interactions, this section is the longest and most detailed amongst all of the dozen or so ontology roles.

The SCO ontology can have multiple effects on multiple parts of an OSF instance. This section describes those interactions.

sMap Component

The sMap component had different behaviors depending on how its input record is described. Here is the list of SCO properties that will have an impact on the sMap’s behaviors:

SCO Property Impact on the sMap component
sco:gisMap Reference a map binary file created created from a ShapeFile map file and ClearMapsBuilder. The referenced map file is a serialized ActionScript object.The sco:gisMap defines the first layout that is related to a given resource. Normally, this resource is part of the map related by the gisMap predicate. Read more about maps in the sMapdocumentation page.There is only one gisMap relationship per resource, other relationships should be made with the sco:relatedGisMappredicate.This property impacts the behavior of the sMap component in the sense that it is the record’s description, and is the property that tells the component what map to render to the user.
sco:relatedGisMap Reference a map binary file created created from a ShapeFile map file and ClearMapsBuilder. The referenced map file is a serialized ActionScript object.The sco:relatedGisMap defines a related map layout that is related to a given resource. The resource is related to that map layer in some ways, but it is not necessarily part of the layer. Read more about maps in the sMapdocumentation page.This property impacts the behavior of the sMap component in the sense that it is the record’s description, and is the property that tells the component what map to render to the user.

sWebMap Component

The sWebMap component has different behaviors depending on how its input record is described. Here is the list of SCO and WGS84 properties that impact the behavior of an sWebMap:

SCO/WGS84 Property Impact on the sWebMap component
sco:polygonCoordinates Defines the coordinates of a polygon shape that represents a geographic area determined by a record.Coordinates are defined as coordinates in KMLThis property impacts the behavior of the sWebMap component in the sense that for a given resultset of records, polygon shapes are displayed on a World map for each of the records described with the property.
sco:polylineCoordinates Defines the coordinates of a polyline shape that represents a record on a map.Coordinates are defined as coordinates in KMLThis property impacts the behavior of the sWebMap component in the sense that for a given resultset of records, polylines are displayed on a World map for each of the records described with the property.
sco:mapMarkerImageUrl URL of an icon image to use as a marker on a web map. Normally, this property is used to annotate a Class description. All of the records belonging to that class are marked on a map using this icon image.This property impacts the behavior of the sWebMap component in the sense for a given resultset of records, and a given ontology description, all records of a given type of class that are displayed with the marker icon found at the URL specified for sco:mapMarkerImageUrl.
wgs84:lat Latitude coordinate of a record on a World map.This property impacts the behavior of the sWebMap component in the sense for a given resultset of records, each record with a wgs84:lat property is displayed on the sWebMap at that latitude coordinate.
wgs84:long Longitude coordinate of a record on a World map.This property impacts the behavior of the sWebMap component in the sense for a given resultset of records, each record with a wgs84:long property is displayed on the sWebMap at that longitude coordinate.
wgs84:alt Altitude of a record on a World map.This property impacts the behavior of the sWebMap component in the sense for a given resultset of records, each record with a wgs84:alt property is displayed on the sWebMap at that altitude indicator.

sStory Component

The sStory component has different behaviors depending on how its input record is described. Here is the list of SCO properties that impact an sStory component:

SCO Property Impact on the sStory component
sco:storyUrl URL reference to a webpage representation of the story that got indexed into Scones.This property impacts the behavior of the sStory component in the sense that for a given record’s description, the sStory component refers users to the original webpage URL that got processed by Scones and is displayed in the sStory component.
sco:storyTextUri URI reference to the text of a storyThis property impacts the behavior of the sStory component in the sense that for a given record’s description, the sStory component uses the text document referenced by this property to display in the text display of the sStory component.
sco:storyAnnotatedTextUri URI reference to the annotated text of a story. Annotations are serialized in XML given the GATEformat.This property impacts the behavior of the sStory component in the sense that for a given record’s description, the sStory component usesw the Gate annotated text document referenced by this property to display the tagged concepts in the tags section of the sStory viewer, and also uses it to highlight the tagged terms within the text viewer.

sBarChart and sLinearChart Components

The sBarChart and the sLinearChart components exhibit different behaviors depending on how the input records that are enabled for these component types are described. Here is the list of the SCO properties that impact this behavior:

SCO Property Impact on the sBarChart and the sLinearChart components
sco:comparableWith Is is possible to specify a “comparableWith” relation between two predicates. These comparable attributes have the same allowedValue(s), and the semantics of the predicates that are deemed comparable are the same. Since the kinds of values, and their semantics, are the same, they are then considered comparable.This property is normally applied when it is desirable, for example, to plot values of different attributes describing similar records on some visualization component (for example, a linear chart).This property impacts the behavior of the sLinearChart component in the sense that for a given record’s description, and a given ontology, the sLinearChart component will display the values of the comparable attributes on the a linear chart.
sco:unitType URI reference to a unit type ontology. The sco:unitType property is used to determine the type of unit referenced by a property. For example, if a data property has xsd:float as range, then sco:unitTypedetermines what kind of things referred to by this number.The semantic components make all of the properties that share the same sco:unitTypecomparable (so, possibly displayable on the same semantic component, such as the sBarChart and the sLinearChart).This property impacts the behavior of the sLinarChart and the sBarChart component in the sense that for a given record’s description, and a given ontology, the sLinarChart or the sBarChart can be selected and used to display the values with the same unit type on one of these charts.
sco:orderingValue The value of the sco:orderingValue predicate is used to order the predicate of a set of comparable predicates. This set of comparable predicates is normally created from the set composed of all compatibleWithpredicates. This is normally used to plot, and order, values of different attributes describing similar records on some visualization component (for example, a linear chart).This property impacts the behavior of the sLinarChart and the sBarChart component in the sense that for a given record’s description, and a given ontology, the sLinarChart or the sBarChart will order the values of comparable properties on the charts, according to the ordering value defined for each property.

sRelationBrowser

The sRelationBrowser component exhibits different behaviors depending on how its input record is described. Here is the list of SCO properties that impact the sRelationBrowser component:

SCO Property Impact on the sRelationBrowser component
sco:relationBrowserNodeType Reference to a relation browser node type used to skin a node according to its type. This should be a reference to a type URI defined in a relation browse nodes skins configuration file. If a record is defined with this property, the relation browser tries to find a node of that type to apply to it as a skin.This property impacts the behavior of the sRelationBrowser component in the sense that for a given record’s description, and a given ontology, the sRelationBrowser component uses the skin specified by the sco:relationBrowserNodeType attribute to display the record in the sRelationBrowser component.

sDashboard

The sDashboard component exhibits different behaviors depending on how its input record is described. Here is the list of SCO properties that impact the sDashboard component:

SCO Property Impact on the sDashboard component
sco:dashboardSessionFileUri URI reference to the Dashboard session accessible on the Web.This property impacts the behavior of the sRelationBrowser component in the sense that for a given record’s description, and a given ontology, the sDashboard component loads the Dashboard session referenced by this property.

Guide Visualization Template Selection

One of the core features of the conStruct set of Drupal modules is the ability to use different display templates depending on the types of records available. The selection of these templates is based on the types of those records and the type hierarchies described by the OSF ontologies. This section describes how these ontologies guide template selections.

As a refresher on templates and their use, see the Building conStruct Templates document. It describes how the templating engine works and how to create various templates.

Template Selection

Template selection is the action of binding an instance record to a display template based on its type. Three things are required to make this happen:

  1. Instance records have to be typed
  2. An ontological structure of type relationships (via subClasses) has to exist in one or more OSF ontology(ies), and
  3. A template has to exist for the type of the instance record.

(Note: a specific template by type is not strictly required, since lacking a specific template for the target type, the system will invoke the nearest template up the parental chain in the governing ontology structure, eventually getting to the most generic template available, that for “thing”.)

Impact of Ontologies on Template Selection

conStruct’s templating engine selects record display templates based on the class hierarchy loaded on a OSF instance. It also uses inference on types to select the proper template for a given record.

Let’s say that we try to display information about a foaf:Person instance record. What the system attempts to do is to find a template that displays information about this kind of instance record. First, the foaf:Person type (class) has to be defined in the ontological structure of the OSF instance; if it is not, then no specific template will be selected and the system will default to using the owl_thing.html template (see below). If the type (class) is found, the system will next check to see if a template exists for that specific type. If one exists one, it will use the matching template. If one does not, it will next select the parent class of the type and try the match again. If it again fails, it will continue its test up the parental chain. If all tests fail, it will use the default owl_thing.html template. Whichever template is selected then becomes the basis for formatting and presenting the visual record display.

We can use a simple class hierarchy, matched to a simple set of available template files, to illustrate how ontologies impact the conStruct templating system.

Loaded Class Hierarchy Available template files
owl:Thing
   |
   |
    --> foaf:Agent
            |
            |
            |--> foaf:Person
            |
            |
             --> foaf:Organization
  owl_thing.tpl
  foaf_agent.tpl
  foaf_organization.tpl

Now, let’s say that our OSF portal is about to display information about a foaf:Person record. As we can notice, there is no foaf_person.tpl template available for a foaf:Person. However, because of the ontology structure, the system next attempts to select a template from a parent class of that foaf:Person.

What the system would do is to check if there is a template available for a record of type foaf:Person. Since there is none, it would try to find one for a parent type, so in this case the foaf:Agent class. In our example, there is now a match. The templating engine thus uses the foaf_agent.tpl template to display information about the foaf:Person record.

Were the foaf_agent.tpl not to exist, then the templating engine would fall back to the owl_thing.tpl template, which is considered to be the “generic record display template”, or the template of last resort.

This design means that if:

  1. the ontological structure changes over time, or
  2. new templates get added to the system

then there may be an impact on how the record gets displayed.

The major advantage of this design is that more and more specific formatting templates may be added to an OSF installation over time, both improving the tailored look of results displays and accommodating more structure and relationships as they evolve.

Provide Reasoning and Inference

A standard use of ontologies is for reasoning and inference, and those used by OSF are no exception.

By extension, however, we can also use these same capabilities to check on data consistency and coherence. This is an important feature of the system since the system can detect if there are logical inconsistencies or logical incoherencies that have been developed by the system administrator during ontology growth and development. Having coherent and consistent ontologies means that we have the proper foundations to create consistent and coherent datasets of instance records.

See further the discussion on reasoning using Protégé.

Guide Content Filtering

Filtering data is the action of getting a subset of records from a complete dataset based on some selection criteria. In OSF, the predominant share of filtering is done using the structWSF Search Web service endpoint. The a minority of filtering is done using the SPARQL endpoint. It is also possible to filter via the AGGR aggregation ontology.

Possible filtering criteria for the Search endpoint are:

  1. Filtering by type(s)
  2. Filtering by attribute(s)
  3. Filtering by attribute(s)/value(s)
  4. Filtering by geo-localization (within a given geographical area)

These filtering activities are performed by different tools of the stack, such as:

  • structSearch
  • structBrowse
  • sWebMap

These tools are impacted by the definition of the loaded ontologies. The filtering of the values by types, attributes and attributes/values requires an ontology class or an ontology property as filtering criteria.

Filtering with Inference

Also, the any Search query can be performed with inference enabled. Just like with the template selection section noted above, inference can have a big impact on the number and nature of returned results. Let’s consider this example class structure:

Loaded Class Hierarchy Indexer Records
owl:Thing
   |
   |
    --> bibo:Document
            |
            |
            |
             --> bibo:Image
                     |
                     |
                     |--> muni:HeritageImage
                     |        |
                     |        |
                     |         --> muni:ParkHeritageImage
                     |
                     |
                     |--> muni:NeighborhoodImage
                     |
                     |
                     |
                      --> muni:ParkImage
  <1> a bibo:Image .
  <2> a muni:HeritageImage .
  <3> a muni:HeritageImage .
  <4> a muni:ParkHeritageImage .
  <5> a muni:ParlImage .

This class structure shows a hierarchy of images where the leaf classes are topical image classes (so classes where their individuals are considered images representing one of the topic: Heritage, Neighborhood and Park). Now let’s see how this class structure impacts Search queries, and returned results, by different tools (structSearch, structBrowse, sWebMap and others).

Here is a series of Search queries sent to a structWSF instance that has this class hierarchy loaded, using the sample specification noted above. This tables shows the results potentially returned by the Search endpoint with and without inferencing turned on:

Use Case Type Filter Inference Returned Results
#1 muni:HeritageImage Off
<2> a muni:HeritageImage .
<3> a muni:HeritageImage .
#2 muni:HeritageImage On
<2> a muni:HeritageImage .
<3> a muni:HeritageImage .
<4> a muni:ParkHeritageImage .
#3 bibo:Image Off
#4 bibo:Image On
<1> a bibo:Image .
<2> a muni:HeritageImage .
<3> a muni:HeritageImage .
<4> a muni:ParkHeritageImage .
<5> a muni:ParlImage .

In the Use Case #1, the user requests all of the muni:HeritageImages without inferencing. This means that the Search endpoint will return all of the records that have been typed as muni:HeritageImage. In this case, the records <2> and <3> got returned.

Use Case #2 is a variant of Use Case #1, only now with inferencing enabled. In this use case, the Search endpoint will return all the muni:HeritageImage and all the records that are typed with one of its subtypes (in this case, muni:ParkHeritageImage). For this query, records <2>, <3> and <4> got returned. This case shows where ontologies can have a dramatic impact on the system. If we modify that class hierarchy and put the muni:ParkHeritageImage as being a sub-class-of bibo:Image, then the same results would be returned for Use Case #2 than we got with Use Case #1.

With Use Case #3, the endpoint does not return any results because inferencing is disabled, and because there is no record typed as bibo:Image.

Use Case #4 is a variant of Use Case #3 where inferencing is enabled. The endpoint returns all the image records because all of them are bibo:Image by inference on type.

Filtering via the AGGR Ontology

The AGGR Ontology also has an impact on anything that displays facets of filtered searches. Amongst others, it impacts the structSearch and structBrowse conStruct modules. It also impacts different user interfaces that use the Search Web service endpoint to perform auto-completion tasks.

Tag Concepts in Text Documents

In the Open Semantic Framework, the Scones Web service endpoint is what is used to analyze unstructured text documents, then turning them into semi-structured text documents by automatically tagging concepts. The concept tagging takes place using ontology-based information extraction, or OBIE. Named entity dictionaries are the basis for entity tagging.

These concepts used for the tagging come from selected ontologies loaded on the system. The way these ontologies have been created, and the way the classes and named individuals have been defined, has a dramatic impact on the quality of the documents tagged by Scones.

Scones uses two things from ontologies:

  • its classes
  • its named individuals

Depending on settings, one or both of these sources may be used for scones tagging.

There are a few properties intimately related to the Scones Web service endpoint:

Properties Impact on Scones
iron:prefLabel Preferred label to refer to an instance record.This property impacts the behavior of the Scones tagger in the sense that the value of the iron:prefLabel property is used to detect and tag as a reference the corresponding class or named individual.
iron:altLabel Alternative label to refer to an instance record.This property impacts the behavior of the Scones tagger in the sense that the value(s) of the iron:altLabel property is used to detect and tag as a reference the corresponding class(es) or named individual(s).
iron:hiddenLabel Hidden label are labels that are not displayed in any user interface, but may be used by different systems for indexing purposes (such as for recognizing misspellings).This property impacts the behavior of the Scones tagger in the sense that the value(s) of the iron:hiddenLabel property is used to detect and tag as a reference the corresponding class(es) or named individual(s). As we saw above, hidden labels are not displayed in user interfaces. However, they are used to specify variations in the way some of the other labels may be written. These hidden labels are explicitly used by the Scones tagger.
sco:namedEntity Specifies if a resource can be considered a named entity. Literal value: “true” or “false”.This property impacts the behavior of the Scones tagger in the sense that all of the records with the sco:namedEntity property set to trueare automatically added by the Scones endpoint to its Named Entities Dictionaries.This means that all the records that are specified to be named entities will be used by Scones to tag any input text documents.

Help Navigate and Organize Web Portals

In OSF, ontologies also have an impact on the general organization of a Web portal and how it is navigated.

Portal Navigation

In an OSF portal, its domain ontologies use the sRelationBrowser for general navigation. The relation browser is a tool that lets users dynamically navigate a graph (that is, nodes with arcs that links these nodes). The most widespread usage of the relation browser is to let users navigate the links between ontology concepts. These concepts are the anchor points of what other content is available on the Web portal. By navigating the concepts (classes) structure, users are able to explore an OSF portal’s entire content.

Each node in the sRelationBrowser semantic component is linked to whatever other kinds of related records exist in the system. Depending on the types of those records, other semantic components can then be invoked to display this tightly related content for each node.

Ontologies thus impact navigation and discovery on an OSF portal in two ways:

  1. They impact the navigation of the structure by defining which concepts are linked to other concepts and with what property
  2. They define what related records may get displayed to the user based on their classes and properties.

Layouts Organization

OSF Web portals are mainly organized by Layouts. A layout is a specific page presentation format with specific design, components and ordering and sizing of those components. This page presentation is highly influenced by the kind of things indexed in the system. Generally, layouts present records of a certain type (or family of types), along with specialized functions that users are able to use to perform different actions on that set of records.

Here are a few examples of such layouts:

These layouts aggregate all of the records of a certain type (like images of all kinds), display them using different kind of tools (like an Images Gallery), and filter them depending on different filtering criteria (like mapping the position where each image got captured, on a map, within a specific neighborhood area).

The ontologies impact the general organization of the Web portal because of the kind of things that are indexed in the system interacting with the available layouts.

Manage Datasets and Ontologies

Basic settings for managing datasets and ontologies is provided by the WSF Ontology. It presently does so via two mechanisms.

Datasets Syncing Framework

The Datasets Syncing Framework behaves differently depending on the value of the wsf:crudAction property for each input record.

WSF Property Impact on the DSF
wsf:crudAction States the CRUD action that should be used to index a given record into structWSF. This property is used by the Datasets Syncing Framework to determine if the record feed to it should be created, deleted or updated.The value of this property can be one of:(1) create (2) update (3) deleteThis property impact the behavior of the DSF in the sense that it is the record’s description, using this property that will tells the framework how to behave (create, delete or update) toward the input record. If nothing is specified, the record will simply be ignored.

structOntology

The structOntology conStruct module exhibits different behavior depending on the value of the wsf:ontologyModified property for each input ontology description.

WSF Property Impact on the DSF
wsf:ontologyModified States if an ontology has been modified since the last time it got saved on the file system of the OSF server instance.This property impacts the behavior of the structOntology module in the sense that if, for an input ontology, the description of that ontology states that this property is “true”, then it will notify the user via its loaded ontologies list that the ontology has been modified, and that it has not yet been saved.

Set Access Permissions and Registrations

The WSF Ontology also has a principal purpose to describe the internal state of a structWSF instance such as the internal access control records, the datasets descriptions, the registered web service endpoints, etc. As a result, this ontology can have multiple effects on other parts of an OSF instance.

The WSF Ontology is used to describe three main areas of a structWSF installation:

  1. datasets registry
  2. access definition registry
  3. registered web services endpoints registry

These registries are hosted in some specialized datasets in the triple store (Virtuoso for most OSF installations). The information indexed in these different registries is defined using the WSF ontology.

All structWSF Web services are affected by these registries.

0 Responses to “Role and Use of Ontologies in the Open Semantic Framework”


  1. No Comments

Leave a Reply






This blog is a regularly updated collection of my thoughts, tips, tricks and ideas about my semantic Web researches and related software development.


RSS Twitter LinkedIN


Follow

Get every new post on this blog delivered to your Inbox.

Join 64 other followers:

Or subscribe to the RSS feed by clicking on the counter:




RSS Twitter LinkedIN