RDFAccessProtocol

In WebDataInterfaceDesign, an obvious first steps is a triplesMatching(s, p, o) interface. But many queries are more than just what is the title of <xyz>?. For example tell me the titles of all books by an author with homepage <abc>. This can be done with a triplesMatching API, but for remote access, it's very inefficient. Besides... many RDF knowledgebases are backed by SQL engines. A number of graph-matching services (guha's rdfdb, Joseki WebAPI, cwm's SQL integration, squish) have sprung up.

Relational Databases on the Semantic Web suggests db:sqlService and db:formService to relate databases to GET-based query services. These relationships are typically set up in a schema, which makes them available to any consumer that looks up the property and class definitions.

hmm... relevant to charter discussions?

Update (aka Write)

hmm... perhaps this is a separate topic? DanConnolly wants a name for just the read part above

BeesAndAnts and DeltaView suggests we might want a protocol like:

• HTTP GET kb
  • send the kb contents (using the first matching Content-Type)
• HTTP GET kb?queryParms
  • when you only want some of the kb (too constrained. more later -- DanConnolly)
• HTTP HEAD/GET kb
  • returns a Deltas: head which is another KB containing the deltas
  • returns a Participants: header which is another KB containing information

      about how changes are managed, including a subcription list (to which you
      may be able to add yourself, ...) and maybe a change-approvers list, etc.
      (a la RDF database federation.)

• HTTP PUT kb
  • replace the contents of the KB
• HTTP POST kb
  • provide new content to be added to the KB
• HTTP POST (the Delta-Location of the KB):
  • provide a new delta for the original KB

This puts deletions on a very different footing from additions. Maybe that's appropriate. An alternative is to say that what is posted to a KB is deltas.

Deltas can contain metadata, like who, when, and why. Where does trust come in? Probably any data added via POST needs to be vetted and/or transformed according to appropriate security policies.

Use Case:

• An RDF user interface (IsaViz, SemWeaver, BrownSauce) talking to its storage facility

Prototype ideas:

• on CVS
• on an RDBMS keeping its transaction logs
• on MoinMoin using files like test.n3

Challenges:

• Inference and merged data (perhaps both are forms of the ViewUpdateProblem)

hmm... FunctionsAndOperators

---

DanBri's RDF Description Services sketch, the Annotea protocol (LinkMe), and TAP(LinkMe) all present variations on a theme: look up a chunk of information in a service and return it presented as RDF. In many ways this is a natural successor to the PICS label bureau protocol, hence related to ContentSelection4SemanticWeb concerns.

The Joseki WebAPI seems to follow this design pattern. In the query GET, they include the query language as one of the parameters. But query languages don't seem to be named with URIs. Might as well just have properties that relate KBs to query interfaces on a by-language basis, ala dbview. <KB> sql:service <KB/sqlIO>. <KB> forms:service <KB/formIO>. <KB> rdql:service <KB/rdqlIO>.