On 20/02/13 04:13, Simon Helsen wrote:
Hi everyone,
I was using the following API to translate http content types into the
appropriate jena language to use in I/O. So something like this:
String jenaLanguage = WebContent.contentTypeToLang(content-type
).getName();
m.write(out, jenaLanguage);
getName() is a display string - it returns "N-Triples" - the contract
isn't really that its a Jena writer name (or reader for that matter)
This will do it:
.getName().toUpperCase()
All the writer names are UC; there is also "Turtle".
It's easy enough to add "N-Triples" to the last days of the core reader
and writer setup. Done (this is the only case BTW).
In riot-output (post 2.10.0), you can use the lang directly in:
RDFDataMgr.write(model, out, lang) ;
And in 2.10.0:
RDFDataMgr.read(model, in, lang) ;
After the big module reorg we can use symbols not strings:
model.read(in, Lang) ;
model.write(in, Lang) ;
will work (and, IMO, be preferred over strings, but generally use
RDFDataMgr).
This seems to work well for turtle, rdf/xml, n3, but when I used it for
ntriples, the name was not recognized by the writer because of the 's' in
N-Triples. I noticed then that in SysRIOT.wireIntoJena, there is a
specific new reader added for ntriples which does recognize N-TRIPLES (as
well as N-TRIPLE).
Core Jena already has readers for N-TRIPLES and N-TRIPLE.
Core Jena already has writers for N-TRIPLES and N-TRIPLE.
The language name (in a Lang object) however follows the correct
presentation form "N-Triples".
I guess this is strictly speaking not a bug, but it would be nice if I
didn't have to register a writer for N-TRIPLES myself given that there is
one for N-TRIPLE.
thanks
Simon
