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

Gregg Kellogg <gregg@greggkellogg.net> wrote:

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

+1

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

Good point, when I said that I was forgetting time zones.    I should be able to attend then.    

      - Sandro

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

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Received on Saturday, 1 June 2013 00:38:37 UTC