Resolutions for features at risk

Hi all,

I'm now back home and am still catching up with all that happened the last
three weeks.

Looks as Google already fixed their documentation and uses "@context":
"http://schema.org" now which is awesome. So the only missing is the context
at http://schema.org. I think we should suggest the simplest possible thing
at this point in time, i.e., suggest them to upload the following context
document:

{
  "@context": {
    "@vocab": "http://schema.org/"
  }
}

I've updated the spec to close RDF-ISSUE-128 in
https://github.com/json-ld/json-ld.org/commit/e6a7c851db88eb89a59d0540bf7c10
bf31776f6c


The other thing I saw we need to do is to get formal resolutions for our
features at risk. Here are some proposals I would like to discuss before the
next RDF WG telecon next week where we'll get some time to resolve them.

* Feature at Risk 2: Reverse properties
We have 6 implementations supporting reverse properties, thus

PROPOSAL: Support reverse properties in JSON-LD 1.0.


* Feature at Risk 3: Allow blank nodes to be used as graph name or property
We discussed this several times and always came to the same conclusion. I
think we also had a resolution about that from the RDF WG group but wasn't
able to find it.
In the meantime the RDF WG decided to allow bnodes as graph names as well,
but the last word may not be spoken yet on that decision. Nevertheless:

PROPOSAL: Allow blank nodes to be used as graph names or properties in
JSON-LD 1.0.


* Feature at Risk 7: Conversion to/from JSON Native Types 
Currently we convert xsd:integer, xsd:double, and xsd:boolean to native
types and vice-versa. It may be more practical to convert all numeric types
to JSON native types and all JSON numbers to xsd:doubles. The only exception
that I think would make sense is xsd:decimal as in practice that is only
used if precision matters, i.e., no rounding should occur.
It is worth nothing that JSON-LD the data format does not suffer from
rounding errors or range limits. The problem arises when such values are
parsed by off-the-shelf JSON parsers and used in applications.

Sandro suggested to leave this feature at risk throughout CR in the last RDF
WG telecon. In any case, here are some proposals for discussion:

PROPOSAL a: Keep conversion to/from native types as-is
PROPOSAL b: Convert all of XSD's numeric types to native numbers and
xsd:booleans to true/false. Convert native numbers back to xsd:double
PROPOSAL c: Same as proposal b with the exception of not converting
xsd:decimal
PROPOSAL d: Keep conversion to/from native-types as-is but limit it to
numbers in the 32bit/64bit range


* Feature at Risk 8: Properly referencing the DOM Futures spec
Not sure what to do with this one. We probably don't need a resolution, see
Sandro's mail:
  http://lists.w3.org/Archives/Public/public-rdf-wg/2013May/0260.html



--- Features at risk we resolved already ---

Not sure if we need resolutions for this as the RDF WG agreed to publish the
LC2 spec which already includes these changes. Nevertheless, for the sake of
completeness, there was

* Feature at Risk 1: @base keyword 

Resolution: Relative IRIs are allowed us values of @base. The empty string
is interpreted as a relative IRI. Setting @base to null to specify that
there is no base IRI. 


* Feature at Risk 4: Converting list of lists to JSON-LD 

Resolution: The algorithm was updated to convert lists of lists to expanded
form, i.e., list nodes linked together by rdf:rest properties. The @list
keyword does not support list of lists. 


* Feature at Risk 5: Use of method overloading to make the options parameter
optional 

Resolution: The API has been updated to use Futures instead of callbacks
which means that method overloading is not needed anymore as the callback
parameter was eliminated. 


* Feature at Risk 6: Default value of base member in JsonLdOptions 

Resolution: The base member of JsonLdOptions has no default value. It is
only taken into consideration if it was set explicitly.

Received on Friday, 31 May 2013 21:42:13 UTC