Hi Olivier I agree that the data passed around should be using human-friendly prefixes, so the serializers both in js and in java should create such json-ld. But I also think that our RDF aware application code shouldn't have to care about serialization specific issues, this should be the business of the serializer. It is great if we can - to a certain degree - interact with people who don't know about RDF, yet we should keep writing our code on the RDF level abstraction. So while other js-code might use the prefixes and ignore URIs and triples our code should ignore the prefixes and see the URIs.
Reto On Wed, Sep 28, 2011 at 6:26 PM, Olivier Grisel <[email protected]>wrote: > 2011/9/28 Reto Bachmann-Gmür <[email protected]>: > > On Wed, Sep 28, 2011 at 6:03 PM, Olivier Grisel < > [email protected]>wrote: > > > >> 2011/9/28 Reto Bachmann-Gmür <[email protected]>: > >> > > >> > As a next step I would like to integrate VIE in the enhancer interface > so > >> > that the enhancements appear while you type. VIE could pass its > content > >> as > >> > JSON-LD with ajax to the server. Is there an existing > MessageBodyReader > >> or > >> > other JSON-LD parser in use in Stanbol or elsewhere? > >> > >> Hi Reto, > >> > >> AFAIK, there is JSON-LD parser in java. Also the current serializer > >> does not take into account the latests changes of the JSON-LD spec: > >> http://json-ld.org/ > >> > >> Also the current serializer be extended to make it possible to pass a > >> list of common namespace prefix and actually use them in the > >> serialization (otherwise the generated JSON is full of annoying > >> redundant URIs which are a pain to work with from javascript for > >> instance). > >> > > This reminds me the curie-prefix service added to clerezza, which > > unfortunately isn't yet used in any serializer. However I think that > apart > > from the js-code actually doing parsing or serializing the js code > shouldn't > > see the prefixes but access the data exclusively by the URIs. > > The point of JSON-LD is to make linked data readable by regular people > (web developers) who don't understand RDF and don't want to learn > about it: they just want items with properties and values and be able > to read it and access it naturally from javascript. The good news is > that we can easily provide them with what they want while also > providing RDF namespace info for "semantic web"-enlighted advanced > users. > > For instance this is an example taken from the > http://json-ld.org/playground/ : > > { > "name": "The Empire State Building", > "description": "The Empire State Building is a 102-story landmark > in New York City.", > "image": " > http://www.civil.usherbrooke.ca/cours/gci215a/empire-state-building.jpg", > "geo": { > "latitude": "40.75", > "longitude": "73.98" > }, > "@context": { > "name": "http://schema.org/name", > "description": "http://schema.org/description", > "image": "http://schema.org/image", > "@coerce": { > "@iri": "image", > "xsd:float": ["latitude", "longitude"] > }, > "geo": "http://schema.org/geo", > "latitude": "http://schema.org/latitude", > "xsd": "http://www.w3.org/2001/XMLSchema#", > "longitude": "http://schema.org/longitude" > } > } > > People who know about the importance of RDF, Linked Data and > vocabularies with explicit namespace declaration can access it by > parsing the @context node. > > Regular web developer who don't have a clue about all of this can > still read and understand the fist part and do interesting stuff in JS > using the trivial dotted notation: "entity.name" for instance. > > This is very, very important for adoption that Stanbol outputs > human-readable JSON **by default** and JSON-LD is a clean solution to > achieve this goal. > > -- > Olivier > http://twitter.com/ogrisel - http://github.com/ogrisel >
