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:
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>.