- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Fri, 17 Jun 2011 12:24:07 -0400
- To: public-linked-json@w3.org
On 06/03/11 20:38, Brian Peterson wrote: > I wish it were so, but I just can’t agree. I might have agreed with you > 2 years ago, but not now. If a developer hasn’t, it’s because JSON is so > simple they don’t need to. I think this is the case with most specs - people don't read the spec because they just read a tutorial and download some library that is conformant with the specification. > The spec is so simple that intro articles > tend to be longer than the spec! (http://www.json.org) Brian - that is not the JSON spec. That is the JSON website, please don't keep conflating the two. Granted, the IETF JSON specification is just 10 pages long: http://www.ietf.org/rfc/rfc4627.txt If you print out the JSON-LD specification, it's currently 19 pages in length. 5 of those pages are examples. So, the JSON-LD specification is 14 pages long, the JSON specification is 10 pages long. Is your concern specification length or complexity? > Make it explicit that there is a simple JSON-LD, an intermediary > JSON-LD, and an advanced JSON-LD for the hard cases. Are those 3 different conformance levels? What goes in each conformance level? > Allow tools and > utilities to be compliant with the various levels of standards, letting > them expand to support the hard cases when there is a need. Typically, when simple specs like JSON-LD do that - you get a number of non-interoperable implementations. You also eventually get implementations that end up dominating in the market because they implement all levels of conformance. There is a set of growing pains over time that developers have - requiring them to switch parsers as they find a need for the more advanced features. > Allow the > average developers to understand as much as they need, without > cluttering with cool features or border cases. Make it so that a > developer that knows JSON can understand what JSON-LD is doing without > any reference documents I agree with these parts. > Use 3 special keywords: @context, @iri, and @type. Are you suggesting that we get rid of @base, @profile, @vocab, @literal, the ability to specify an IRI, @language, and @datatype? I can see a good argument for getting rid of @base and @profile. We can say that we won't support @base until there are a larger number of people that require it. I think that @profile can be replaced with @context: "@profile": "http://example.org/myprofile" is pretty much the same as: "@context": "http://example.org/myprofile" We could even support multiple profile loading, like so: "@context": [ "http://example.org/myprofile1", "http://example.org/myprofile2" ] Getting rid of @literal and @language would make it impossible to specify which language a piece of data is in (which is incredibly important for internationalization). Not allowing people to specify their native language information is imperialistic. It removes one's right to express data in their own language in an inter-operable way. @vocab is how people would use something like schema.org in JSON-LD. Many people don't want their processors to hit the Web and download a profile. For those use cases, they can use @vocab or use absolute IRIs everywhere. Not being able to specify @datatype makes microsyntaxes for things like measurements an inevitability. How do you specify "7 meters" across every language on the planet in an inter-operable way without datatype? How do you do it without writing an uber-parser for measurements? Only being able to specify an IRI through a context or profile @coerce seems overly limiting. If we are going to support @datatype, or @literal and @language, we might as well support the other native Web type - the IRI. Thoughts? > Possibly limit > contexts as mappings from keywords to URIs, not as namespace prefix > definitions and CURIEs. Contexts /are/ mappings from keywords to URIs. It just so happens that you can use those keywords as a CURIE prefix. Removing CURIEs entirely from the specification is an issue for Web Payments and PaySwarm. > Possibly allow for @coerce in contexts. Possibly > do not support embedding contexts in your resource (or at least > discourage it). How would we discourage it? > Do NOT have bnodes. Do not have CURIES. JSON objects are > resources, array values are multiple values to the keyword property. If we don't have bnodes, there are a certain class of very important problems that become impossible to solve. For example: 100 people know the same person, but that person doesn't have an identifier. How do you represent that without bnodes? That problem is a fairly basic social web problem. Here's another issue - if we don't have bnodes, we would have to generate a unique, dereferenceable identifier for every digital signature every created on PaySwarm. This number could be as high as millions to billions of digital signatures a day. We would have to define an algorithm that generates these identifiers and ensure that all implementations run the algorithm correctly. We could do that, or we could just support bnodes. CURIEs are optional - JSON-LD makes it so that you don't have to use them if you don't want to use them. If you want, use a profile and terms defined in that profile. > Now an average developer can look at this kind of JSON-LD object and > pretty much see what it is doing – except for the 3 ‘@’ keywords it’s > just JSON. They probably ignore the @context (and it is easy to ignore > because it is just a link). Possibly someone tells them @iri is the IRI > for your resource. They might need someone to say “@type is like > Microdata ITEMTYPE or RDFa’s @type”. And that’s it. That's fine, I think that would be a great introduction to JSON-LD. > It becomes a selling point that the JSON-LD spec is as short as the > original JSON spec. It would be nearly impossible to make the JSON-LD spec as short as the JSON spec. JSON-LD does a great deal more than just regular JSON. Where is your waterline between implementable and non-starter? > But you leave the door open to doing much more. It > is so simple that there isn’t any reason _/not/_ to do JSON-LD if you > are doing JSON. I agree that this is what we should shoot for... how we get there is what we need to figure out. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: PaySwarm Developer Tools and Demo Released http://digitalbazaar.com/2011/05/05/payswarm-sandbox/
Received on Friday, 17 June 2011 16:24:51 UTC