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

allow schema:domain/rangeIncludes and rdfs:Class #13

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

VladimirAlexiev
Copy link

Fixes #12 (allow schema:domain/rangeIncludes).
Tested on:

Also:

  • allows rdfs:Class, since many people use that instead of owl:Class.
  • allows sub-class and sub-property references using rdf:about instead of rdf:resource, eg (closing tags omitted for brevity)
  <owl:ObjectProperty rdf:about="http://data.businessgraph.io/ontology#adminUnitL3">
    <rdfs:subPropertyOf>
      <owl:ObjectProperty rdf:about="http://data.businessgraph.io/ontology#adminUnit"/>
  <rdfs:Class rdf:about="http://data.businessgraph.io/ontology#Register">
    <rdfs:subClassOf>
      <rdfs:Class rdf:about="http://www.w3.org/ns/regorg#RegisteredOrganization"/>

Such are produced by some ttl->rdf conversion tools, eg

riot --output=rdfxml test/ebg-ontology.ttl > test/ebg-ontology.rdf

@VladimirAlexiev
Copy link
Author

@essepuntato
Copy link
Owner

essepuntato commented May 11, 2018

Hi @VladimirAlexiev

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. ramon:code schema:domainIncludes ramon:NUTSRegion, ebg:LAURegion), should be actually rendered as an "or" restriction, e.g. LAU Regionc or NUTS Regionc, instead of using a list as shown in https://rawgit.com/euBusinessGraph/eubg-data/master/ontology/index.html#d4e769.

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?

@VladimirAlexiev
Copy link
Author

VladimirAlexiev commented May 14, 2018

@essepuntato

must differ from the usual rdfs:range/domain axioms. This is because, honestly, mixing things is not good

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.

that accompany the existing range/domain field defined formally via OWL/RDFS

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.

should be actually rendered as an "or" restriction, instead of using a list

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.

using the "owlapi" param would solve automatically these issues about rdfs:Class you mentioned before. Is that modification really necessary

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?

@essepuntato
Copy link
Owner

Hi @VladimirAlexiev

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.

@dr-shorthair
Copy link

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'.
They are combined with OR rather than the AND defined in RDFS global constraints.

@VladimirAlexiev
Copy link
Author

Ok, I'll split them off to separate labels Domain includes and Range includes. I think keeping the comma in the respective lists (instead of or) is ok since includes says the same.

@essepuntato, is there a duplication problem with rdfs:Class|owl:Class when you try it through OWLAPI? If not, I suggest we keep it as is in the PR. Cheers!

@VladimirAlexiev
Copy link
Author

As discused, I've separated rdfs:domain and schema:domainIncludes and emit them separately, and same for range.

An updated example is at
https://rawgit.com/euBusinessGraph/eubg-data/master/ontology/index.html#objectproperties
It also uses VladimirAlexiev#1 to print more metadata (tracked at #15)

@dr-shorthair
Copy link

Maybe test it with https://www.w3.org/ns/ssn/ which imports https://www.w3.org/ns/sosa/ which contains schema.org properties

@VladimirAlexiev
Copy link
Author

Thanks @dr-shorthair! Unfortunately I can't easily build it, so I'm monkey-wrenching by using directly extract.xsl.
@essepuntato, if you don't have time to test this now, I can get some programmer colleague to build it.

@VladimirAlexiev
Copy link
Author

hi @essepuntato, should I do something more for this PR to go through?
Cheers!

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

Successfully merging this pull request may close these issues.

3 participants