Closed matentzn closed 5 years ago
I see you use --use-graphs false
. Are these declarations in an import? In that case you need --use-graphs true
, and then have your SPARQL query run over the default graph (no FROM
statement).
The use case is: give me all the object properties used in the edit file.. What do you mean by:
then have your SPARQL query run over the default graph (no FROM statement)
The only thing I noticed is this: If I drop the imports, it appears to work again (deleting the import statements I mean).
When you delete imports, property declarations will be inserted into the main ontology by OWL API as needed.
There must be a robust way to get all object properties used in the signature with --use-graphs false, no?
--use-graphs true
and query for ?x a owl:ObjectProperty
--use-graphs false
and query for ?x a owl:ObjectProperty
--use-graphs false
and create SPARQL query for specific syntactic situations, like owl:onProperty
.I think that covers it? If I understand it correctly I don't think there is a bug here.
imports: o.owl
A sub B
and both A and B are declared in o.owl, that the sparql query ?a a owl:Class returns A and B when the import statement is there and nothing when it is not. You dont think this is counter intuitive? Our users dont really care whether something is declared. They just want a nice overview of all the used classes, and they want to use robots query function to do so...
Its probably not a ROBOT issues, but important enough for someone to investigate.
Goal: Get all object properties in signature. Symptom: SPARQL queries using
?x a owl:ObjectProperty
fail for an unknown reason to retrieve all existing object properties.I have developed a unit test here:
This will execute two sparql queries.
works_seed_by_entity_type_cl.txt
is the result of an alternative SPARQL query exploiting the presence of existential restrictions for retrieving object properties (successfully).fail_seed_by_entity_type_cl.txt
contains the seed using the?x a owl:ObjectProperty
. As you can see, most importantly, BFO:0000050 is missing from that seed!As we rely on this a lot in the ODK (many SPARQL queries with this kind of selector), it would be good to figure out what is going wrong. The only thing I noticed is this: If I drop the imports, it appears to work again (deleting the import statements I mean).