Sun Dec 12 18:29:16 GMT 2010
the most important of these is the JSON. The user
interactions (at present just manipulating collections
running in the browser speaks a JSON protocol with
The JSON representation for a particular subject is
built like so, starting with an empty dictionary:
1. put "id": "<subject_uri>" (URI is expressed in
angle brackets as in ntriples/turtle/n3
2. for each predicate, do we have an explictly
modelled property on the server side object?
if so make a key with that name
3. if we do not have an explicitly modelled
property and we do have a useable namespace
make a curie, e.g. dc:isPartOf
4. if we do not have a useable namespace, use the
predicate URI in angle brackets as key.
5. for the objects, do we have more than one? use
a list, else use a single value
6. if the object is a (modelled) URI, the value
is a dictionary, go recursively to step 1 for that
7. if the object is an unmodelled URI, represent
according to steps 3,4
8. if the object is a literal, encode it directly,
paying attention to datatypes that are representable
directly in JSON (e.g. integers, floats, strings)
and ignoring language tags.
This algorithm is applied in reverse for a PUT or POST
operation, the "id" key for the subject being required
in the case of a PUT or being generated by the server
in the case of a POST.
A "better" (for some values of better) protocol would
to be to use RDF with GET/PUT/POST directly which is
supported by the server software but has proven very
difficult for otherwise skilled and competent user
interface developers to wrap their heads around.
Nathan asked if we need the three possibilities of
directly modelled simple property names, curies and
explicit URIs or if we could dispense with curies.
of view is that they are all simple property names
and they never have to think about properties with
namespaces. Failing that, curies are more friendly
than full URIs but do require at least some convention
on well-known namespace prefixes at least within the
context of a single application. Full URIs as properties
are actually disorienting, they are not expressible
in the usual OO kind of notation that JS programmers
are used to, they are acceptable as values but not
really as keys.
William Waites <mailto:ww at styx.org>
http://river.styx.org/ww/ <sip:ww at styx.org>
F4B3 39BF E775 CF42 0BAB 3DF0 BE40 A6DF B06F FD45
More information about the openbiblio-dev