Okay, I will roll on with the current design, which uses ja:namedGraph to call
out named graphs, ja:graphName to name them, and ja:data to load content into
them, and ja:data directly on the root to load either triples into the default
graph or quads into wherever they need to go, based on their graph node.
I will make a ticket to bring assembler.ttl into sync with the various
assembler vocabularies, which we’ll eventually do with all of the copious free
time that Jena devs have. {grin}
I will add some file-based tests (as discussed previously) and get another
revision in for review.
---
A. Soroka
The University of Virginia Library
> On Nov 7, 2015, at 11:49 AM, Andy Seaborne <[email protected]> wrote:
>
> On 05/11/15 18:14, A. Soroka wrote:
>> Ah, you use that code because using ja:graph in the way that you are using
>> it requires distinguishing between named graphs and the default graph,
>> whereas because I am requiring the use of ja:namedGraph to construct a named
>> graph, that part of my code is simpler. This gives me to ask yet another
>> question (sorry!). Should I be allowing the use of ja:graph to construct a
>> named graph as you show? I had restricted it to the use of ja:namedGraph.
>
> Personally, I expect ja:data to be the important case. That's creating the
> file or files and just loading them.
>
> ja:namedGraph is already in use but the purpose is roughly the same so it's a
> reasonable use.
>
> ja:defaultGraph is a related case - loading into the default graph and
> ignoring any named graphs.
>
> That's why I had ja:graph - one predciate, and the further information (name
> or no name) determined the place to put the triples.
>
> ja:namedGraph + ja:defaultGraph without ja:graph is fine. ja:data is the
> form to encourage.
>
>> Unfortunately, these predicates don’t appear in assembler.ttl and the
>> versions in DatasetAssemblerVocab have no comments to clarify their use.
>
> History. jena-core is graphs, jena-arq is datasets.
>
> All mixed up with the jena-core/jena-arq split. I felt it was too big a step
> to do a major code reorg for Jena3 to sort that out overall - and
> people-bandwidth limitation with seemingly random impact on
> users/applications.
>
>> Speaking of the fact that there is a separate DatasetAssemblerVocab that
>> contains ja:graph, ja:defaultGraph, and so forth: I added ja:MemoryDataset
>> and ja:data directly to JA. Should they go in another class, specific to
>> InMemoryDatasetAssembler?
>
> Where does not matter too much. ja:MemoryDataset in JA can't be used in
> jena-core for anything meaningful. ja:data is a braod term so JA makes sense.
>
> We can fine tune when the code is in.
>
> Andy
