Aperture - Closed Issues

These things have been discussed on ApertureDiscussion, and were implemented.

Vocabulary: use DC instead of data

We are using many properties of Dublic Core, but redefining them. For compabilities sake, we should inlcude the real DC vocabularies right from the start, and not use our own uris.

Heinz Kirchmann had the trouble that our DATA vocabulary was not Dublin core, and in his project he had to write a converter. Although the converter is easy to write, using Dublin Core in the first place would have been better.

Note that Leo designed the Data ontology very bad and used own properties only because the f* generation code from Schemagen(Jena) only supports one namespace at a time. We can circumvent that now by using better tools or by other tricks. So the generation of one JAVA file named DATA with all properties in it, the propeties are then a mixture from DC and others, would be possible.

RDFContainer based on RDF2GO

The casting of RDFCOntainer to sesame2 to read values is unaccapteable.

We should definitely move to RDF2GO, and RDF2GO will be improved to fit us. Alternatively we use ONLY sesame2.

A problem that Heinz Kirchmann found when programming catwiesel.opendfki.de was that the downcast from RDFContainer to SesameRdfContainer was not obvious. The crawlerhandler in Gnowsis is seperated from the actual processing of the data. We used RDFContainer as interface inside gnowsis, in many methods. We should have used SesameRDFContainer everywhere inside gnowsis.

If sesame is the right framework for gnowsis, the passing SesameRDFContainer would have been right. But if we remove sesame and use kowari or something else, the usage of RDF2GO may be better.

Also, we never used a RDFContainer besides Sesame2. So it may be the obvious choice to cast everything and define everything as SesameRdfContainer BUT this will cause troubles for projects that are based on Sesame1. If somebody that is based on Sesame1 wants to use Aperture, then using OpenRDF may be good.

On the long run, to have a generic API, using RDF2GO as interface and something like sesame2 as default implementation is better.

The RDFContainer interface did not include all methods that we needed at the end, only SesameRDFContainer did implement the needed methods to read data. So the Interface must be extended to implement all methods needed.

Discussion pros:

• bindings for various RDF stores that we get for free

cons:

• is RDF2GO still using java.net.URIs? That would mean a lot of

conversions that are potentially not necessary, e.g. when using a Sesame Repository: org.openrdf.model.URIs get translated to java.net.URIs and back to org.openrdf.model.URIs.

• RDFContainer lacks full RDF graph access. A simple getStatements

method with a subject parameter would solve this though. I've also read comments by Gunnar about having to cast RDFContainer to SesameRDFContainer in code he wrote, I guess he had the same problem?

Gunnar and Leo are happy with this:

• We keep RDFContainer as it is and only switch "getModel()" to return a RDF2GO model.
• We switch the methods of RDFContainer to use RDF2GO interfaces (RDF2Go's predicate, resource, etc) for the setProperty(property, value) methods.