- From: Nathan <nathan@webr3.org>
- Date: Thu, 10 Mar 2011 00:01:37 +0000
- To: Thomas Steiner <tsteiner@google.com>
- CC: RDF WG <public-rdf-wg@w3.org>
Hi Thomas, Glad you replied, as I'd very much like to work out where we agree and disagree. Thomas Steiner wrote: > I see some issues if there are different flavors of RDF JSON > serializations (see different thread), but wanted to ask for > clarification first: how do you explain to someone who is happy to > have copied and pasted, say, the OpenGraph triples onto their > homepage, that a) there's something like "RDF goggles", and b) how > does the world look like if you put them on? Honest question. You could say, X web service (giving back json) happens to have a JSON-to-RDF map, and if you include Y javascript on your page, that script can put on it's RDF goggles to mash your opengraph triples together with the information from X service and augment your homepage with all these wonderful features and related infos which your readers will love. It's less about the person who's already using triples, and more about giving those who don't or can't or haven't used triples a way to let us see their data as RDF. As in, we can say to any JSON data provider: "don't you worry about the cost and complexity of doing all this semantic web stuff, we've made a simple map that bootstraps you in" and we can say to any developer, don't worry about changing your stack, just provide us a simple map and when we you'll be hooked in to the web of data. Best, Nathan > On 09.03.2011, at 23:48, Nathan <nathan@webr3.org> wrote: > >> Hi All, >> >> [In some ways this is a reword of an earlier post] >> >> RDF can be seen as having three core factors: >> - Triple/Node/Graph based Data Model >> - Shared Vocabularies >> - URIs as Identifiers >> >> and there are two principal ways of exposing "RDF" over the wire: >> - Use an RDF data format (universal data bus) >> - Use a non-RDF data model / format, and offer a way to view it as RDF (bootstrapped data transformation) >> >> >> JSON is heavily used to provide "plain old data objects" over the wire, for example: >> >> http://dev.twitter.com/doc/get/users/lookup >> >> Many developers have become accustomed to this, and almost expect this to be the norm when dealing with JSON. The ability to work with the data without any custom tooling, for example: >> >> obj = get(uri) >> print( obj.status.text ); >> >> >> At this point in the process, we have a core decision to make: >> >> 1: Is our approach going to be offer a way to bootstrap and transform these plain old data objects in to RDF? >> + will allow developers to work with data without RDF tooling, but it won't be RDF unless the developer puts their RDF goggles on. >> + will allow bootstrapping of many existing APIs and data sources, without them breaking bc. >> - not RDF on the wire >> >> 2: Or, is our approach going to be to provide a JSON serialization of RDF? >> + it's RDF. >> + builds on a lightweight open standard which is very well supported with native parsing. >> - typically requires RDF tooling to work with. >> - may not be as human readable as typical JSON data in the wild. >> >> >> I believe that making this choice early on, or determining that we need both, will serve us well moving forwards. For example if we choose one, then with the territory comes some core constraints on what we do, basically we can't change the way people use JSON and must work on providing a standardized way of transforming JSON to RDF. If we choose two, then we're conceding that people will typically require tooling to use the data and thus will need to focus on making trade-offs between bytesize, processing complexity, and the level of human readability. >> >> Personally, I'm happy to work on and use either or both, and can see use cases for both. >> >> The only concern I do have is us trying to do something in the middle and getting another RDF/XML, to me it's a no-grey area, either focus on providing a way to map plain old data objects to RDF, or focus on a lightweight RDF in JSON data interchange format. You either need RDF tooling to use it, or not (and if you do need tooling, why not the same tooling you use for turtle and rdf/xml). >> >> Ideally, I'd love to see a clear vote on this choice happen early on, so that we can focus early and produce something great. >> >> Best, >> >> Nathan >> > >
Received on Thursday, 10 March 2011 00:02:38 UTC