Hi Lewis,
On 14/03/18 06:13, Lewis John McGibbney wrote:
Hi Dave,
Coming back to this to address some thing I missed before
On 2018/03/07 08:57:47, Dave Reynolds <[email protected]> wrote:
OntModels use a somewhat older stack of tools (FileManager) which
guesses the language based on the suffix, with a default of RDF/XML, and
then relies on content negotiation to deliver the guessed format. Since
your resources don't support conneg
The resources do. For example, SWEET is served with conneg as per the following
http://sweetontoligy.net/sweetAll (returns default TTL)
http://sweetontoligy.net/sweetAll.ttl (explicitly returns TTL)
http://sweetontoligy.net/sweetAll.rdf (returns non-default RDFXML)
and don't support RDF/XML (the
official default) that's not going to work.
Ths issue I see is that even if I return the following ontology
(http://sweetontoligy.net/sweetAll.rdf) resource as RDFXML, the imports
contained within this resource e.g. http://sweetontology.net/relaHuman are
parsed as RDFXML when they should be parsed as TTL e.g. the default
manifestation.
One option might be to create a subclass of FileManager which overrides
readModelWorker to either load the data via the newer RDFDataMgr which
has more sophisticated conneg support, or to change the default syntax
to Turtle. Then install that FileManager in the OntDocumentManager you
use for your loading.
Yes, I can see from the stack trace that FileManager is being called as follows
at
org.apache.jena.util.FileManager.readModelWorker(FileManager.java:375)
at org.apache.jena.util.FileManager.readModel(FileManager.java:342)
at org.apache.jena.util.FileManager.readModel(FileManager.java:326)
This in turn invokes readers expecting XML input, which is not the case...
I'll go ahead and implement the suggested fx as above.
Andy pointed out that in modern Jena versions RIOT rewires itself into
model readers, so it *may* be that just updating to a newer version of
Jena will solve this anyway.
Dave
