Re: Resolutions for features at risk [JSON-LD]

On 05/31/2013 02:41 PM, Markus Lanthaler wrote:
> 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

Wouldn't this cause all the values of object properties to be read as 
strings instead of IRIs?

Perhaps there's something I'm missing in how schema.org is designed.

I'd be a bit more work, but I think it'd make sense to have the object 
properties flag their values as links.

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

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

I'd suggest holding off on this until after rdf-concepts has gone to 
last call.

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

I like Gregg's idea that the conversion be done separate from RDF 
conversion.  That way the conversion can, in general, be done just in 
the consumer, where the actual platform characteristics are known and 
errors can be thrown if necessary.

One COULD do that conversion before sending out some JSON-LD on the 
wire, but we should warn that will lead altered values of certain 
numbers when going between certain pairs of platforms.

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

I suggest we leave it At Risk through CR.    We can confirm this during 
the transition-to-CR meeting.  I don't think the WG needs to do anything 
here.

         -- Sandro


>
>
> --- 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:59:53 UTC