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

On Saturday, June 01, 2013 2:04 AM, Gregg Kellogg wrote:
> 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.

Great! Let me know if I can help somehow.


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

JSON-LD could still be a super-set of RDF. Even if bnodes would be allowed
for graph names, we would still have to decide what to do with predicates.


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

We have that already, useNativeTypes = false


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

Definitely


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

It certainly makes sense to allow a client to perform these conversions but
you can't prevent that people will create JSON-LD with native types in it
which are outside the 32/64 bit range.

Could you please describe how you would see this work. E.g., how would the
following JSON-LD snippets be expanded/compacted/converted to RDF:

  "prop1": { "@value": 5 }
  "prop2": { "@value": 5, "@type": "xsd:double" }
  "prop3": { "@value": "5.0", "@type": "xsd:double" }
  "prop4": { "@value": "5.0E0", "@type": "xsd:double" }
  "prop5": { "@value": "99999...1000s.of.9s", "@type": "xsd:integer" }

and how the corresponding RDF literals would be transformed to JSON-LD:

  <> <prop3> "5"^^"xsd:double" .
  <> <prop3> "5.0"^^"xsd:double" .
  <> <prop4> "5.0E0"^^"xsd:double" .
  <> <prop5> "99999...1000s.of.9s"^^"xsd:integer" .

with the flag(s) set to true/false.


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler

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