JSON User Segments

From RDF Working Group Wiki
Revision as of 15:17, 23 March 2011 by Sandro (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

See original email for more details.

Key to the table:

  • Each box on the grid involves a particular kind of data provider sending information to a particular kind of data consumer
  • The providers are classified by how much they are willing to support consumers who want RDF. We assume they all want to support json.
  • The consumers are classified by whether they (1) want RDF and (2) are willing to use a library to handle their incoming data
Group A: Data consumers who will not benefit from RDF Group B: Data consumers who will benefit from RDF but are not willing to use libraries. Group C: Data consumers who will benefit from RDF and are willing to use libraries.
Level 1: json publishers, not willing to change; conversion to RDF is messy Nothing for us to do, they are fine already. We just need to avoid making things more difficult for them. Nothing for us to do, no solution is possible in this space. Needs: 3rd party mapping
Level 2: json publishers, not willing to change; conversion to RDF isn't too hard
Level 3: json publishers, willing to help mapping, but non-RDF users should not see any sign of RDF Needs: Standard Annotation and Method for Transforming json to Triples
Level 4: json publishers, willing to add little bits to help mapping to RDF
Level 5: json publishers, willing to add everything to make json into RDF.
Level 6: json publishers, willing to use a new W3C json/RDF format Needs: Standard Simple Syntax for Triples in json Okay, either 6B or 3-4-5C solution can be used.
Level 7: data publishers happy to expose RDF in whatever formats work for their users. Needs: Standard form for extracting json view of RDF data Okay, if 6B solution can be used Already Solved, just use an RDF library.


Segmentation for JSON apps - RDF data publishers

See original email.

Group A1: applications willing to do what ever it takes to get RDF-published data Group A2: applications wanting a JSON data structure Group A3: applications willing to use a library/API
Level P1: RDF publisher willing to publish according to a fixed, universal JSON presentation
Level P2: RDF publisher willing to provide a JSON friendly form to all applications
Level P3: RDF publisher willing to provide a JSON friendly form based on the application accessing the data

Potentials that Manu Sees

Group A: Data consumers willing to do custom code for each data source. They want obvious json, no libraries. Group B: Data consumers willing to use RDF to avoid custom coding per data source, no libraries/APIs. Group C: Data consumers willing to use RDF to avoid custom coding per data source, uses libraries/APIs.
Level 1: json publishers, not willing to change; conversion to RDF is messy Nothing for us to do, they are fine already. We just need to avoid making things more difficult for them. Nothing for us to do, no solution is possible in this space. Needs: 3rd party mapping
Level 2: json publishers, not willing to change; conversion to RDF isn't too hard
Level 3: json publishers, willing to help mapping, but non-RDF users should not see any sign of RDF Needs: Standard Annotation and Method for Transforming JSON to Triples Needs: Standard Annotation and Method for Transforming JSON to Triples Needs: Standard Annotation and Method for Transforming JSON to Triples
Level 4: json publishers, willing to add little bits to help mapping to RDF
Level 5: json publishers, willing to add everything to make json into RDF.
Level 6: json publishers, willing to use a new W3C json/RDF format Needs: Standard Simple Syntax for Triples in json Okay, either 6B or 3-4-5C solution can be used.
Level 7: data publishers happy to expose RDF in whatever formats work for their users. Needs: Standard form for extracting json view of RDF data Okay, if 6B solution can be used Already Solved, just use an RDF library.