-
Notifications
You must be signed in to change notification settings - Fork 315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent type assertions when converting ObjectInverseOf
to turtle
#1161
Comments
Looks like the behaviour you're seeing is a bug that's just the opposite of what you wish. Declarations should not be inferred from usage (because that causes its own set of problems when accidental misuse causes contrasting declarations). So the appearance of that declaration might be one of two things: either the parser incorrectly deciding that there's a declaration for that property, or the writer adding declarations for undeclared entities - it would depend on the format settings when saving the ontology. That's what I'd like to know - how is the ontology saved? Changing the settings for adding declarations for undeclared entities would also give you what you want, i.e., declarations for all entities. (Note: to be fully OWL 2 compliant, the input ontologies should already have those declarations - but I'm guessing the real ontologies you're using are not under your control) |
I must have misunderstood the spec, since I thought it said that any time you use something as an object property, it should get a declaration. I'm happy with it being either way, as long as it's consistent! |
I've not read that portion of the specs in a while. However,
That has two interpretations about what adds the declaration - should it be added to the ontology by who is creating it (like you declare a variable in, say, C or Java), or by what processes it (as in, OWLAPI adding declarations based on use)? The parsing rules, though, specify that a parser can throw out input if it's not got declarations for all properties, classes and datatypes (individuals don't need declarations), which exclude the second interpretation. Meantime in the real world, plenty of ontologies do not declare everything, and plenty of projects use RDF vocabularies that are not owl ontologies at all, so many tools have permissive parsers that will allow them to do something with imperfect data, at the cost of having to debug stuff later because of inconsistencies :-( it's tradeoffs all the way down. |
thanks for the nice response. I appreciate this isn't easy to deal with, as I'm re-implementing some of these rules in Python right now. If you don't think this has any actionable follow-up in this repo, then feel free to close this issue. Cheers! |
Sorry, I was going to ask again how you save the ontology and only now noticed you're doing so through Robot. What I can do is checking how this behaves in the OWLAPI version Robot is using - then hopefully I can tell you if there's anything you can do to get the output you want. I'm not fully familiar with Robot but I should be able to figure the output options. |
I just added the filenames and the exact commands I ran into the original post |
This issue is about inconsistent behavior when using
ObjectInverseOf
in OWL functional syntax.I'm on ROBOT version v1.9.7 / OWL API v.5.29
Examples
Explicit type declaration inside
SubObjectPropertyOf
generates the following turtle with
robot convert -i test1.ofn -o test1.ttl
(note, this output is abridged to the relevant parts):No explicit type declaration inside
EquivalentObjectProperties
generates the following turtle with
robot convert -i test2.ofn -o test2.ttl
(note, this output is abridged to the relevant parts):Desired Behavior
I would like the
EquivalentObjectProperties
to also outputa:ope2 rdf:type owl:ObjectProperty .
. More generally, I would like to assume any timeObjectInverseOf(a:ope2)
is used, regardless of where in the structure, that this type declaration gets madeThe text was updated successfully, but these errors were encountered: