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

On May 31, 2013, at 2:59 PM, Sandro Hawke <sandro@w3.org> wrote:

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

I've had more discussions with Danbri, and I think we may make more progress this week at SemTech, with several people from Google, the other schema.org partners, Sandro and myself there all in person. In particular, there's a Semantic Hack day tomorrow where we may have some time to dive into this more.

At this point, I'm not too concerned about not having a context at http://schema.org/. Certainly, what you have is the absolute minimal, but we can probably do better than that.

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

+1, no brainer at this point.

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

There's no point in resolving anything while the issue is still being tossed around for RDF Concepts; ideally, the general use of BNodes as graph labels will prevail, and this becomes a non-issue.

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

I think this needs more discussion. I would be a -1 on anything that yields a non-round-tripable RDF/JSON-LD/RDF conversion. I know Sandro said he couldn't be on Tuesday's call due to SemTech, but given that it's at 7:00PST out here, perhaps he can make it after all. I think it bears discussion.

As Sandro said, from my perspective, allowing the client to perform these convesions as part of normal transformations makes sense to me, rather than over-relying on JSON native types, and certainly not when there's loss of fidelity.

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

That seems best to me.

Gregg

>        -- 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 Saturday, 1 June 2013 00:04:53 UTC