mention that factory is the only entry point to create new objects

[bergos]

During a discussion about cloning terms with new values came up that it should be more clear that the factory is the only entry point to creates new objects. Maybe we should mention it in the spec.

[timbl]

Not sure I understand the issue. Lots of functions create new objects -- like take a string and convert it to a new Literal -- what is the point here?

[timbl]

Do you mean duck typing is not allowed -- don't make up your own?

[RubenVerborgh]

Having an “only entry point” seems a bit overspecified. The spec defines a common entry point all implementations should have, but each implementation should be free to have other entry points IMHO.

[blake-regalia]

I support encouraging/requiring implementers to only create new Term objects from factory only - this does not mean they cannot use multiple secondary entry points which themselves invoke the factory's primary "entry point". I think the motivation is to ensure that stores can do all necessary indexing when new Terms are instantiated, especially when mixing libraries.

[niklasl]

Is it expected that the evolution of the API will lead to more features of the terms themselves, such as Term.getPName() or perhaps even Node.getProperties() (the latter of which I'd probably advice against)? Or are terms simply thin value objects? If they are simple, I see little need for any value factory.

If they need access to at least prefix bindings, they should have a "store" member (or a "prefix manager"), or similar. That thing should also be a factory capable or producing instances. (I think this is more complex though. Also, indexing upon production of values isn't necessarily a good thing. For one, it might affect performance when doing basic format conversions.)

In Python's RDFLib, the terms themselves are (fairly) simple. High-level convenience access is provided through the Resource class. This combines the backing store and the identifier, enabling users to access the subjects, objects, prefixed names etc. I'm thinking something similar may be nice to build upon this API, and should inform these design decisions. (SimpleRDF comes to mind.)

Anyhow, we should strive for simplicity. Creating value objects directly seems more simple to me, to keeps things clearly separated.

[bergos]

Do you mean duck typing is not allowed

@timbl It's either the other way round, don't use instanceof always check the type of a term with .termType, so you can handle objects of other implementations.

...but each implementation should be free to have other entry points

@RubenVerborgh I see this as high level API feature. If there are new entry points, still the factory should be used internal. The comment of @blake-regalia describes the intention for it very well.

I see little need for any value factory.

@niklasl Without factory it's not possible to control which instance of objects an external library creates. If we would have only one reference implementation, that is used by everyone, than I would agree, but we will have more with different features. One will be better for streaming, the other one is better for fast in memory lookups and another one does a better job on embedded devices.

Maybe we should describe the concept and the need for the factory, not just it's "only entry point". Could be also part of a primer.

[blake-regalia]

@bergos The same goes for .datatype: https://github.com/bergos/rdf-data-model-test-suite/issues/4