On 05/11/15 16:11, A. Soroka wrote:
On Nov 5, 2015, at 11:02 AM, Andy Seaborne <[email protected]> wrote:
On 05/11/15 15:44, A. Soroka wrote:
Yeah, I basically copied the “parallel semantics” of ja:graph and 
ja:defaultGraph from DatasetAssembler. Perhaps I misunderstood them?
If you think it's a problem, do you have a better name?

I’m now a bit confused about what they mean and what ja:data is supposed to 
mean, and I don’t want to spread my confusion any further! {grin} To (try to) 
get some clarity: are they supposed to have the same meaning (they do now in my 
PR, and I really think they do in DatasetAssembler)? If they are supposed to 
have a different meaning, and one of those meanings is “load from this URI”, 
what is the difference in that and the newly-introduced ja:data predicate?


They are different.

If you call assembler.open for the object of ja:defaultGraph it will create a model. It does not know about datasets at that point. You get a regular model in-memory.

Adding to the in-mem dataset with addNamedModel or setDefaultModel will be a copy into the datastructures of the in-mem dataset.

The use cases for direct file loading are:


1/ Load file into dataset.
RDFDataMgr.read(dataset, file)
  Case 1a: quads
  Case 1b: triples


2/ Load file to graph
  Case 2a: default graph
       RDFDataMgr.read(dataset.getdefaultModel(), file)
  Case 2b: named graph
       RDFDataMgr.read(dataset.getNamedModel(), file)

Note: When asked to read triples and it's a quads file, the RDFDataMgr outputs just the triples from the default graph of the input (it does not know it's reading into a named graph - it's just a destination of a stream of triples).

        Andy





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?

See all the testing/ directories.

Thanks! I’ll get myself up to speed on this style of testing.

---
A. Soroka
The University of Virginia Library


They could go in src/test/resources but as they are loaded a plain files from 
testing/ it's more realistic.

For lots of files and manifests its easier.

And the base URI issues of class loaded resources are horrible.

        Andy


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