Yeah, I basically copied the “parallel semantics” of ja:graph and 
ja:defaultGraph from DatasetAssembler. Perhaps I misunderstood them?

I will definitely gin up some file-based examples. Is there a standard way to 
do that in Jena tests? I.e. should I put documents in the test classpath, or 
something else? 

---
A. Soroka
The University of Virginia Library

> On Nov 5, 2015, at 10:35 AM, Andy Seaborne <[email protected]> wrote:
> 
> 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> .
>> 
> 

Reply via email to