Architecture

APIs

On the one hand, we want a powerful API that is close to the RDF model. On the other hand, it should be easy for JavaScript developers to get started with RDF. Perhaps this means we need a low-level API one the one hand (comparable to the DOM in browsers) and one or more high-level APIs on the other hand (like jQuery or MooTools).

Low level

Audience: library and low-level developers, RDF experts

High level

Audience: application and service developers, JavaScript developers

interface choices

• triple/quad model
  • attribute access
    • s/p/o/g vs. subject/predicate/object(/graph)
    • graph:null vs. graph:undefined vs. graph:"" vs. no graph property
  • | function access
    • RDF Interfaces offers: equals, toString
  • "fringe" requirements.
    • validators like ShEx can use utterances of triples (a triple composed of RDF terms that have a location in a document) to provide nice feedback to users.
• graph API
  • can have attribute access to triples and function access to graphs
  • RDF Interfaces graph API:
    • add triple, addAction (???), addAll graph, every test all triples, filter restrict triples, forEach different from '''every'''?, match usual triplesMatching function, merge return concatenation, remove a triple, removeMatches matches().forEach(), some does some triple match, toArray plus JSON-LD manipulators.
    • other APIs: Jena, Sesame, Redland, ...
    • deciderata: familiarity, intuitiveness, appropriateness to javascript

module structure

Tension between modularity and ease-of-use. Propose a core module for stuff needed for parsing and matching triples, a util for stuff like graph==graph and an all meta module that includes everything. This gives folks and easy on-ramp which they can then factor out when they get motivated.