Re: Requirements update

Just for kicks, here's a quick list of my personal requirements for 
JSON-LD, or something like it - to see how it weighs up against the 
current requirements:

public and private naming, public being URIs with a global/universal 
scope of the web, private being scoped within the "document" under 
consideration. Ability to use shortened names relating to fragment 
identifiers in the syntax, for example "me" in a graph with the IRI 
<http://webr3.org/nathan#> resulting in <http://webr3.org/nathan#me> as 
the proper public name for said object. This applies to property names 
too, in addition to needing an easy syntax for property IRIs, I also 
need properties that are named privately.

all data expressed in k/v JSON objects relating to property-object 
chains in RDF, optional "subject", where subject can be a public or 
private name.

first class support for: integer, decimal, boolean, string, IRI, 
date/time-stamps. (and ideally hex-binary and base64-binary, unsure 
about float). No support for NULL.

I'm easy on generic datatyping methods, as I figure this should be more 
of a requirement to specify using validation rules in ontologies, 
however I realise it can sometimes be an optimisation to know a datatype 
upfront and have no ontological knowledge of the data being encountered.

also easy on language tag specification for strings (since you often 
find mixed language text mixing between jp+en for example), however I'm 
sure many will need it.

support for ordered lists, unordered lists, linked lists which span over 
documents and dataspaces, and finally sets.

no RDF imposed constraints (allow non IRI properties, literal subjects 
etc). All JSON-LD is valid JSON, is not necessarily valid RDF - would be 
happy to map to / leverage L-Base for semantics.

easy way to match one document to one vocabulary.

well document expectation that IRIs are meant to be dereferenced.

I'll send this, then read the requirements below in a minute and see how 
they compare.

Best,

Nathan

Gregg Kellogg wrote:
> We discussed the requirements [1] on the call today. I made a couple of small changes, but I mainly wanted to get feedback from the list on the specific JSON-LD markup requirements:
> 
> 
>  1.  A JSON-LD document must be able to express a linked data graph.
>  2.  A JSON-LD document must be a valid JSON document.
>  3.  All JSON constructs must have semantic meaning in a JSON-LD document: associative arrays, arrays, numbers, strings and other literal names to express semantic information.
>  4.  A subject is defined using a designated name/value pair of a JSON object.
>  5.  There must be a way label a JSON object with an IRI.
>  6.  There may be a way to reference an un-labeled JSON object that does not have a direct child relationship.
>  7.  JSON name/value should be used to describe property-object relationships.
>  8.  A property should resolve to an absolute IRI.
>  9.  An object is represented using JSON objects, arrays, numbers, strings and literal names resolve to nodes in a linked data graph.
>  10. Un-coerced JSON strings represent literal objects.
>  11. Coerced JSON strings may represent IRIs.
>  12. There should be a way to associate a datatype IRI with a literal JSON value.
>  13. JSON booleans, numbers and other literal values must represent specific datatyped literals.  What does null map to? There may be value in specifically saying that the meaning is undefined.
>  14. A JSON array may be used to associate multiple objects with a subject through a common property.
>  15. A JSON array must not be used to imply an order to the component entities.
>  16. A JSON-LD document should be able to express and ordered list objects.
> 
> 
> Gregg
> 
> [1] http://json-ld.org/requirements/latest/
>

Received on Tuesday, 9 August 2011 19:22:17 UTC