Hi Martynas,

 

OWL 2 relaxed some of the previous constraints by introducing punning. So,
an instance of a class could also be a class and still be handled by OWL DL
reasoners. 

 

Having said this, there are very few DL reasoners and most of the real world
reasoning is done with rule-based inference engines. In recognition of this,
one of the most important aspects of OWL 2 was defining OWL profiles that
specified different subsets of OWL based on the real world situations and
use cases http://www.w3.org/TR/owl2-profiles/. 

 

In effect, what W3C found out was that dividing OWL into Lite, DL and Full
had little practical meaning. So, with profiles they came up with a
different way to divide OWL into sublanguages - a way that was grounded in
actual applications of reasoning:

 

"An OWL 2 profile (commonly called a fragment or a sublanguage in
computational logic) is a trimmed down version of OWL 2 that trades some
expressive power for the efficiency of reasoning. This document describes
three profiles of OWL 2, each of which achieves efficiency in a different
way and is useful in different application scenarios. The choice of which
profile to use in practice will depend on the structure of the ontologies
and the reasoning tasks at hand. 

*       OWL 2 EL is particularly useful in applications employing ontologies
that contain very large numbers of properties and/or classes. This profile
captures the expressive power used by many such ontologies and is a subset
of OWL 2 for which the basic reasoning problems can be performed in time
that is polynomial with respect to the size of the ontology [EL++
<http://www.w3.org/TR/owl2-profiles/#ref-ELpp> ] (see Section 5
<http://www.w3.org/TR/owl2-profiles/#Computational_Properties>  for more
information on computational complexity). Dedicated reasoning algorithms for
this profile are available and have been demonstrated to be implementable in
a highly scalable way. The EL acronym reflects the profile's basis in the EL
family of description logics [EL++
<http://www.w3.org/TR/owl2-profiles/#ref-ELpp> ], logics that provide only
Existential quantification. 
*       OWL 2 QL is aimed at applications that use very large volumes of
instance data, and where query answering is the most important reasoning
task. In OWL 2 QL, conjunctive query answering can be implemented using
conventional relational database systems. Using a suitable reasoning
technique, sound and complete conjunctive query answering can be performed
in LOGSPACE with respect to the size of the data (assertions). As in OWL 2
EL, polynomial time algorithms can be used to implement the ontology
consistency and class expression subsumption reasoning problems. The
expressive power of the profile is necessarily quite limited, although it
does include most of the main features of conceptual models such as UML
class diagrams and ER diagrams. The QL acronym reflects the fact that query
answering in this profile can be implemented by rewriting queries into a
standard relational Query Language. 
*       OWL 2 RL is aimed at applications that require scalable reasoning
without sacrificing too much expressive power. It is designed to accommodate
OWL 2 applications that can trade the full expressivity of the language for
efficiency, as well as RDF(S) applications that need some added
expressivity. OWL 2 RL reasoning systems can be implemented using rule-based
reasoning engines. The ontology consistency, class expression
satisfiability, class expression subsumption, instance checking, and
conjunctive query answering problems can be solved in time that is
polynomial with respect to the size of the ontology. The RL acronym reflects
the fact that reasoning in this profile can be implemented using a standard
Rule Language. "

If you are thinking of reasoning over the models you are defining,  I
recommend that you think in terms of an OWL profile that is most suitable
for the type of applications you are considering. Which bring me to a
question - what type of reasoning are you expecting to do over templates?

 

Regards,

 

Irene

 

From: [email protected]
[mailto:[email protected]] On Behalf Of [email protected]
Sent: Saturday, April 06, 2013 1:02 PM
To: [email protected]
Subject: [topbraid-users] Semantics of spin:Template

 

Hey all,

I am about to design a Template meta-class semantically very similar to
spin:Template (although in a different domain).

I have a question about SPIN ontology design. spin:Template is defined like
this (shortened):

  spin:Template a rdfs:Class ;
    rdfs:comment "The metaclass of SPIN templates. Templates are classes
that are instances of this class. A template represents a reusable SPARQL
query or update request that can be parameterized with arguments. Templates
can be instantiated in places where normally a SPARQL query or update
request is used, in particular as spin:rules and
spin:constraints."^^xsd:string .

Then, resources that import SPIN, define instances of spin:Template, for
example:

  :DescribeTemplate a spin:Template ;
    spin:body :DefaultDescribe . # query body defined separately

as well as constraints with instances of thos templates:

  :Resource a owl:Class ;
    spin:constraint [ a :DescribeTemplate ] .

If I understand right, at this point the :DescribeTemplate is both an
instance (of spin:Template) and a class (as its instance is used within the
spin:constraint), although not explicitly declared as a class. Adding an
explicit class definition would result in:

  :DescribeTemplate a owl:Class, spin:Template .

Is this correct? And does it mean that ontologies using spin:Template and
spin:constraint will always be OWL Full? That is what I read from the OWL
reference (http://www.w3.org/TR/owl-ref/#Class):

  NOTE: In OWL Lite and OWL DL an individual can never be at the same time a
class: classes and individuals form disjoint domains (as do properties and
data values). OWL Full allows the freedom of RDF Schema: a class may act as
an instance of another (meta)class.

I'm far from an expert in OWL and the case I described is handled just fine
in my code, but I'm trying to understand the semantic implications of such
design on the ontologies using the templates.

Martynas
graphity.org

-- 
-- You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include Enterprise
Vocabulary Network (EVN), TopBraid Composer, TopBraid Live,
TopBraid Ensemble, SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en
--- 
You received this message because you are subscribed to the Google Groups
"TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
 
 

-- 
-- You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary 
Network (EVN), TopBraid Composer, TopBraid Live,
TopBraid Ensemble, SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to