-
Notifications
You must be signed in to change notification settings - Fork 55
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
allow schema:domain/rangeIncludes and rdfs:Class #13
base: master
Are you sure you want to change the base?
Conversation
Thanks for your comments and your input. In principle, I'm not contrary to the handling of schema:range/domainInclude annotation. However, the way it should be shown in the documentation must differ from the usual rdfs:range/domain axioms. This is because, honestly, mixing things is not good and usually would decrease the comprehension of the ontology for a human reader if the things are not clearly stated. Thus, my idea, actually, would be to add additional fields (in the properties and in the involved classes) in the documentation produced by LODE if the original ontology includes schema:domain/rangeInclude annotation statements, that accompany the existing range/domain field defined formally via OWL/RDFS. I actually believe we should not mix stuff in the documentation, but clearly specify from where these information come from. This is particularly delicate in the cases in which we have both rdfs:domain/range and schema:domain/rangeInclude statements in an ontology. How can I distinguish from those ones that are formally defined and those ones that are annotated. In addition, to me the schema:range/domainInclude, when more than one range/domain are defined (e.g. Finally, I'm currently collaborating with some researcher and we are going to release a new version of LODE quite soon, so as to address some issues and to provide additional features. It would be great to involve them in this conversation as well, if it is fine with you. Thanks again for your help and support :-) S. ps: as far as I remember, using the "owlapi" param would solve automatically these issues about rdfs:Class you mentioned before. Is that modification really necessary for making LODE working correctly? |
We could of course introduce different labels "Domain includes" and "Range includes". But the meaning of the two ways is the same, even though the details of the semantics differ.
One ontology would not mix the two ways. So I think having different labels is not so important. But if you insist, I can try to split them up.
No, domain/rangeIncludes are used with multiple classes as values, eg see http://schema.org/audience.ttl. The main point of using domain/rangeIncludes is to avoid awkward (ineffectual ;-)) OWL constructs such as union.
I haven't tried that. I thought domain/rangeIncludes won't work with OWLAPI because it doesn't support them. In any case, LODE has the option of working without OWLAPI, and it should support rdfs:Class in that case. The only downside of this addition to the XSL is if using OWLAPI returns both rdfs:Class and owl:Class, which would duplicate the print out of class (unless we uniquify the xpath result). I cannot easily build LODE (I've been testing directly with the XSL), could you please test this or post a built version for me to test with OWLAPI? |
The meaning of the two ways is not the same at all, since one is an annotation (the range/domainInclude) while the other is a formal axiom of the ontology. Thus we need to handle them separately, and to make the distinction clear to a user that is not accustomed to seeing one of the two. In addition, saying that an ontology should not use both the approaches is simplistic. I'm not disagreeing with you, but honestly speaking you cannot control what users may do, and I think that having to process an ontology that includes both these kinds of statements is actually reasonable and it will happen for sure. Finally, it is not the problem of how OWL handles specific axioms (like restrictions with boolean operators), but it is actually a matter of how you present the information to a user. If the LODE user is accustomed to see "ClassA or ClassB" in the LODE documentation when an "or" exist (i.e. when it is defined formally), you need to convey similar information in the same manner, even if that is defined via range/domainInclude, otherwise you risk that the user will get lost in the documentation. As a very last note: it is true that LODE can be used without the OWLAPI option specified, but it is able to handle only a specific kind of RDF/XML format in this case – which is exactly what the OWLAPI typically returns. Just to say that I can build an RDF/XML defining an ontology that LODE cannot process correctly without the specification of the OWLAPI parameter. I'll try to address the other doubts as soon as I can. Have a nice day :-) S. |
sdo:domainIncludes and sdo:rangeIncludes are annotations, and cannot be confused with rdfs:domain and rdfs:range. They are useful 'hints' which might be thought of as defining an 'open union'. |
Ok, I'll split them off to separate labels @essepuntato, is there a duplication problem with |
As discused, I've separated rdfs:domain and schema:domainIncludes and emit them separately, and same for range. An updated example is at |
Maybe test it with https://www.w3.org/ns/ssn/ which imports https://www.w3.org/ns/sosa/ which contains schema.org properties |
Thanks @dr-shorthair! Unfortunately I can't easily build it, so I'm monkey-wrenching by using directly extract.xsl. |
hi @essepuntato, should I do something more for this PR to go through? |
Fixes #12 (allow schema:domain/rangeIncludes).
Tested on:
Also:
Such are produced by some ttl->rdf conversion tools, eg
riot --output=rdfxml test/ebg-ontology.ttl > test/ebg-ontology.rdf