On 19/08/13 18:43, Norman Walsh wrote:
Hi,
I'm calling RdfDataMgr.read() to load a model (into either a Model or a Dataset
depending on some other parameters).
Shh, but if you load as a dataset and it's actually a graph, the default
graph gets loaded.
And if it's a graph load and the file is actually a dataset format, the
default graph of the data goes into the graph to be loaded.
Come RDF 1.1, it is likely that TriG will allow having the default graph
without {} around it, so Turtle is a subset of TriG.
When the data loaded contains errors, such as:
<c:date
rdf:datatype="http://www.w3.org/2001/XMLSchema#date";>2012-11-00</c:date>
I get logged WARNings. Do I have any control over what happens when
invalid data is encountered? In particular, I might like to have an
option to either abort the load or continue skipping the invalid
triple (that seems to be the default).
WARN is just a warning, and not a stop.
Strictly, it's legal RDF. Just because the lexical form is illegal,
does not mean it's invalid as base RDF.
N-triples and N-Quads does not check by default IIRC.
Even more importantly, I'd like to be able to change the warning
message to include URI of the document that contains the error...possible?
Yes, sort of. It's all controlled by a "profile", which includes error
handler and also whether to check literals for datatype validity.
It's not visible through the RDFDataMgr interface but through the lower
level RiotReader API.
RiotReader is restricted to the built-in readers; the lifecycle is
create-parser, set it up and call .parse.
LangRIOT parser = RiotReader.createParser(...) ;
parser.setProfile(...) ;
parser.parse() ;
See RiotLib for some canned ways to create a parser profile. Some
features are necessary for the language.
RDFDataMgr is the simple-to-use API with one extension point - passing
in a Context object as a way of tunnelling parameters from client to
parser (there are enough API variations already - java syntax tax:-()
It seems reasonable to add some e.g. via the context. I can imagine
that not all parsers will support this. If an extension language is
added and it's based on some existing other codebase, the idea of RIOT's
errorhandler may be inconvenient to fit in.
So as not to forget it:
https://issues.apache.org/jira/browse/JENA-518
Be seeing you,
norm
++beers and counting
Andy
