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

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
http://danbri.org/2013/SchemaD3/examples/4063550/hackathon-schema2.js
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)

Dan

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