I am using Protege 4.3.0 to describe remediation activities in oil-damaged areas.
I am a complete newbie at ontologies and followed Matthew Horridge's tutorial.
He expresses the fact that every Pizza has some Toppings through the propriety hasTopping, that it has one base through hasBase etc...
I was wondering what would have been the drawbacks of creating a general property "has" and expressing the fact with
Pizza has some Topping
Pizza has max 1 Base
and so on ...
Any consideration?
Adriano
The general rule in creating ontologies is to be as specific as possible. Based on the Pizza ontology example and the two main object properties:
hasTopping
hasBase
If you only define "has" instead of the two, it means that you can say:
Pizza has max 1 PizzaBase
Pizza has min 3 PizzaTopping
Imagine that you have FrenchPizza that is equivalent to:
has some (TomatoTopping and ThinBase)
This will result in an inconsistency, since PizzaBase and PizzaTopping are disjoint and it cannot distinguish between the property relating them. However, if you had the original two properties, this would not have occurred.
Hope this helps.
Using has would be fine in many situations. As opposed to what Conquering Scientist said, I see no reason to be as specific as possible. In fact, it such was the case, the Pizza ontology would not be specific enough. However, using simply the verb has for the name of the property would probably be prone to mistakes. But you could have a property hasIngredient that is more general than hasTopping and hasBase.
One advantage of defining hasTopping is that you can set its domain and range independently from hasBase, so that:
<p> <hasTopping> <t> .
entails:
<t> a <Topping> .
while:
<p> <has> <t> .
does not say anything about <t>.
In any case, you must conscious that the Pizza tutorial is not a tutorial for good ontology modelling. It is merely presenting all the features of Protégé 4. If I was selling pizzas and wanted to organise the information with SemWeb technologies, I would never use such an ontology.
Related
I am wondering why public biomedical ontologies are often organized in such a way that there are no class instances and only classes? I understand it in a way that all instances are classes, but I do not understand what is the advantage or purpose of such modelling? Those classes have also only annotation properties. For example NCIT ontology: https://bioportal.bioontology.org/ontologies/NCIT/?p=summary.
I would appreciate if someone could provide me with an explanation what is the purpose of such model and if there is an advantage to a model where classes have class instances. I am definitively not an expert in the field and I only was working on modelling 'standard' ontologies with classes and their instances.
TLDR
The reason for preferring classes over individuals (or instances) is that classes allow for sophisticated reasoning which is used to infer classification hierarchies.
The longer answer
The semantics of OWL allows you to make the following type of statements:
ClassExpression1 is a subclass of ClassExpression2
PropertyExpression1 is a subproperty of PropertyExpression2
Individual c1 is an instance of Class1
Individual x is related to individual y via property1
Of these 4 options, (1) by far allows for the most sophistication. Intuitively it comes down to how much each of these allow you to express and the reasoning capability to derive inferences from those statements. To get an intuitive feel of this, using the OWL Direct Semantics, we can see what
ClassExpression1 and ClassExpression2 can be substituted with:
There no way that this expressivity can be achieved using individuals.
Individuals vs Classes
In your question you say that all instances (individuals) are classes. This is not exactly true. Rather, classes consists of instances or instances belong to classes. From a mathematical perspective classes are sets and individuals are members of a set.
Annotations in biomedical ontologies
These ontologies have a substantial (80%-90%) amount of annotations. However, they do have lots of logical axioms. You can see it for example when you look at http://purl.obolibrary.org/obo/NCIT_C12392 on the righthandside, if you scroll down to the bottom, you will see the axioms listed:
I have two main Questions:
1/ If we speak about OWL 2 semantics in academic manuscripts (ex. thesis) :
do we include the description provided in this W3C official page, which consists of more than one interpretation functions
OR
the one provided in most Description logic and OWL manuscripts? Which consists just of one interpretation function (papers and thesis)???
2/ If we speak about OWL 2 standard reasoning tasks in academic manuscripts (ex. thesis) :
do we speak about object and data properties reasoning tasks( ex. subsumption, satisfiability...) besides those of classes: because most academic manuscripts speak just about classes reasoning tasks in OWL 2;
thank you for telling me which of these alternatives, in both questions, is more correct and formal.
Strictly speaking OWL 2 maps to the DL SROIQ(D) extended with DL safe rules (which provides the semantics for hasKey).
Using one interpretation function is the norm in academic texts.
As AKSW pointed out, standard reasoning tasks are reducible to concept satisfiability (resp. class satisfiability in OWL), hence the reason academic texts tend to refer to concept satisfiability.
Role satisfiability (object/data properties satisfiability) reduces to concept satisfiability by checking satisfiability of the concept $\geq 1 r.\top$. However, there are some limitations when considering object/data properties. See Preventing, Detecting, and Revising Flaws in Object Property Expressions.
The trouble is that “OWL 2 Semantics” is ambiguous: OWL is a well-defined interchange format with several incompatible semantic interpretations. If you like you can refer to that particular document, but it’s important to cite it more specifically as the “OWL 2 Direct Semantics”.
In cases where your work doesn’t involve data types or punning, the SROIQ logic is actually a much simpler and cleaner mathematical formalism...with the caveat that the SROIQ literature is typically written for an academic audience, so this simpler model is usually described in a denser style.
For example, for Book and Author classes, I can have authorOf relation, and or hasAuthor relation. For Student and Course classes, I can have courseOf and hasCourse relations between the two.
It seems redundant to always create relations in two directions. Is there any guideline or principle to deal with situation?
I'm not aware of any recommendation to always explicitly provide the inverse property.
There are at least two use cases for inverse properties:
The need to reference the inverse property, let's call it "IP",
internally in the ontology.
We may need to state that another property is disjoint with IP. Or that another property is equivalent to IP. Now, we provide IP to allow that statement. Another very trivial example is the desire to keep a comment in the right place. You may define IP just to place a rdfs:comment on it.
The need to externally reference the inverse property.
An example is: Our application assigns translations of natural languages to ObjectProperties. In case of the famous Protege Pizza Ontology, we translate "hasTopping" to strings like "en:has topping". We also want to express "en:is the topping of" in a natural language. (Our application semantics needs it.) That's a reason to create the inverse property "isToppingOf": To have an instance, respective an URI, our translations can refer to.
I'm working with a OWL API 3 / Pellet / SPARQL-DL stack and want to read the asserted TBox axioms of a certain class from an ontology.
I can easily access the axioms with OWL API. However, the OWLClassAxiom just provides function to access the signature without the connections. I.e. I want to know to which Class a ObjectProperty is assigned to. All I can retrieve is a set of all elements in the signature, without their connection.
It seems that OWL API does not really support working with given axioms on a class level well (Reading, not adding.) Or am I missing something? Any other ideas how to achieve that? (With whatever tools.)
Concrete Example: Pizza hasBase some PizzaTopping. I want to retrieve the value "PizzaTopping" by specifying Pizza and hasBase.
If Pizza is a class, then
Pizza hasBase some PizzaTopping
isn't a legal axiom. What you probably actually have is
Pizza subClassof hasBase some PizzaTopping
That means that every instance of Pizza is related to some instance of PizzaTopping by the hasBase property. The axiom is a subclass axiom, so you'd want to retrieve an instance of OWLSubClassOfAxiom, (which is a subclass of OWLClassAxiom).
In this case, if you have a reference to the OWLClass for Pizza, then you could use OWLClass#getSuperclasses() to get a list of superclass expressions. One of them would be an OWLObjectSomeValuesFrom expression for (hasBase some PizzaTopping). You'd have to look for the ones of that type, and then examine the property that it is a restriction on.
That said, your stated goal
to know to which Class a ObjectProperty is assigned to
doesn't quite match up with the OWL model. Object properties (and data properties) don't "belong" to classes in OWL. You can use subclass axioms and property restrictions, like above, to say that members of a class must have a value for a particular property,
I'm fairly new to ontologies and have the following situation:
Given a class definition, I want to automatically generate individuals based on all possible combinations of a given restriction.
For example:
Let's say a "Pizza" class has the property "hasTopping" which is supposed to be linked to an individual of class "Topping". I want to generate an individual of the class Pizza for each individual existing for a Topping. If there are two Topping individuals, Tomato and Cheese, I want to create one Pizza individual with "hasTopping Tomato" and one with "hasTopping Cheese".
Is there any general way to generate individuals in ontologies like this? (As an alternative to implement it myself.)
Is this "violating" the intent/purpose of ontologies in general? Would this usually be handled in a different way? (I'm not completely familiar with ontologies yet.)
There's no standard method to do this, so I think you'll have to implement it yourself. The Leigh University Benchmark does something similar, so it might provide you with some ideas: http://swat.cse.lehigh.edu/projects/lubm/
I don't think this violates the idea behind ontologies at all - seems quite straightforward. There is no best practice for it, so however you choose to implement it will probably be adequate.