RDFReaderFactoryRIOT

[Claude Warren <cl...@xenei.com>]

RDFReaderFactoryRIOT does not seem to implement the full RDFReaderF
interface in as much as setReaderClassName does not actually add the reader
to the list of readers.

Is there a reason for this?  How does an implementation know (at run time)
that the RDFReaderFactoryRIOT is in use and that readers can not be added?
 Any help here would be appreciated.

Claude

-- 
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren

Re: RDFReaderFactoryRIOT

[Andy Seaborne <an...@apache.org>]

On 28/10/13 14:49, Claude Warren wrote:
> RDFReaderFactoryRIOT does not seem to implement the full RDFReaderF
> interface in as much as setReaderClassName does not actually add the reader
> to the list of readers.
>
> Is there a reason for this?  How does an implementation know (at run time)
> that the RDFReaderFactoryRIOT is in use and that readers can not be added?
>   Any help here would be appreciated.

RDFReaderFactoryRIOT isn't used.  It just an adapter in case of need. 
It can be deleted.


See IO_JenaReaders.wireIntoJena() for the adapters.

RIOT looks up the MIME type of language name when the app decides to 
read in data.  See RDFDataMgr.

Class-based loading of different readers is a feature of jena-core - 
RIOT has it's own registry of languages, MIME types and parsers.  It's a 
lot more complicated; it has a concept of parser separate from model.

RIOT Parsers generate a stream of triples - a model is one possible 
destination.  There is no concept of per-model reader - it's not 
something that got used much except for RDF/XML configuration.

As far as I'm concerned, RIOT is the way to do things and the old code 
is merely there for compatibility.

The limitation is that RIOT depends on datasets and quads which aren't 
in jena-core.

One way is to simply merge jena-arq and jena-core then remove all the 
legacy.

	Andy

>
> Claude
>