W3C home > Mailing lists > Public > public-linked-json@w3.org > June 2013

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

From: Dan Brickley <danbri@danbri.org>
Date: Sun, 2 Jun 2013 21:51:10 -0700
Message-ID: <CAFfrAFprYsE7RyKnJMOGUrrDVCRsSB0_zR5ACWumiAWZ6OA=qQ@mail.gmail.com>
To: Sandro Hawke <sandro@w3.org>, Markus Lanthaler <markus.lanthaler@gmx.net>, Linked JSON <public-linked-json@w3.org>, W3C RDF WG <public-rdf-wg@w3.org>
On 31 May 2013 14:59, 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.
>> 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

strong +1

Having spent some time with Sandro and Gregg yesterday looking at
JSON-LD in a schema.org context, @reverse looks pretty useful.

For a specific use case, Gregg generated
from the RDFa from Schema.org, i.e. from
http://schema.org/docs/schema_org_rdfa.html ... this has the advantage
of matching the JSON idioms expected by d3js.org (leading Javascript
data viz toolkit) but also working as RDF via JSON-LD. For example
http://danbri.org/2013/SchemaD3/examples/4063550/hack4.html can be
generated from this JSON with zero lines of code. This was faciliated
by an @context mapping: "children": { "@reverse": "rdfs:subClassOf" }
which allows a JSON hierarchy beginning with the most general class
c.f.  https://github.com/mbostock/d3/wiki/Tree-Layout

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

(am agnostic / don't know enough to judge currently)

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

(am agnostic / don't know enough to judge currently)

Received on Monday, 3 June 2013 04:51:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:37 UTC