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
