Hello,
we are working on a small ontology created on Protégé and uploaded to Stardog in .rdf format.
In this ontology, two concepts "Vulnerabilities" and "Weakness" each have sub-concepts "CVE" and "CWE". Conceptually, these "CVE" and "CWE" sub-concepts should be linked together with relations carried by the parent concepts represented by the red arrows on the screenshot. Unfortunately we were unable to load the data by doing this. To make it possible to link the "CVE" and "CWE" sub-concepts we had to directly create "Wields" and "isWieldBy" relations and load the data into them.
This mode of operation poses the following problem: if a parent concept "A" is attached to all the sub-concepts of another parent concept "B", this forces us to create as many relationships and to modify our entire ontology.
Conversely, when we enter the instances manually in Protégé and launch the reasoner, Protégé knows how to do the link inheritance perfectly and all our data is correctly attached between our parent and child concepts without it being necessary to create links with each child concept. We thought that the notion of relationship could be inherited from parents to children but we are unable to reproduce this behavior in Stardog. Is this a misunderstanding on our part? A design error? A feature that does not exist in Stardog? Misuse of the tool?
Thank you in advance for your help !
Hi Romain,
If I am understanding correctly, you are accomplishing the same behavior in Designer. If you publish these mappings and query for triples consisting of Vulnerabilities Wields Weakness with reasoning on the relationship will be inherited as desired. It's inferred that all Vulnerabilities returned by the query will be of type CVE.
Designer only visualizations the explicit relationships and types. Stardog Explorer can be used to query and visualize data with reasoning on to also see inferred data. You will need to toggle reasoning on in Explorer's settings. A feature to visualize inferred types when mapping and modeling in Designer is a great suggestion!
Hope this helps.
Laura
Hello Laura and thank you very much for your feedback.
I'm not sure I understood your answer, we're just trying to import a simple ontology with a relationship between two parent concepts. We then try in the Designer to correctly map the source files to feed the relations as well as the child concepts "CVE" and "CWE" but when we query in the Explorer it does not work. Instances of child concepts are unrelated. We are forced to create the relationship only and directly between the 2 child concepts for it to work. However, in Protégé only the relationship between the parent concepts is necessary and the relationship between the children is automatically inferred. Do you need more information on how we linked the concepts? The keys we used?...? Thanks in advance !
Hi Romain,
The types are shown in Explorer but only in the details or inferred through filters. Details being the see details option when right clicking a node from the visualization canvas and inferred through filters implying if you set the class filter on the search to an inferred type, nodes inferred for that type will be included in the result set. Although, we only show leaf types in Explorer (given a tree or trees of related subclasses for an instance, we only show the ending types). We chose to do this as for deep ontologies showing all types can be inefficient and result a number of types that would be overwhelming in a visualization. In this case, I understand it is removing your ability to see that Vulnerabilities Wields Weakness in the visualization as Explorer will only present Vulnerabilities as CVE and Weakness as CWE.
Example for a similar dataset,
For the following model and mapping in Designer
Lecturers data set:
| Person_ID |
Name |
Class_ID |
| 1 |
Joe |
a |
| 2 |
Jane |
b |
| 3 |
Fred |
c |
| 4 |
Samantha |
d |
Courses dataset:
| Class_ID |
Name |
| a |
Biology |
| b |
Chemistry |
| c |
Math |
| d |
English |
In Explorer with reasoning on, you would be able to set the class selector to Course and search for Math. The node for Math will only be shown with the type of Class as we only show leaf nodes in Explorer. The Math node can be expanded by teaches to show the Lecturer (sorry in my example the teaches/isTaughtBy relationships are backwards). If you right click on the Lecturer node you can open the details for the node and see the type is both Lecturer and Person.
In Studio you can run SPARQL queries directly. So a query like
select ?s_label ?p_label ?o_label
where {
?s ?p ?o.
?s a <tag:stardog:project:220518160554:modelConceptClass:Course>.
?o a <tag:stardog:project:220518160554:modelConceptClass:Person>.
?s rdfs:label ?s_label.
?p rdfs:label ?p_label.
?o rdfs:label ?o_label.
}
Would return the 4 teaches instances as expected with reasoning on. With reasoning off, no results would be returned as there is no explicit relationship between Course and Person.
On our side I'll add a feature request to be able to see all types of a node in Explorer and visualizing inferred types when mapping and modeling.
Hi Laura,
thanks for this detailed explanation.
My bad, the first one capture of our Designer is more like this :
As you can see, the link is between Vulnerabilities and Weaknessess. But we feed child classes "CWE" and "CVE".
Doing such mapping leads to no instance matching between data from "CVE" and data from "CWE" on the Explorer -> Stardog show that a specific "CVE" instance is a subclass of vulnerabilities, the same for a specific "CWE" recognized as a subclass of Weakness.
To resume, in Explorer, this is what we expect :
And this is what we get :
Hope my explanations are clear 
Thanks !
Thanks for the reply Romain. I see now what you were originally asking.
We don't currently offer an option in Designer to visualize the model how reasoning would include inheritance of properties. So though Designer you would not be able to map to properties such as wields/iswieldsby without explicitly defining them between cve/cwe, even though as you noted those properties could be inherited from their parent classes.
I have shared the feature request to be able to map to inherited properties in Designer.
Thanks,
Laura
Hi, Laura, thanks for you feedback so we will modify our model to match Stardog capabilities.
