I am looking for guidance on what is the best way for ontology alignment? I am using protege for ontology modelling at the moment. I like to use other classes from existing ontologies. However, is it better to (1) make my own classes and then add the existing classes as equiavalentTo? or (2) import the existing ontologies or classes/relationships and use them as the start?
Thanks!
I don't think it's necessarily "better" to use either approach, but there are factors which may affect the choice:
Some vocabularies may not have a proper ontology, i.e. the terms are not described by anything that could be imported. You could still use the terms from the vocabulary directly, but you'd have to describe the ontology yourself to make them logically usable, at the risk of coming into conflict with someone else who would also want to use the vocabulary this way.
If you use the external ontology only marginally, and you don't want to describe all the classes and properties yourself since it pretty much aligns with the existing definitions, there is of course no need to "duplicate" it, as importing makes it less cluttered and helps people who are already familiar with the other ontology understand yours.
If you'd use the external ontology as the core, it depends on what you are creating. If you are merely extending it with new concepts, then again your concepts should align with those from the external ontology, so there is no issue with importing it (for the same reasons as above). However, if your ontology has a somewhat different focus, you may want to define the core terms yourself without relying on other ontologies, since it may as well come to the point that you decide that they are not really equivalent (like a "Person" in one ontology may not be equivalent to a "Person" in another ontology). Such a choice will be easier to make when you don't have to rewrite half of your ontology.
Last thing to note: owl:equivalentClass does not mean the classes are the same; just that they share the set of individuals. You could still give them your own descriptions, link them to other concepts etc. without affecting the equivalent classes, which still have their own "identity". This is similar in mathematics to Zorn's lemma, the well-ordering theorem, and the axiom of choice, which are all logically equivalent, yet they have their own Wikipedia articles so clearly they are not identical.
Related
I'm writing game worlds and I've started working on representing the worlds not just as text and images but as a graph of topics and associations. In other words, an ontology representing the game world's characters, places, events, concepts, terms and so on.
Where I've got a bit stuck is in defining and naming the relationships between topics. It's easy enough to come up with things like "is a", "part of", "located in" etc, but as the work goes on, I realize that using the terms loosely will not work well, there are many relationships that overlap in meaning and you start wondering if this hasn't already been done. I've looked into OWL for creating ontologies, and topic maps, but what I lack is an actual data set of named associations (predicates in RDF) that I can build on, that have been vetted and used for larger projects.
What is a good strategy and resource to describe relationships between concepts in an ontology?
Schema.org is probably the definitive resource when it comes to widely accepted nomenclature for ontologies. See their page for Organizations for a good example of their property names.
I found a similar question that was addressed to the Neo4j/Cypher graph database audience, but may provide some good insights as well. A key one is the trade-offs between fine-grained relationships ('LIKES_POST') vs course-grained relationships ('LIKES'). The finer the grain, the greater the specificity, but the greater the overall complexity of the graph. In general, these trade-offs depend on your use case, where you can determine which direction best suits your needs.
I am looking for ontologies made for the domain of agriculture. I need these ontologies for testing a logic I implemented for merging domain specific ontologies. I specifically need ontologies that are created for the sub domains of agriculture(ontologies of other domains will also be useful as well).
For example: Crops ontology, Fertilizer ontology, Rice ontology, Weed ontology.
Any kind of ontology will be helpful. Does anyone know where to find such ontologies? I couldn't find any.
If anyone know ontologies like these related to a domain other than agriculture, mention them too. Thank you in advance.
Sorry if I posted a wrong kind of question.
You don't state exactly what you mean by ontology, so I'm assuming a definition as is commonly used in the life-sciences, encompassing a wide degree of axiomatization with hundreds to potentially hundreds of thousands of classes. If you mean something more like an RDF schema then my examples may not apply.
AgroPortal has over 100 ontologies/thesauri in the domain of or closely related to Agriculture. You can see in the top 5 accessed ontologies some of the most relevant ones, including AGROVOC. Note that GACS is itself a merger of other thesauri, so if your goal is to test a merge framework you may want to hold this one back. Many of these are more thesaurus-like, but some such as ENVO and AGRO employ more extensive OWL axiomatization.
Note also that considerable work has been done in the Planteome project to merge together different crop ontologies into a pan-species trait ontology, this may also be useful for your evaluation.
If you are interested in applying your techniques more broadly in the life sciences, common sub-domains are anatomy, phenotype and disease. These frequently are used as tests in initiatives like the Ontology Alignment Evaluation Initiative. Although it sounds like your technique goes beyond mapping and into merging, it may be useful to look at past competitions. I have also produced merged anatomy, disease and phenotype ontologies, these have all been curated and could be used as test sets for your approach.
I have developed an ontology of emotions using Protege. I want to relate each class(emotion) of my ontology to its similar concepts in another ontology. For example, I have a class Anger. I want to retrieve concepts relating to anger, like agitation, mad, etc., in correct context from another ontology (ConceptNet or WordNet) through their URIs. How can I do so?
Is this even a correct idea to begin with? How else can I achieve my target? Can I call a class from another ontology from my ontology through URI within Protege?
If you only want to refer to the classes, you can simply use the same URI in both places.
However this does not force tools to actually take into account any axioms about those classes, i.e., your ontology will not know about superclasses or restrictions declared in the other ontology.
To actually use all axioms related to your other classes, you'll need to import the other ontology in its entirety. To only use part of the ontology, you can use one of various modularisation techniques available to create a subset of an ontology, containing the axioms you're interested in. However, the technique to use depends on your specific needs.
Can you provide more insight on what you are trying to achieve?
There's a lot of material online on modularisation - search for "ontology modularisation". Reading a few abstracts should help you focus on the best approach for your needs.
I use Jena and TDB to store RDF,and I want to do some inference on it.But the RDF data is big,and Jena's owl reasoner has to load all the data into memory .
So I want to find one reasoner that can reason without load all data into memory,is there any one?
Not really. DL reasoning is computationally difficult at even low scale. With lots of data, that's just not going to work with the existing approaches. Doing it over secondary storage is still an open research problem afaik.
However, the various profiles of OWL exist to address this issue. They all have different computational complexities, which are all 'easier' than DL making them much more amenable to reasoning at scale. In particular, QL is designed for query time reasoning which in my experience tends to have a very small memory footprint and RL can be implemented with a standard rule reasoner.
So if you don't need to use DL, then I'd go with a tool that supports one of the profiles and you should get pretty good mileage out of that.
For reference, you might find this document about the compuational complexities of the various OWL dialects interesting.
If you are prepared to take a subset of OWL, there are things you can do in a stream processing fashion without loading all your RDF data in memory and which will materialise all the inferred triples.
As an example, have a look at RIOT's infer command:
http://incubator.apache.org/jena/documentation/io/riot.html#inference
Source code here:
https://svn.apache.org/repos/asf/incubator/jena/Jena2/ARQ/tags/jena-arq-2.9.0-incubating/src/main/java/riotcmd/infer.java
https://svn.apache.org/repos/asf/incubator/jena/Jena2/ARQ/tags/jena-arq-2.9.0-incubating/src/main/java/org/openjena/riot/pipeline/inf/InferenceProcessorRDFS.java
https://svn.apache.org/repos/asf/incubator/jena/Jena2/ARQ/tags/jena-arq-2.9.0-incubating/src/main/java/org/openjena/riot/pipeline/inf/InferenceSetupRDFS.java
It is trivial to take RIOT's infer and run it in parallel with something like MapReduce, example is here:
https://github.com/castagna/tdbloader4/blob/f5363fa49d16a04a362898c1a5084ade620ee81b/src/main/java/org/apache/jena/tdbloader4/InferDriver.java
Another different approach which uses MapReduce to apply the RDFS and OWL ter Horst rules and materialize all the derived statements is here:
http://www.few.vu.nl/~jui200/webpie.html
Perhaps, you can look at the parts of OWL you are interested in and check if you can do it in a streaming fashion. If so, you can take RIOT's infer and extend it, adding the parts of OWL you are interested in. That would be a nice contribution to Apache Jena (get back in touch on the jena-dev mailing list if you want to do that).
WebPIE is a clever and interesting project, but as you can see, a bit more complex and it's a research project (with all that this implies from a long-term support and maintenance point of view). However, if it is OWL ter Horst you want/need, WebPIE would do.
You could even put the effort, fork WebPIE and contribute it to an open source project, if others are interested in using it.
You might be interested to look also at Ymris (but this is currently sleeping... zzzzz):
https://svn.apache.org/repos/asf/incubator/jena/Import/Jena-SVN/Ymris/trunk/
You may want to try GRAKN.AI, they perform reasoning in real time on persisted data in distributed systems.
I'm still new to OOP, and the way I initially perceived it was to throw alot of procedural looking code inside of objects, and think I'd done my job. But as I've spent the last few weeks doing alot of thinking, reading, and coding (and looking at good code, which is a hugely under-rated resource), I believe I'm starting to grasp the different outlook. It's really just a matter of clarity, simplicity, and organization once you get down to it.
But now I'm starting to look at things as objects that are not as black and white a slamdunk case for being an object. For example, I have a parser, and usually the parser returns some strings that I have to deal with. But it has one specialized case where it has to return an array, and what goes in that array and how it's formatted has specialized rules. This only amounts to two lines plus one method of code, but this code sticks out to me as not being cleanly fitting in the Parser class, and I want to turn it into its own "ActionArray" object.
But is it going to far? Has OOP become a hammer that is making me look at everything like a nail? Is it possible to go too far with turning things into objects?
It's your call, but you should think of objects as real life objects.
Take for example a car. You could describe a car with different objects:
Engine
Wheels
Chassis
Or you could describe a car with just one object:
Engine
You can keep it simple and stupid or you can spread the dependency to different objects.
As a general guideline, I think Sesame Street says it best: you need an new object when "one of these things is not like the others".
Listen to your code. If it is telling you that your objects are becoming polluted with non-essential state and behavior (and thus violating the "Single Responsibility Principle"), or that one part of your object has a rate of change that is different from the rest, and so on, it is telling you that you are missing an object.
Do the simplest thing that could possibly work. When that no longer works, do the next simplest thing. And so on. In general, this means that a system tends to move from fewer, larger objects to more, smaller objects; but not always.
There are a number of great resources for OO design. In addition to the ones already mentioned, I highly recommend Smalltalk Best Practice Patterns and Implementation Patterns by Kent Beck. They use Smalltalk and Java examples, respectively, but I find the principles translate quite well to other OO languages.
Design patterns are your friend. A class rarely exists in a vacuum. It interacts with other classes, and the mechanisms by which your classes are coupled together is going to directly affect your ability to modify your code in the future. With poor class design, a change that you make in one class may ripple down and force changes in other classes, which cause you to have to change other classes, etc.
Design patterns force you to think about how classes relate to each other. For example, your Parser class might choose to implement the Strategy design pattern to abstract out the mechanism for parsing. You might decide to create your Parser as a Template design pattern, and then have each actual instance of the Parser complete the template.
The original book on Design Patters (Design Patterns: Elements of Reusable Object-Oriented Software is excellent, but can be dense and intimidating reading if you are new to OOP. A more accessible book (and specific to Ruby) might be Design Patterns in Ruby, which has a nice introduction to design patterns, and talks about the Ruby way of implementing those patterns.
Object oriented programming is a pretty tricky tool. Many people today are getting into the same conflict, by forgetting the fundamental OOP purpose, which is improving code maintainability.
You can always brainstorm about your future OO code reusability and maintainability, and decide yourself if it's the best way to go. Take look at this interesting study:
Potok, Thomas; Mladen Vouk, Andy Rindos (1999). "Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment"