Re: OntModel.read parsing non-suffixed TTL as RDF/XML

2018-03-14 Thread Andy Seaborne

Lewis,

I tried:

OntModel m = ModelFactory.createOntologyModel();
m.read("http://sweetontology.net/sweetAll";, null, "TTL");
System.out.println("DONE");
System.exit(0);

and it worked for me (3.6.0, 3.7.0-dev; apache-jena-libs)
Have you got any local copies remapped?
Could you produce a standalone example that does not work for you?

Andy

On 14/03/18 08:52, Dave Reynolds wrote:

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  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


Re: OntModel.read parsing non-suffixed TTL as RDF/XML

2018-03-14 Thread Dave Reynolds

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  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


Re: OntModel.read parsing non-suffixed TTL as RDF/XML

2018-03-13 Thread Lewis John McGibbney
Hi Dave,
Coming back to this to address some thing I missed before

On 2018/03/07 08:57:47, Dave Reynolds  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.
Thanks again,
Lewis


Re: OntModel.read parsing non-suffixed TTL as RDF/XML

2018-03-13 Thread Lewis John McGibbney
Thanks Andy, OK I've added this dependency to the project and te result is just 
the same. I am going to try Dave's suggestion.
Thanks
Lewis

On 2018/03/13 18:51:06, Andy Seaborne  wrote: 
> 
> 
> On 13/03/18 18:44, Lewis John McGibbney wrote:
> > Hi Andy,
> > This is correct.
> > Do you suggest I augment the classpath?
> > Thank you
> > Lewis
> 
> Yes:
> 
>
>  org.apache.jena
>  apache-jena-libs
>  pom
>  X.Y.Z
>
> 
> > 
> > On 2018/03/07 17:01:43, Andy Seaborne  wrote:
> >>
> >>
> >> On 07/03/18 10:59, Andy Seaborne wrote:
> >>> Lewis - which version? Do yo have all the apache-jena-libs jars on the
> >>> classpath?  RIOT rewirers Jena model reading.
> >>
> >> It looks like you only have jena-core of some version on the classpath.
> >>
> >>>
> >>> Also, there was an issue around redirect and remapping but it's fixed.
> >>>
> >>>       Andy
> >>>
> >>> On 07/03/18 08:57, Dave Reynolds wrote:
>  I can't tell from the trace whether you are mapping the import URLs to
>  local files or are loading directly from the URL. If loading from
>  local files then you really need suffixes on those. I'll assume you
>  are loading from the URL ...
> 
>  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 and don't support RDF/XML
>  (the official default) that's not going to work.
> 
>  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.
> 
>  Dave
> 
> 
>  On 07/03/18 04:28, lewis john mcgibbney wrote:
> > Hi Folks,
> >
> > Over on the SWEET ontology suite [0] we recently changed out canonical
> > serialization to TTL. Additionally however, we removed all file suffixes
> > from the resources themselves, therefore although the following resource
> > [1] is serialized as TTL, you would never know unless you looked at
> > it or
> > peeked into the server response.
> >
> > I am experiencing issues when I attempt to load the SWEET 'master' file
> > [2], which essentially produces a graph by importing every file
> > within the
> > ontology suite. The code I use to do this is as follows.
> >
> > ((OntModel) m).read(url, null, lang); //Where lang is the string
> > "TTL" or
> > "TURTLE" depending on previous logic.
> >
> > The stack trace I get is as follows [3]
> >
> > As you can see it loads the sweetAll file correctly but chokes on the
> > imported resource http://sweetontology.net/realmSoil, which is also a
> > TTL
> > serialization but with no file suffix. The stack trace indicates that an
> > attempt is being made to parse the resource as RDF/XML... which in this
> > case is incorrect.
> >
> > Any hints on how to override/define this behaviour?
> >
> > Another related question, the large stack trace I receive from the above
> > parsing activity seems to also indicate that the OntModel.read logic
> > randomly processes imports when processing a resource such as [2]. Is
> > this
> > correct?
> >
> > Thanks for any hits folks, I appreciate it.
> > Lewis
> >
> > [0] http://sweetontology.net
> > [1] http://sweetontology.net/reprDataProduct
> > [2] http://sweetontology.net/sweetAll
> > [3] https://paste.apache.org/vLt8
> >
> >>
> 


Re: OntModel.read parsing non-suffixed TTL as RDF/XML

2018-03-13 Thread Andy Seaborne



On 13/03/18 18:44, Lewis John McGibbney wrote:

Hi Andy,
This is correct.
Do you suggest I augment the classpath?
Thank you
Lewis


Yes:

  
org.apache.jena
apache-jena-libs
pom
X.Y.Z
  



On 2018/03/07 17:01:43, Andy Seaborne  wrote:



On 07/03/18 10:59, Andy Seaborne wrote:

Lewis - which version? Do yo have all the apache-jena-libs jars on the
classpath?  RIOT rewirers Jena model reading.


It looks like you only have jena-core of some version on the classpath.



Also, there was an issue around redirect and remapping but it's fixed.

      Andy

On 07/03/18 08:57, Dave Reynolds wrote:

I can't tell from the trace whether you are mapping the import URLs to
local files or are loading directly from the URL. If loading from
local files then you really need suffixes on those. I'll assume you
are loading from the URL ...

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 and don't support RDF/XML
(the official default) that's not going to work.

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.

Dave


On 07/03/18 04:28, lewis john mcgibbney wrote:

Hi Folks,

Over on the SWEET ontology suite [0] we recently changed out canonical
serialization to TTL. Additionally however, we removed all file suffixes
from the resources themselves, therefore although the following resource
[1] is serialized as TTL, you would never know unless you looked at
it or
peeked into the server response.

I am experiencing issues when I attempt to load the SWEET 'master' file
[2], which essentially produces a graph by importing every file
within the
ontology suite. The code I use to do this is as follows.

((OntModel) m).read(url, null, lang); //Where lang is the string
"TTL" or
"TURTLE" depending on previous logic.

The stack trace I get is as follows [3]

As you can see it loads the sweetAll file correctly but chokes on the
imported resource http://sweetontology.net/realmSoil, which is also a
TTL
serialization but with no file suffix. The stack trace indicates that an
attempt is being made to parse the resource as RDF/XML... which in this
case is incorrect.

Any hints on how to override/define this behaviour?

Another related question, the large stack trace I receive from the above
parsing activity seems to also indicate that the OntModel.read logic
randomly processes imports when processing a resource such as [2]. Is
this
correct?

Thanks for any hits folks, I appreciate it.
Lewis

[0] http://sweetontology.net
[1] http://sweetontology.net/reprDataProduct
[2] http://sweetontology.net/sweetAll
[3] https://paste.apache.org/vLt8





Re: OntModel.read parsing non-suffixed TTL as RDF/XML

2018-03-13 Thread Lewis John McGibbney
Hi Andy,
This is correct.
Do you suggest I augment the classpath?
Thank you
Lewis

On 2018/03/07 17:01:43, Andy Seaborne  wrote: 
> 
> 
> On 07/03/18 10:59, Andy Seaborne wrote:
> > Lewis - which version? Do yo have all the apache-jena-libs jars on the 
> > classpath?  RIOT rewirers Jena model reading.
> 
> It looks like you only have jena-core of some version on the classpath.
> 
> > 
> > Also, there was an issue around redirect and remapping but it's fixed.
> > 
> >      Andy
> > 
> > On 07/03/18 08:57, Dave Reynolds wrote:
> >> I can't tell from the trace whether you are mapping the import URLs to 
> >> local files or are loading directly from the URL. If loading from 
> >> local files then you really need suffixes on those. I'll assume you 
> >> are loading from the URL ...
> >>
> >> 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 and don't support RDF/XML 
> >> (the official default) that's not going to work.
> >>
> >> 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.
> >>
> >> Dave
> >>
> >>
> >> On 07/03/18 04:28, lewis john mcgibbney wrote:
> >>> Hi Folks,
> >>>
> >>> Over on the SWEET ontology suite [0] we recently changed out canonical
> >>> serialization to TTL. Additionally however, we removed all file suffixes
> >>> from the resources themselves, therefore although the following resource
> >>> [1] is serialized as TTL, you would never know unless you looked at 
> >>> it or
> >>> peeked into the server response.
> >>>
> >>> I am experiencing issues when I attempt to load the SWEET 'master' file
> >>> [2], which essentially produces a graph by importing every file 
> >>> within the
> >>> ontology suite. The code I use to do this is as follows.
> >>>
> >>> ((OntModel) m).read(url, null, lang); //Where lang is the string 
> >>> "TTL" or
> >>> "TURTLE" depending on previous logic.
> >>>
> >>> The stack trace I get is as follows [3]
> >>>
> >>> As you can see it loads the sweetAll file correctly but chokes on the
> >>> imported resource http://sweetontology.net/realmSoil, which is also a 
> >>> TTL
> >>> serialization but with no file suffix. The stack trace indicates that an
> >>> attempt is being made to parse the resource as RDF/XML... which in this
> >>> case is incorrect.
> >>>
> >>> Any hints on how to override/define this behaviour?
> >>>
> >>> Another related question, the large stack trace I receive from the above
> >>> parsing activity seems to also indicate that the OntModel.read logic
> >>> randomly processes imports when processing a resource such as [2]. Is 
> >>> this
> >>> correct?
> >>>
> >>> Thanks for any hits folks, I appreciate it.
> >>> Lewis
> >>>
> >>> [0] http://sweetontology.net
> >>> [1] http://sweetontology.net/reprDataProduct
> >>> [2] http://sweetontology.net/sweetAll
> >>> [3] https://paste.apache.org/vLt8
> >>>
> 


Re: OntModel.read parsing non-suffixed TTL as RDF/XML

2018-03-13 Thread Lewis John McGibbney
Hi Andy,
This is Jena 3.6.0.
Lewis

On 2018/03/07 10:59:42, Andy Seaborne  wrote: 
> Lewis - which version? Do yo have all the apache-jena-libs jars on the 
> classpath?  RIOT rewirers Jena model reading.
> 
> Also, there was an issue around redirect and remapping but it's fixed.
> 
>   Andy
> 
> On 07/03/18 08:57, Dave Reynolds wrote:
> > I can't tell from the trace whether you are mapping the import URLs to 
> > local files or are loading directly from the URL. If loading from local 
> > files then you really need suffixes on those. I'll assume you are 
> > loading from the URL ...
> > 
> > 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 and don't support RDF/XML (the 
> > official default) that's not going to work.
> > 
> > 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.
> > 
> > Dave
> > 
> > 
> > On 07/03/18 04:28, lewis john mcgibbney wrote:
> >> Hi Folks,
> >>
> >> Over on the SWEET ontology suite [0] we recently changed out canonical
> >> serialization to TTL. Additionally however, we removed all file suffixes
> >> from the resources themselves, therefore although the following resource
> >> [1] is serialized as TTL, you would never know unless you looked at it or
> >> peeked into the server response.
> >>
> >> I am experiencing issues when I attempt to load the SWEET 'master' file
> >> [2], which essentially produces a graph by importing every file within 
> >> the
> >> ontology suite. The code I use to do this is as follows.
> >>
> >> ((OntModel) m).read(url, null, lang); //Where lang is the string "TTL" or
> >> "TURTLE" depending on previous logic.
> >>
> >> The stack trace I get is as follows [3]
> >>
> >> As you can see it loads the sweetAll file correctly but chokes on the
> >> imported resource http://sweetontology.net/realmSoil, which is also a TTL
> >> serialization but with no file suffix. The stack trace indicates that an
> >> attempt is being made to parse the resource as RDF/XML... which in this
> >> case is incorrect.
> >>
> >> Any hints on how to override/define this behaviour?
> >>
> >> Another related question, the large stack trace I receive from the above
> >> parsing activity seems to also indicate that the OntModel.read logic
> >> randomly processes imports when processing a resource such as [2]. Is 
> >> this
> >> correct?
> >>
> >> Thanks for any hits folks, I appreciate it.
> >> Lewis
> >>
> >> [0] http://sweetontology.net
> >> [1] http://sweetontology.net/reprDataProduct
> >> [2] http://sweetontology.net/sweetAll
> >> [3] https://paste.apache.org/vLt8
> >>
> 


Re: OntModel.read parsing non-suffixed TTL as RDF/XML

2018-03-13 Thread Lewis John McGibbney
Hi Dave,
Thank you for the response,

On 2018/03/07 08:57:47, Dave Reynolds  wrote: 
> I can't tell from the trace whether you are mapping the import URLs to 
> local files or are loading directly from the URL. If loading from local 
> files then you really need suffixes on those. I'll assume you are 
> loading from the URL ...

Correct. It is from the URL.

> 
> 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 and don't support RDF/XML (the 
> official default) that's not going to work.
> 
> 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.

I will try this and let you know.
Thank you 
Lewis

> 
> Dave
> 
> 
> On 07/03/18 04:28, lewis john mcgibbney wrote:
> > Hi Folks,
> > 
> > Over on the SWEET ontology suite [0] we recently changed out canonical
> > serialization to TTL. Additionally however, we removed all file suffixes
> > from the resources themselves, therefore although the following resource
> > [1] is serialized as TTL, you would never know unless you looked at it or
> > peeked into the server response.
> > 
> > I am experiencing issues when I attempt to load the SWEET 'master' file
> > [2], which essentially produces a graph by importing every file within the
> > ontology suite. The code I use to do this is as follows.
> > 
> > ((OntModel) m).read(url, null, lang); //Where lang is the string "TTL" or
> > "TURTLE" depending on previous logic.
> > 
> > The stack trace I get is as follows [3]
> > 
> > As you can see it loads the sweetAll file correctly but chokes on the
> > imported resource http://sweetontology.net/realmSoil, which is also a TTL
> > serialization but with no file suffix. The stack trace indicates that an
> > attempt is being made to parse the resource as RDF/XML... which in this
> > case is incorrect.
> > 
> > Any hints on how to override/define this behaviour?
> > 
> > Another related question, the large stack trace I receive from the above
> > parsing activity seems to also indicate that the OntModel.read logic
> > randomly processes imports when processing a resource such as [2]. Is this
> > correct?
> > 
> > Thanks for any hits folks, I appreciate it.
> > Lewis
> > 
> > [0] http://sweetontology.net
> > [1] http://sweetontology.net/reprDataProduct
> > [2] http://sweetontology.net/sweetAll
> > [3] https://paste.apache.org/vLt8
> > 
> 


Re: OntModel.read parsing non-suffixed TTL as RDF/XML

2018-03-13 Thread Lewis John McGibbney
Hi Laura,
Sorry for late response.
Right now that is unquantified...
We are engaged in ontology alignment activities such as 
https://github.com/ESIPFed/sweet/tree/master/alignments
With other initiatives listed in our issue tracker
https://github.com/ESIPFed/sweet/issues
I 'was' going to try analyzing WebDataCommons to see if SWEET URI's were 
contained anywhere.
http://www.webdatacommons.org/
I will say however, that SWEET is included in several OGC 
recommendations/standards. I am in the process of updating these documents to 
use the new http://sweetontology.net URI scheme.
If you are interested in joining the community get us below
https://github.com/ESIPFed/sweet#community

Lewis

On 2018/03/07 06:20:15, "Laura Morales"  wrote: 
> Sorry for the OT question but it's the first time I learn about SWEET. Is 
> there any list of datasets/graphs using this vocabulary?
>  
>  
> 
> Sent: Wednesday, March 07, 2018 at 5:28 AM
> From: "lewis john mcgibbney" 
> To: users@jena.apache.org
> Subject: OntModel.read parsing non-suffixed TTL as RDF/XML
> Hi Folks,
> 
> Over on the SWEET ontology suite [0] we recently changed out canonical
> serialization to TTL. Additionally however, we removed all file suffixes
> from the resources themselves, therefore although the following resource
> [1] is serialized as TTL, you would never know unless you looked at it or
> peeked into the server response.
> 
> I am experiencing issues when I attempt to load the SWEET 'master' file
> [2], which essentially produces a graph by importing every file within the
> ontology suite. The code I use to do this is as follows.
> 
> ((OntModel) m).read(url, null, lang); //Where lang is the string "TTL" or
> "TURTLE" depending on previous logic.
> 
> The stack trace I get is as follows [3]
> 
> As you can see it loads the sweetAll file correctly but chokes on the
> imported resource http://sweetontology.net/realmSoil, which is also a TTL
> serialization but with no file suffix. The stack trace indicates that an
> attempt is being made to parse the resource as RDF/XML... which in this
> case is incorrect.
> 
> Any hints on how to override/define this behaviour?
> 
> Another related question, the large stack trace I receive from the above
> parsing activity seems to also indicate that the OntModel.read logic
> randomly processes imports when processing a resource such as [2]. Is this
> correct?
> 
> Thanks for any hits folks, I appreciate it.
> Lewis
> 
> [0] http://sweetontology.net[http://sweetontology.net]
> [1] 
> http://sweetontology.net/reprDataProduct[http://sweetontology.net/reprDataProduct]
> [2] http://sweetontology.net/sweetAll[http://sweetontology.net/sweetAll]
> [3] https://paste.apache.org/vLt8[https://paste.apache.org/vLt8]
> 
> --
> http://home.apache.org/~lewismc/[http://home.apache.org/~lewismc/]
> http://people.apache.org/keys/committer/lewismc
> 


Re: OntModel.read parsing non-suffixed TTL as RDF/XML

2018-03-07 Thread Andy Seaborne



On 07/03/18 10:59, Andy Seaborne wrote:
Lewis - which version? Do yo have all the apache-jena-libs jars on the 
classpath?  RIOT rewirers Jena model reading.


It looks like you only have jena-core of some version on the classpath.



Also, there was an issue around redirect and remapping but it's fixed.

 Andy

On 07/03/18 08:57, Dave Reynolds wrote:
I can't tell from the trace whether you are mapping the import URLs to 
local files or are loading directly from the URL. If loading from 
local files then you really need suffixes on those. I'll assume you 
are loading from the URL ...


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 and don't support RDF/XML 
(the official default) that's not going to work.


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.


Dave


On 07/03/18 04:28, lewis john mcgibbney wrote:

Hi Folks,

Over on the SWEET ontology suite [0] we recently changed out canonical
serialization to TTL. Additionally however, we removed all file suffixes
from the resources themselves, therefore although the following resource
[1] is serialized as TTL, you would never know unless you looked at 
it or

peeked into the server response.

I am experiencing issues when I attempt to load the SWEET 'master' file
[2], which essentially produces a graph by importing every file 
within the

ontology suite. The code I use to do this is as follows.

((OntModel) m).read(url, null, lang); //Where lang is the string 
"TTL" or

"TURTLE" depending on previous logic.

The stack trace I get is as follows [3]

As you can see it loads the sweetAll file correctly but chokes on the
imported resource http://sweetontology.net/realmSoil, which is also a 
TTL

serialization but with no file suffix. The stack trace indicates that an
attempt is being made to parse the resource as RDF/XML... which in this
case is incorrect.

Any hints on how to override/define this behaviour?

Another related question, the large stack trace I receive from the above
parsing activity seems to also indicate that the OntModel.read logic
randomly processes imports when processing a resource such as [2]. Is 
this

correct?

Thanks for any hits folks, I appreciate it.
Lewis

[0] http://sweetontology.net
[1] http://sweetontology.net/reprDataProduct
[2] http://sweetontology.net/sweetAll
[3] https://paste.apache.org/vLt8



Re: OntModel.read parsing non-suffixed TTL as RDF/XML

2018-03-07 Thread Andy Seaborne
Lewis - which version? Do yo have all the apache-jena-libs jars on the 
classpath?  RIOT rewirers Jena model reading.


Also, there was an issue around redirect and remapping but it's fixed.

Andy

On 07/03/18 08:57, Dave Reynolds wrote:
I can't tell from the trace whether you are mapping the import URLs to 
local files or are loading directly from the URL. If loading from local 
files then you really need suffixes on those. I'll assume you are 
loading from the URL ...


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 and don't support RDF/XML (the 
official default) that's not going to work.


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.


Dave


On 07/03/18 04:28, lewis john mcgibbney wrote:

Hi Folks,

Over on the SWEET ontology suite [0] we recently changed out canonical
serialization to TTL. Additionally however, we removed all file suffixes
from the resources themselves, therefore although the following resource
[1] is serialized as TTL, you would never know unless you looked at it or
peeked into the server response.

I am experiencing issues when I attempt to load the SWEET 'master' file
[2], which essentially produces a graph by importing every file within 
the

ontology suite. The code I use to do this is as follows.

((OntModel) m).read(url, null, lang); //Where lang is the string "TTL" or
"TURTLE" depending on previous logic.

The stack trace I get is as follows [3]

As you can see it loads the sweetAll file correctly but chokes on the
imported resource http://sweetontology.net/realmSoil, which is also a TTL
serialization but with no file suffix. The stack trace indicates that an
attempt is being made to parse the resource as RDF/XML... which in this
case is incorrect.

Any hints on how to override/define this behaviour?

Another related question, the large stack trace I receive from the above
parsing activity seems to also indicate that the OntModel.read logic
randomly processes imports when processing a resource such as [2]. Is 
this

correct?

Thanks for any hits folks, I appreciate it.
Lewis

[0] http://sweetontology.net
[1] http://sweetontology.net/reprDataProduct
[2] http://sweetontology.net/sweetAll
[3] https://paste.apache.org/vLt8



Re: OntModel.read parsing non-suffixed TTL as RDF/XML

2018-03-07 Thread Dave Reynolds
I can't tell from the trace whether you are mapping the import URLs to 
local files or are loading directly from the URL. If loading from local 
files then you really need suffixes on those. I'll assume you are 
loading from the URL ...


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 and don't support RDF/XML (the 
official default) that's not going to work.


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.


Dave


On 07/03/18 04:28, lewis john mcgibbney wrote:

Hi Folks,

Over on the SWEET ontology suite [0] we recently changed out canonical
serialization to TTL. Additionally however, we removed all file suffixes
from the resources themselves, therefore although the following resource
[1] is serialized as TTL, you would never know unless you looked at it or
peeked into the server response.

I am experiencing issues when I attempt to load the SWEET 'master' file
[2], which essentially produces a graph by importing every file within the
ontology suite. The code I use to do this is as follows.

((OntModel) m).read(url, null, lang); //Where lang is the string "TTL" or
"TURTLE" depending on previous logic.

The stack trace I get is as follows [3]

As you can see it loads the sweetAll file correctly but chokes on the
imported resource http://sweetontology.net/realmSoil, which is also a TTL
serialization but with no file suffix. The stack trace indicates that an
attempt is being made to parse the resource as RDF/XML... which in this
case is incorrect.

Any hints on how to override/define this behaviour?

Another related question, the large stack trace I receive from the above
parsing activity seems to also indicate that the OntModel.read logic
randomly processes imports when processing a resource such as [2]. Is this
correct?

Thanks for any hits folks, I appreciate it.
Lewis

[0] http://sweetontology.net
[1] http://sweetontology.net/reprDataProduct
[2] http://sweetontology.net/sweetAll
[3] https://paste.apache.org/vLt8



Re: OntModel.read parsing non-suffixed TTL as RDF/XML

2018-03-06 Thread Laura Morales
Sorry for the OT question but it's the first time I learn about SWEET. Is there 
any list of datasets/graphs using this vocabulary?
 
 

Sent: Wednesday, March 07, 2018 at 5:28 AM
From: "lewis john mcgibbney" 
To: users@jena.apache.org
Subject: OntModel.read parsing non-suffixed TTL as RDF/XML
Hi Folks,

Over on the SWEET ontology suite [0] we recently changed out canonical
serialization to TTL. Additionally however, we removed all file suffixes
from the resources themselves, therefore although the following resource
[1] is serialized as TTL, you would never know unless you looked at it or
peeked into the server response.

I am experiencing issues when I attempt to load the SWEET 'master' file
[2], which essentially produces a graph by importing every file within the
ontology suite. The code I use to do this is as follows.

((OntModel) m).read(url, null, lang); //Where lang is the string "TTL" or
"TURTLE" depending on previous logic.

The stack trace I get is as follows [3]

As you can see it loads the sweetAll file correctly but chokes on the
imported resource http://sweetontology.net/realmSoil, which is also a TTL
serialization but with no file suffix. The stack trace indicates that an
attempt is being made to parse the resource as RDF/XML... which in this
case is incorrect.

Any hints on how to override/define this behaviour?

Another related question, the large stack trace I receive from the above
parsing activity seems to also indicate that the OntModel.read logic
randomly processes imports when processing a resource such as [2]. Is this
correct?

Thanks for any hits folks, I appreciate it.
Lewis

[0] http://sweetontology.net[http://sweetontology.net]
[1] 
http://sweetontology.net/reprDataProduct[http://sweetontology.net/reprDataProduct]
[2] http://sweetontology.net/sweetAll[http://sweetontology.net/sweetAll]
[3] https://paste.apache.org/vLt8[https://paste.apache.org/vLt8]

--
http://home.apache.org/~lewismc/[http://home.apache.org/~lewismc/]
http://people.apache.org/keys/committer/lewismc


OntModel.read parsing non-suffixed TTL as RDF/XML

2018-03-06 Thread lewis john mcgibbney
Hi Folks,

Over on the SWEET ontology suite [0] we recently changed out canonical
serialization to TTL. Additionally however, we removed all file suffixes
from the resources themselves, therefore although the following resource
[1] is serialized as TTL, you would never know unless you looked at it or
peeked into the server response.

I am experiencing issues when I attempt to load the SWEET 'master' file
[2], which essentially produces a graph by importing every file within the
ontology suite. The code I use to do this is as follows.

((OntModel) m).read(url, null, lang); //Where lang is the string "TTL" or
"TURTLE" depending on previous logic.

The stack trace I get is as follows [3]

As you can see it loads the sweetAll file correctly but chokes on the
imported resource http://sweetontology.net/realmSoil, which is also a TTL
serialization but with no file suffix. The stack trace indicates that an
attempt is being made to parse the resource as RDF/XML... which in this
case is incorrect.

Any hints on how to override/define this behaviour?

Another related question, the large stack trace I receive from the above
parsing activity seems to also indicate that the OntModel.read logic
randomly processes imports when processing a resource such as [2]. Is this
correct?

Thanks for any hits folks, I appreciate it.
Lewis

[0] http://sweetontology.net
[1] http://sweetontology.net/reprDataProduct
[2] http://sweetontology.net/sweetAll
[3] https://paste.apache.org/vLt8

-- 
http://home.apache.org/~lewismc/
http://people.apache.org/keys/committer/lewismc