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.
Related
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.
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 a set of football related keywords, a data set of positive sentiments words and negative sentiments words with me. My requirement is to combine these and search is social media to get some real time discussions and posts, and do some statistical analysis and reach some conclusions. This keywords and data sets are dynamically updating one. Now my question is
What is the best practice to handle the three sets of data? Using an Ontology structure or Well structured database?
Whether the data in the ontology is able to access from any programming languages? can i update or retrieve the data in Ontology using .NET or R or with any other programming language?
Thank you
Representing the related keywords as an ontology is a good idea rather than storing in a database.
SPARQL can be used to access and search the ontology to get related information
Your system will be semantically rich if its an ontology
If its a database, may be the access time may be improved but it will not be semantically rich
You may use apache jena which is a free Java API for creating an ontology.
Python also has many plugins for ontology generation.
My problem is a simple one. I've created a class library for Delphi 2007 and added the modelling support to it that Delphi offers. It generates nice class overviews of my code, which I'd like to use. But it's not enough. I want to export the generated UML to Altova's UModel to generate some additional documentation and nicer-looking models.
I can't find a way to export the UML from Delphi, though. I can't even find anything in Delphi that would help me to generate any other documentation, except for the class model images that it allows me to save.
My main problem with my class library is that while it's usage is simple, it's creation was quite complex. I've used several techniques to encapsulate functionality, types within types, interfaces and delegations, type aliases and a lot more. The result is actually three simple-looking classes that only expose methods needed to call a specific web service with one class for the WS itself, one class to manage the input and one to manage the output. The class interface is thus kept simple to make it's usage simple. Unfortunately, the complexity of the WS required me to create some complex code.
I need to generate two kinds of documentation now for this code. One simple document that explains how it's used. That one is simple. A second one that explains how to maintain the code, what is where and how and why certain decisions have been taken. That one is complex and requires me to model the whole thing.
I have UModel, which is a great product, especially with C# and Java code. Unfortunately, it can't import Delphi code. I've tried Enterprise Architect, which can manage Delphi code, but this code happens to be way too complex. EA doesn't understand a thing about types within types and other features I've used. Also tried StarUML but had to cry after 10 minutes of usage since that product is just real bad... And doesn't even support Delphi... My hard disk feels real dirty now after I've installed it...
And while I could continue to try other modelling tools, I think I should have a better chance in findiing some way to convert the Together UML stuff to a regular XMI file.
You might want to try ModelMaker.
It has an add-on that allows you to export the UML as XMI, which you can import in Altova UModel.
ModelMaker supports both the Delphi and C# language.
--jeroen
I'm afraid there's no such thing as "regular XMI file" (see for instance this example, that shows the differences in the XMI representation of the same model depending on the tool you use).
Heyho,
There´s a question in my mind for some time now, which hopefully can be cleared quickly by some of you:
I am a big fan of MVC, ASP.Net Mvc in my case.
What I have noticed is the hype about interfaces. Every video, tutorial and book seems to solve any kind of abstraction with interfaces. I have adapted these patterns, understood why and how and I am basically very happy with it.
But I just don´t get why interfaces are used everywhere. I´ve almost never seen some abstraction being done with abstract base classes, which I don´t understand. Maybe I miss something? I know that you can only inherit from one base class while multiple interfaces are possible. But interfaces do have disadvantages, especially when some changes need to be done, which breaks your implementations.
In my projects so far, I only used to pick interfaces for completely different classes.
For example, the whole repository pattern could be done with an abstract base class, still providing testability and exchangeability, or did I miss something?
Please point me to the part where my brain laggs :)
Interfaces are used in tutorials, blogs and elsewhere because those authors are particularly influenced by a group of methodology called "design for testability".
Primarily, design for testability school of thoughts used interface every way because they want to be able to mock any component under tests. If you use concrete class, then a lot of mocking tools can't mock those class, and hence will make it difficult to test your code.
A Story
I once attended a Java user group
meeting where James Gosling (Java's
inventor) was the featured speaker.
During the memorable Q&A session,
someone asked him: "If you could do
Java over again, what would you
change?" "I'd leave out classes," he
replied. After the laughter died down,
he explained that the real problem
wasn't classes per se, but rather
implementation inheritance (the
extends relationship). Interface
inheritance (the implements
relationship) is preferable. You
should avoid implementation
inheritance whenever possible.
While using only or mostly Interfaces does have code reuse problems(as well as eliminating nice base classes), It makes it a lot easier to do Multiple Inheritance like things. As well as having widely different implementations that will work and where you don't have to worry about the base class changing or even what it does(you do have to implement the whole thing though so its a trade off).
P.S. I think the new Go language is based on interfaces rather then inheritance(looks sort of interesting).
If the language doesn't support multiple inheritance or mix-ins abstract base classes are limited in scope compared to interfaces. E.g. in .NET if you must inherit from some other type such as MarshalByRef, you can't use an abstract base class to implement a pattern. Interfaces do not impose this restriction.
Besides the fact you mentioned that you can inherit from a single base class only (which is pretty inconvenient if you want to use an existing class that already inherits from some class with the new framework base class), you also avoid the fragile base class problem if you use interfaces instead.
Coding against interfaces makes your design more flexible and extensible. For instance, plugin frameworks and dependency injection. Without interfaces, the extensibility of it is pretty much limited.
Read about interfaces, abstract classes, breaking changes, and MVC here: http://ayende.com/Blog/archive/2008/02/21/Re-Versioning-Issues-With-Abstract-Base-Classes-and-Interfaces.aspx.
One solution that is presented there (or somewhere else on Ayende's blog) is: do use interface but also provide abstract classes. Those who case about breaking changes can base their implementations on abstract classes. Those who need power of interfaces are also satisfied. But do make sure your methods accept interfaces, not abstract classes, as input.