Re: Requirements update

On Aug 9, 2011, at 12:21 PM, Nathan wrote:

> 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.

Provided for via SHOULD language in reqs. Other language in spec.

> 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.

@base and @vocab within @context will do this.

> 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.

@subject inclusion is a SHOULD, so it allows for an unnamed node. The spec also has unnamed nodes as Advanced Concepts.

> 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.

Nothing for date/time-stamps, hex-binary or base64-binary as first class entities. These can be supported through a typed literal notation. We're also not inclined to go too far on explicit support for XSD datatypes, which would likely be necessary to identify the lexical form of these types.

> 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.

Easy, as in literal notation such as {"@literal": "A string in english", "@datatype": "en"}. However, this does not (yet) come from the requirements. We make no assertions about the form of the @datatype value, but it could have some implications if converting to RDF, for example.

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

There is a requirement for ordered and unordered lists. The spec supports ordered lists as an Experimental Concept. The RDF serialization of this would use rdf:first/rdf:rest linked list generation, but this is not required if staying within JSON.

As with RDF, unordered lists could span documents; can't see how to do this with ordered lists; thoughts?

> 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.

Language for all of these is SHOULD for IRIs.

> easy way to match one document to one vocabulary.

See @vocab, above.

> well document expectation that IRIs are meant to be dereferenced.

Covered.

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

Gregg

> 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 Wednesday, 10 August 2011 00:50:46 UTC