Yes, the SPI is likely fine, or we will find out otherwise if we try a new API. :)
A new API is clearly no small thing. I suppose one way to approach the thing would be to look at what Clerezza and RDF4J 4 and Commons RDF have come up with, what worked and what didn't, and then bring in our own use cases and ideas... The two "asks" I've heard recently from Jena users are: immutability and Streams. I'm guessing there are others. I would like to take advantage of Optional for some of the attributes of a node (e.g. return the lang of a literal as Optional). Other thoughts? It's fun to make wish lists at the end of the year. :grin: ajs6f > On Nov 16, 2017, at 11:47 AM, Andy Seaborne <a...@apache.org> wrote: > > 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.
