I am studying OWL and now I'm trying to merge two ontologies.
My issue is with two properties that share the name (not the whole IRI but only the name).
For my example, it would make sense to merge those two properties to be the same property. Is there a way to do that?
I tried with "Equivalent to", but the doesn't solve the problem in this sense. Any ideas?
You can create IRI in the ontologyX and copy the IRI and use it in the ontologyY. Why not?
Related
Inside the agent, I have seen uvm_component creation like
apb_monitor m_monitor;
m_monitor=apb_monitor::type_id::create("monitor_name_aaa", this);
m_monitor.analysis_port.connect(analysis_port);
Here we can see that when referring to the hierarchy, we still need to put m_monitor.* rather than monitor_name_aaa.*.
My questions are
What is exactly the purpose of this name property 'monitor_name_aaa'
for?
I have seen in many places people says best way is to put the name = 'm_monitor', same as the m_monitor. If this is true, then why not the methodology just built in this feature directly?
Another point is that If I do get_type_name(), then I see the it is using the name property, like m_env.m_agent.monitor_name_aaa instead.
Thanks!
In UVM it is useful to be able to refer to components either using their SystemVerilog hierarchical name directly or as the string equivalent. (There's the answer to Q1.) Unlike in VHDL, in SystemVerilog there is no way of finding out what the name of a variable is. So, when you create a component, you have to manually set this up. (There's the answer to Q2).
As you point out, you must always make the name of the component the same as the name of the variable pointing to it ("m_monitor" in this case), otherwise you will not have this useful ability to refer to components either by SystemVerilog hierarchical reference or by the equivalent string.
I'm new to the OWL API and I was wondering if there was a way to update an ontology with all the new relations picked up by the reasoner (HermiT). I couldn't find a tutorial or much documentation, so I assumed calling
reasoner.classifyClasses();
reasoner.classifyDataProperties();
reasoner.classifyObjectProperties();
reasoner.precomputeInferences();
reasoner.flush();
would classify the new relations. Then, I'm not sure how to translate these new relations to create an updated ontology. I have an idea of how I could manually iterate through new relations and add them if they aren't present in the ontology, but I'm looking for an easier way to do this. Also, I'm not entirely sure if the above code reasons all the new relations for me, so let me know if I should make any corrections.
You can use InferredOntologyGenerator for that purpose. The class can be created with a reasoner as input and the InferredOntologyGenerator::fillOntology method to add all the axioms that can be inferred to a new ontology.
Note that axiom generation can be a very slow operation. Try with a small ontology at first, to see whether the result is what you need.
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 having difficulties understanding when to use object properties and when to use data properties. I've read the definitions, but yet I'm having issues using them in a practical setting.
It would be of much help if anyone could correct the following example.
Let's say I'm making a Wine ontology, with some subclasses redWine, whiteWin, sparklingWine and so on. How will I then manage the properties for example goesWithFoodType, fromCountry and hasGrapeType? All in which have subproperties down the hierachy. Will all of these be data properties with the domain Wine and ranges xsd:string datatype?
If the things stated above is correct, would I have any use from object properties in my ontology?
Thanks.
I'm creating an ontology using protege05 and I have a question in regard to property restrictions. What I've understood from the protege tutorial is that when we assign a property to a class using restrictions, it means that this property is necessary for defining that class.
for example, suppose i have classes "Orthodox Church" and "Sanctuary" and a property "hasPart and i want to say that "an Orthodox Church hasPart Sanctuary".
If I use existential restriction apparently it will mean that "having Sanctuary" is necessary for a building to be an Orthodox Church or if a building is an Orthodox Church it must ALWAYS have a Sanctuary.(but it's not always correct).
so my question is that how should insert this property without it being necessary for defining my class? in other words, how can i say that this property is SOMETIMES correct for my class but not ALWAYS?
Thanks
You want to use Orthodox Church as domain for your property - so, when used, you will infer the building is a church. It won't stop you from creating churches without sanctuaries.
Without changing the domain, you could create a class with 'some hasPart Sanctuary' as a subclass of 'Orthodox Church' - a sufficient but not necessary condition.