Warning:
This wiki has been archived and is now read-only.
JSON User Segments
From RDF Working Group Wiki
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. |