[snip] >> I agree. I actually do not care if it's a `java.util.Map` or something >> else. It's just "something" that gives you a `BlankNode` from a label, >> consistently. It could be an actual Map, or something else based on >> UUID, it doesn't matter. What matters is that there is an implicit >> state, and I argue that this is not a requirement. Passing that >> "something" as an argument, and returning the new state along with the >> `BlankNode` (whether it's stateful of stateless), would achieve your >> requirements the same way. > > > Function<String, BlankNode>
Yes, that is probably enough. > If I follow your argument, that would require either state itself elsewhere > or private access to make blank nodes reproducibly because createBlankNode() > is the only factory way to create a bnode. Correct. > So either state still exists, just moved, and if this is a /commons/RDF we > have to define that. Or there is another route to making bNodes which > defeats the purpose of the factory as it currently is. IMHO, what's *really* needed in common-rdf is a way to create/manipulate the RDF model. The notion of "factory" brings too much baggage with it... I think what I mean is well captured in the RDF interface at [1]. [1] https://gist.github.com/betehess/8983dbff2c3e89f9dadb > A stateless factory version is createBlankNode(UUID) but that idea didn't > get much traction (I'd be happy with it - at the abstract synatx level, a > 1-1 correspondence with UUIDs is just the "arbitrary set" the spec talks > about). I guess you meant `UUID createBlankNode()`. That is actually what plantain-js does in banana-rdf: blank nodes *are* UUIDs. In a previous life, I have met people who thought that generating them would be too slow compared to other methods. I have never been in that case myself and I have no grief against using UUID. > Actually, better would be String in UUID format or at least align with > uniqueReference - details. That is an interesting idea. I would suggest to add an optional label part in the String to improve the serialization when this information is available. We should standardize on the format for the String on a best-effort basis. That was a requirement in the project I was working on with TimBL while at W3C: we wanted to read, then update, then re-serialize the graph, while preserving the labels, because a lot of them were written by humans. >> I actually think that `createBlankNode(String)` *should not* belong to >> the factory interface. That is something external to the factory in >> its essence, which is there just because it makes things "more >> convenient". For example, a parser would have it's own state anyway, >> whether it lives *in* the factory or *outside* of it. > > > The parser does not have long term state. See Jena RIOT - they emit a > stream of triples. No state over the run. Do you mean that the state is scoped to the parsing? Alexandre > > (except RDF/XML because of the "no reuse" of bnodeid but let's skip over > RDF/XML :-). > > Andy > >> >> Alexandre >> >>> >>> Andy > >
