Ha! Actually, that’s how I originally had it (direct link to datasources, files 
of quads or triples, etc.). But I wanted to make it "look more like" what 
already exists in the Assembler vocabulary! {grin}

I can definitely work back to that approach, but also leave the option of the 
“build a model by some means and copy it in” for flexibility. That feature 
will, as you say, require some careful docs. We don’t want people thinking that 
they are building some kind of inferring Dataset.

I will add ja:data as you show and set it up to act usefully. 

Incidentally, I've added ja:MemoryDataset and now I’ll be adding ja:data. Is 
there some way I can add these to the assembler vocabulary at:

https://jena.apache.org/documentation/assembler/assembler.ttl

or is that generated from something?

P.S. Sorry about the missing prefixes!

---
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> .

Reply via email to