> On Nov 22, 2019, at 3:37 AM, Dave Reynolds <dave.e.reyno...@gmail.com> wrote > I suspect the underlying point is that the second form of getProperty is > badly named and in retrospect perhaps could have been called makeProperty.
Worse; here is the Javadoc for that getProperty: > Return a Property instance with the given URI in this model. <i>This method > behaves identically to <code>createProperty(String,String)</code></i> and > exists as legacy: createProperty is now capable of, and allowed to, reuse > existing objects. It's semi-deprecated. It seems that "createProperty" is to be preferred? The underlying point is actually this very confusion; that (IMO) the profusion of methods on Model and some of the other core classes are less helpful to less-experienced users than they might seem to more-experienced users. An API with fewer and clearer methods per class, even at the cost of some verbosity, might be a good goal. To be clear, I'm not criticizing the work that brought us here. I think Jena's attention to keeping the API backwards-compatible has been one of its great strengths. I'm just calling attention to the fact that if we want to simplify, this is the time to do it, at a major version change. ajs6f ajs6f
