Skip to content
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

Open
cthoyt opened this issue Jan 3, 2025 · 6 comments
Open

Comments

@cthoyt
Copy link

cthoyt commented Jan 3, 2025

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

# test1.ofn
Prefix(a:=<https://example.org/a:>)
Ontology(<https://example.org/ontology_2.ofn>
    SubObjectPropertyOf(a:ope1 ObjectInverseOf(a:ope2))
)

generates the following turtle with robot convert -i test1.ofn -o test1.ttl (note, this output is abridged to the relevant parts):

# test1.ttl
a:ope1 rdf:type owl:ObjectProperty ;
       rdfs:subPropertyOf [ owl:inverseOf a:ope2
                          ] .

a:ope2 rdf:type owl:ObjectProperty .

No explicit type declaration inside EquivalentObjectProperties

# test2.ofn
Prefix(a:=<https://example.org/a:>)
Ontology(<https://example.org/ontology_1.ofn>
    EquivalentObjectProperties(a:ope1 ObjectInverseOf(a:ope2))
)

generates the following turtle with robot convert -i test2.ofn -o test2.ttl (note, this output is abridged to the relevant parts):

# test2.ttl
a:ope1 rdf:type owl:ObjectProperty ;
       owl:equivalentProperty [ owl:inverseOf a:ope2
                              ] .

Desired Behavior

I would like the EquivalentObjectProperties to also output a:ope2 rdf:type owl:ObjectProperty .. More generally, I would like to assume any time ObjectInverseOf(a:ope2) is used, regardless of where in the structure, that this type declaration gets made

@ignazio1977
Copy link
Contributor

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)

@cthoyt
Copy link
Author

cthoyt commented Jan 4, 2025

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!

@ignazio1977
Copy link
Contributor

I've not read that portion of the specs in a while. However,

any time you use something as an object property, it should get a declaration

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.

@cthoyt
Copy link
Author

cthoyt commented Jan 4, 2025

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!

@ignazio1977
Copy link
Contributor

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.

@cthoyt
Copy link
Author

cthoyt commented Jan 4, 2025

I just added the filenames and the exact commands I ran into the original post

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants