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