Does this seem like a reasonable approach? It should allow users to
build up their data by whatever means they like, including using
inferencing models to generate assertions, then add them to the
in-memory container.
That's an interesting possibility that hadn't occurred to me. It's a
copy-in and the implications of that will need to be clear.
Just relying on ja:MemoryModel and ja:externalContent for the cases of
loading files risks a load-copy though. It could be "optimzied"
What about allowing files to be directly pointed to from the assembler
for the ja:MemoryDataset?
Example:
-----------------------------------
@prefix ja: <http://jena.hpl.hp.com/2005/11/Assembler#> .
<test:simpleExample> a ja:MemoryDataset ;
ja:data <file:///some/data.trig> ;
ja:data <file:///some/data.ttl> ;
ja:graph [ ja:data <file:///some/data2.ttl> ] ;
ja:graph
[ ja:graphName <test:namedGraphExample> ;
ja:data <file:///some/data3.ttl> ] .
-----------------------------------
The ability to load trig, NQuads in the dataset:
ja:data <file:///some/data.trig> ;
If a triples form is given, it loads the default graph. This is what
Jena does already. These are both RDFDataMgr.read(dataset, file) ;
The ja:graph for specific graphs:
Default graph (uniformity):
ja:graph [ ja:data <file:///some/data2.ttl> ] ;
and named graphs
ja:graph
[ ja:graphName <test:namedGraphExample> ;
ja:data <file:///some/data3.ttl> ] .
I like the build-copy idea - these also add the core tasks of loading a
file into a dataset in a direct way.
Thoughts?
Andy
--- A. Soroka The University of Virginia Library
Prefixes !!!!!!!!!!!!!1
@prefix ja: <http://jena.hpl.hp.com/2005/11/Assembler#> .
<test:simpleExample> a ja:MemoryDataset ;
ja:defaultGraph <test:defaultGraphDef> ;
ja:namedGraph <test:namedGraphDef> .
<test:defaultGraphDef>
a ja:MemoryModel ;
ja:content [ ja:externalContent <file:///some/triples.nt> ] .
<test:namedGraphDef> a ja:MemoryModel ;
ja:content
[ ja:externalContent <file:///some/other/triples.nt> ] ;
ja:graphName <test:namedGraphExample> .
