Hi there,
I got ja:data working but ja:graph alluded me. After some code digging,
it seems it is a synonym for ja:defaultGraph but ja:defaultGraph goes to
a full-blown model description.
Tests from files would be good and they can be used in documentation
examples as well.
-----------------------
@prefix ja: <http://jena.hpl.hp.com/2005/11/Assembler#> .
<test:simpleExample> a ja:MemoryDataset ;
ja:data <file:data.trig> ;
ja:data <file:data1.ttl> ;
ja:graph [ ja:data <file:data2.ttl> ] ;
ja:graph
[ ja:graphName <http://example/g3> ;
ja:data <file:data3.ttl> ] ;
.
-----------------------
and I tried:
DatasetFactory.assemble("assembler.ttl") ;
OK - wiring not in place yet
then
Model m = RDFDataMgr.loadModel("assembler.ttl") ;
Resource r = m.createResource("test:simpleExample") ;
Dataset ds = (Dataset)new InMemDatasetAssembler().open(r) ;
I was expecting ja:graph to be a direct description - not needing a
ja:MemoryModel description
ja:graph is needed to associate a name with a triples file.
I took a go at an implementation:
---------------------
open( ...) {
...
// Instead of: final Resource defaultGraphDef =
multiValueResource(root, pGraph)
.forEach(r->readGraphDesc(dataset, r));
...
}
// May need better checking for expected Resource/String things.
private void readGraphDesc(Dataset dataset, Resource r) {
String gn = null ;
if ( r.hasProperty(pGraphName)) {
Resource rgn = r.getProperty(pGraphName).getResource() ;
gn = rgn.getURI() ;
}
String dataFn = getAsStringValue(r, data) ;
if ( gn == null )
RDFDataMgr.read(dataset.getDefaultModel(), dataFn);
else
RDFDataMgr.read(dataset.getNamedModel(gn), dataFn);
}
---------------------
Andy
On 02/11/15 16:44, A. Soroka wrote:
I’ve added “direct data links” in the style Andy outlines below to this
JENA-624 PR, with tests.
Feedback eagerly desired!
---
A. Soroka
The University of Virginia Library
On Oct 30, 2015, at 3:05 PM, Andy Seaborne <[email protected]> wrote:
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> .
