Yes, I think it is best done as a new API.
Modifications to the existing one are likely to run into problems
somewhere and given the number of users, and the change over time on
upgrades, having compatibility matters as does gradual migration
A complicates case: Dataset.getModel(String) returns a model. No idea
whether it is immutable or not or how it will be used. Assigning to a
ImmutableModel does not guaratee anything - it helps the caller not make
mistakes but the model is not immutable. Some code calling getModel can
change it. And the union model isn't immutable! - it's a dynamic union
and any name graph change will be reflected. The world is multithreaded.
But the main reason for a new API is that this is just one of several
features to include so to make it a success these different features
need to come together into one *agreed* design.
The good news is that it can target the SPI.
(I see no value in changing the SPI for this - that's not it's role)
ARQ's API is really very small. A design that took a dataset+model view
of the world would be a good thing.
Andy
See also commons-rdf.
That is RDF 1.1 compliant
On 15/11/17 15:52, aj...@apache.org wrote:
So it seems to me that if we want to introduce immutable types, we might
want to do that in the context of a completely new API. The use of the
Java 8 Streams API is also something that has been mooted as something
that might merit a new Jena API. (Instead of mixing things up in the
current one.)
I'm not sure how that plays out with ARQ, though. We would want people
to be able to use the new types with ARQ without much difficulty.
