JSON representation of OAC?
Bruce D'Arcus
wondering:
Any talk of having a lightweight JSON representation of the OAC model
(and maybe related OSS client code) that could be easily converted
to/from the RDF?
Maybe something like:
{
"type": "Annotation",
"target": [
{
"type": "OffsetRangeConstraint",
"offset": 4,
"range": 3
}
],
"body": {
"creator": {
"email": "d...@foo.org"
},
"content": "Hello World",
"reply": {
"creator": {
"email": "sm...@bar.org"
},
"content": "Goodbye"
}
}
}
Or is that just out of scope for OAC?
Bruce
Jodi Schneider
Robert Sanderson
At the moment, I don't think that we want to define a competing JSON
representation, even if there isn't (as yet) a recognized standard.
I've had a lot of success recently with Jeni Tennison's RdfQuery
module for JQuery in parsing and generating RDF/XML. It also supports
RDFA and current JSON serializations.
http://code.google.com/p/rdfquery/
I'm happy to share this code if people are interested.
Hope that helps,
Rob
Bruce D'Arcus
> Well, RDF JSON is coming. It's in the charter of the current RDF working
> group:
> http://www.w3.org/2010/09/rdf-wg-charter.html
Right; forgot about that.
Still, there are some challenges in producing something close to
idiomatic JSON that non-semweb devs would not be repulsed by.
In either case, whether OAC defines a JSON syntax itself, or chooses
an off-the-shelf RDF-JSON alternative, I would think it would likely
encourage support for OAC.
The specific use case I'm thinking of here is actually Sakai OAE,
which is mostly working with JSON data natively, a case that is
increasingly common with noSQL solutions like Riak, MongoDB, CouchDB,
etc.
Bruce
Bruce D'Arcus
> Jodi beat me to it :)
>
> At the moment, I don't think that we want to define a competing JSON
> representation, even if there isn't (as yet) a recognized standard.
Agreed.
> I've had a lot of success recently with Jeni Tennison's RdfQuery
> module for JQuery in parsing and generating RDF/XML. It also supports
> RDFA and current JSON serializations.
> http://code.google.com/p/rdfquery/
>
> I'm happy to share this code if people are interested.
I think, in general, the more code openly available, the better.
Still, I'm skeptical an RDF solution would work for this case.
Bruce
Robert Sanderson
idea to define a competing _transfer_ syntax, a discussion about how
JSON based implementations might then internally map the RDF into JSON
is possibly in scope for some shareable code.
The thought being that although across the wire, it might be RDF/XML,
RDF/JSON, N3 or whatever, so long as the application can transform it
into understandable json, there could be value in sharing a structure
for that json. This then doesn't compete with existing transfer
syntaxes and implementers are free to completely ignore it, but at
least gives a starting point for people who don't want to totally roll
their own.
The structure in a pseudo JSON/BNF might look like:
basic = {
id : "uri" // The URI of the resource, or null
for a blank node
types : [name, ...] // Multiple rdf:type
creator : agent // dc:creator
title : "" // dc:title
value : "" // The bitstream for the resource
}
name = "prefix:RdfClassName"
agent = {
id : "uri"
name : ""
email : ""
web : ""
}
anno = {
+basic // Include basic properties
body : bt // Only one body in an oac:Anno
targets : [bt, ...] // Multiple targets
}
bt = {
+basic
partOf : basic // Either dcterms:isPartOf (for fragment URIs)
or oac:constrains
constraint : cnst // Not null if ConstrainedTarget with a Constraint
cnst = {
+basic
+ constraint specific properties, eg offset, range, prefix, suffix,
exact, x, y, r, ...
}
And an example:
{ id : "http://example.org/annotations/1",
types : ['oac:Annotation'],
creator : { id : null, name : 'Rob Sanderson', email :
'azar...@gmail.com' },
title : 'My Annotation',
body : {
id : null,
types : ['cnt:ContentAsText'],
value : "This is my annotation about a circle segment of a logo"
}
targets: [ {
id : "http://example.org/constrainedTarget/1",
partOf : "http:example.com/logo.jpg",
constraint : {
id : null,
types : [ 'oac:SvgConstraint'],
value : "<svg:circle .... />"
}
} ]
}
Rob Sanderson
Dear all,
An initial release of the OAC javascript code that parses RDF into a
more developer friendly set of objects:
http://code.google.com/p/oac-js/
Any feedback is very much welcomed.
Rob
Bruce D'Arcus
>
> Dear all,
>
> An initial release of the OAC javascript code that parses RDF into a
> more developer friendly set of objects:
>
> http://code.google.com/p/oac-js/
Cool; thanks!
> Any feedback is very much welcomed.
The only initial comment (will take a look at details later) is just
that it'd be nice if you could host new code on github.
Bruce
Bruce D'Arcus
>
> An initial release of the OAC javascript code that parses RDF into a
> more developer friendly set of objects:
>
> http://code.google.com/p/oac-js/
>
> Any feedback is very much welcomed.
And on the code, if I checkout the code (using git-svn) and open
test.html, it fails to work because of path issues on the included
files (assumes a "js" subdir that isn't there), and then this error on
line 21:
Uncaught ReferenceError: fetch_annotations is not defined
Bruce
Robert Sanderson
Opening the test.html via a file open, rather than from the web, is
also unlikely to work due to the XMLHttpRequest needed to pull the
data.
RDFQuery also supports extracting RDFA from the local page, if there's
a good (and easily distributed) RDFA example someone wants to submit?
Rob
Bruce D'Arcus
> Yes, it's setup to live in a /js directory.
So shouldn't the files be in a js directory in the repo?
Maybe this is just a consequence of how SVN and CVS deal with branching?
> Opening the test.html via a file open, rather than from the web, is
> also unlikely to work due to the XMLHttpRequest needed to pull the
> data.
Yeah, I ran across that after I adjusted the path.
Bruce