RDF/XML parser

[IvanoBilenchi]

As indicated in the OWL 2 conformance document, RDF/XML support is mandatory, so this needs to be addressed eventually.

The obvious solution would be integrating the raptor parser from Redland, though serd also looks very promising and is probably more aligned with Cowl's focus on embedded devices.

Either way, RDF/XML support would:

• Introduce an external dependency.
• Make the library bigger.

Both of which are not particularly appealing. A solution would be letting users select the parser(s) they want at compile time, which would solve the second issue and partially mitigate the first one.

[wbraswell]

My team has been investigating this very issue recently, and we have come to the tentative conclusion that Redland/Raptor is now too outdated for our technical needs. We are in the process of putting together a comprehensive Perl-and-C based approach for working with RDF/OWL ontologies.

Fortunately, the Attean project by @kasei seems to provide most or all of our desired RDF and SPARQL functionality.
https://github.com/kasei/attean
https://metacpan.org/dist/Attean

@IvanoBilenchi will you please review the Attean project and let us know if you find it to be a potential complement to Cowl?

[IvanoBilenchi]

In order for a RDF toolkit to be suitable as a backend for Cowl it needs to be implemented in a sufficiently low-level language, with the (strongly) preferred option being C. It is a strict requirement for us as Cowl must be able to run on the widest possible range of platforms, including embedded devices (for which C/C++ is currently the only reasonable option). With regards to the original issue, we do now have support for selecting readers at compile time, though there's no timeframe on RDF/SPARQL support other than "it will eventually come", as it keeps popping up as a requirement in our research as well.

On the other hand, Attean may serve -your- purpose. I know nothing about C-Perl interoperability, but if it is anything like the Java Native Interface or the C API for Python, then you may be able to make it work. The effort is of course non-negligible, as a Perl implementation of the OWL-RDF mapping would be needed, together with bridging to Cowl data structures and any necessary glue.

[wbraswell]

Thanks @IvanoBilenchi for the great info, especially the need for an OWL-to-RDF mapping component.
I totally agree with your requirement of C/C++ for any Cowl extensions.

I also agree with the sentiment that Attean may work for our Perl-centric needs at this time. (I have already asked the Attean people if they have started work on such a mapping: kasei/attean#161)

Have you considered the possibility of utilizing the owlcpp code related to "Converting RDF triples to DL axioms" as your RDF-to-OWL mapping?
https://owl-cpp.sourceforge.net/tutorial_cpp.html

[IvanoBilenchi]

Despite its name, owlcpp is more of a RDF library, as anything related to OWL semantics is delegated to the Fact++ reasoner. We assessed owlcpp long before starting the Cowl project, and its mapping to OWL axioms was one of the things I specifically did not like, as it is done by spawning an instance of Fact++ over the RDF triple store. Resorting to a full-blown OWL reasoner for a syntactical mapping is both overkill (w.r.t. code size, performance, memory, etc.) and a huge overlap of responsibilities.

[wbraswell]

Thanks for the info about owlcpp, we have decided to go with Cowl and will be moving forward with plans to create a Perl API for Cowl in the near future.

Meanwhile, we still need to figure out how to implement the OWL-to-RDF mapping component. We do potentially plan to use Attean as well, and the Attean folks have indicated that they have not yet worked on the OWL-to-RDF mapping.

Looking into Fact++, I have found the following BitBucket as the latest source code:
https://bitbucket.org/dtsarkov/factplusplus/src/master/

Can you please tell me, where exactly in the Fact++ source code is the OWL-to-RDF mapping contained?

[IvanoBilenchi]

I believe part of the logic is implemented in adaptor_triple.cpp, though it looks incomplete (some types of triples are ignored) and it seems to rely on the Fact++ library for quite a bit of stuff.

[wbraswell]

Thanks for helping us locate owlcpp's adapter_triple.cpp file, we have briefly reviewed the C++ source code and agree with your assessment that it relies on Fact++ and is probably not of any practical use to us at this time. We will go ahead and move forward with our plans to create a Perl API for Cowl, and will keep you informed as we make progress. I'm sure we will have many questions for you as we go along! :-)

Meanwhile, we are looking at the owlready2 Python API as a potential template or guide for implementing our Perl wrapper around Cowl. Can you please tell us, what (if any) are the significant design and functionality differences between the Cowl API and the owlready2 API?

https://bitbucket.org/jibalamy/owlready2/src/master/

[IvanoBilenchi]

I'm not confident enough with owlready2 to be able to answer that, however it looks like it's using an RDF quad store as its core data model. This likely entails it is pretty different from Cowl architecture-wise, as its data model reflects that of the OWL 2 functional specification.

If you're looking for architecture guidance and specifically require something that's similar to Cowl, the OWL API is certainly a much closer candidate, as it implements a proper OWL 2 structural data model rather than just relying on logical views over RDF.

[wbraswell]

Hello and happy new year!
Can you please explain in more detail why you consider Cowl and OWL API to contain the "proper OWL 2 structural data model", and also why owlready2's usage of RDF quad stores would thus be considered "improper"?
In other words, what are the practical differences between the proper and improper implementations?

[IvanoBilenchi]

There's nothing improper about using quad stores as the underlying storage. With "proper" I meant "adherent to the structural specification", abstraction-wise. The OWL API implements an OWL 2 structural data model just as Cowl does (i.e. you have model objects for "ontologies", "axioms", "class expressions" and other OWL constructs), while most RDF-based frameworks I know of can parse OWL 2 to RDF and mostly leave it at that, meaning one is left working with triples and SPARQL queries. I don't have enough experience with owlready2 to know if this applies to it as well.

I will point out we are pretty off-topic from the subject of the issue. If you require further assistance with Cowl feel free to open separate issues, however please note that my time is very limited these days so further inquiries will have to be focused on Cowl itself for me to be able to reply.