What belongs to the rdf class?

[retog]

The global rdf class should be the convenient main entry point of the API and allow access to the most commonly needed RDF specific functionality.

Some thoughts:

What should stay:

• factory method for creation of nodes and triples
• factory method for creation of graphs
• factory method to create datasets (quad stores)

  What should be removed:

• prefixMap/prefix resolution: This should go to a CURIE library as not RDF specific: there are no prefixes in RDF (even though some concrete syntaxes support CURIEs and similar mechanism)
• encodeString: not RDF specific
• AbstractGraph: this is a utility for service provider, rdf should be the entry point for API users
• Triple class: users should create triples via factory method, unclear what the benefit is of having this visible

  What should be added:

• methods to get serializers and parsers and/or to serilaize and parse: serializing and parsersing are very frequently needed functionality so it should be available directly from the main API access point. Of course, everything offered at this level is independent of any concrete format, it simple provides an extensible way to get/use the available parsers and serializers by specifying the desired format (of course, using media types as the standard mechanism for identifying data formats), see also: https://github.com/rdf-ext/rdf-mime-type-util/issues/1

  The discussion is open....

[bergos]

Comments to: What should be removed:

• prefixMap must stay, because .createNamedNode() will support do .resolve() for CURIEs in the future.
• encodeString is not an official API method and should only be used by Graph implementations which inherit from AbstractGraph.
• AbstractGraph is just one possibility to implement a Graph. It's possible to implement a Graph interface completely from scratch. If you want to use it, use require()
• We haven't decided yet how to change the classes used by the factory methods. At the moment it would work by changing rdf.NamedNode, rdf.Triple, etc.

Comments to: What should be added:

Please have in mind that CommonJS require() is now also part of the RDF-Ext concept. The distribution builder + browserify will be bridge to access the packages in the browser.

[retog]

Answer to: Comments to: What should be removed:

• Even if createNamedNode will support resolving CURIEs (or maybe safe CURIEs to prevent ambiguity) it doesn't mean it has to do the resolution itself, a CURIE library is useful independently of RDF and so it should use such an external library
• AbstractGraph can (but doesn't has to) be used by implementation of Graph, implementations can get it with require so there is no need to have this as a member of rdf
• I now understand the rationale for having rdf.Triple, etc. - still think this SPI features should be hidden away as to have a neat rdfclass for the API users

Answer to: Comments to: What should be added:

• I don't think that require would provide a useful mean to get a parser for a particular format. For example if rdf-store-ldp is used and a new application/super-compact-rdfRDF concrete syntax comes out I would like to be able to register my super-compact-parser so that rdf-ldp-store will work with servers sending payloads in this format (without having to change any code in rdf-ldp-store).