Re: JSON-LD in examples invalid due to comments

Here's a use case. There are times when I want to publish data that refers to a graph node by its opaque URI, but I don't want to republish data that describes it. In cases like those, I might want to stick its name in an adjacent comment for casual readability.

Jeff

Sent from my iPad

On Nov 28, 2013, at 3:18 PM, "Guha" <guha@google.com<mailto:guha@google.com>> wrote:

I don't see why we wouldn't want the comments in the graph.

guha


On Thu, Nov 28, 2013 at 9:01 PM, Gregg Kellogg <gregg@greggkellogg.net<mailto:gregg@greggkellogg.net>> wrote:
On Nov 28, 2013, at 7:15 AM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com<mailto:pfpschneider@gmail.com>> wrote:
>
> I think that using properties that do not have the type in their domain is neither transparent nor workable, aside from the problems related to misspellings and new properties.  This approach might be better than using duplicate keys, but only marginally.
>
> Adding comments to JSON is a non-starter, as well, as far as I can tell.
>
> One approach that appears workable to me would be to add a comment property to Thing (although I'm not too happy about suggesting having a comment property in general).  However, why not just use "description" for this purpose?

Of course, there is rdfs:comment, but I think the point was to have a syntactic comment, not something that becomes part of the data model.

The ship has sailed on JSON (and JSON-LD); however, apublisher may generate JSON-LD with unmapped keys and use as a commenting convention, but care must be taken that it isn't accidentally mapped through use of @vocab.

> Of course, having comments that just reiterate content is a bad idea in general.  Either the comment correctly reiterates the content, in which case it is useless, or it incorrectly reiterates the content, in which case it is harmful.   It would be better to just remove such comments.  As the comments in question appear to be of one or the other of these forms, there is a clear way forward here, with no downside.
>
>
> As a general point, I would think that all the examples in schema.org<http://schema.org> should be run through several parsers set to strict validation settings to ensure that the examples are not syntactically incorrect.

Absolutely, many examples, microdata, RDFa and JSON-LD are replete with syntax errors; no excuse for this with modern tooling.

Gregg

> peter
>
>
>> On 11/28/2013 06:20 AM, Gregg Kellogg wrote:
>>> On Nov 28, 2013, at 2:48 AM, Martin Hepp <martin.hepp@unibw.de<mailto:martin.hepp@unibw.de>> wrote:
>>> Just my two cents: Would it be completely unthinkable to introduce a syntax for comments in JSON and JSON-LD?
>> It's outside the scope of JSON-LD to change the base JSON syntax, but if this were supported in JSON, JSON-LD would pick it up automatically.
>>
>> Alternatively, using an undefined key, such as @comment, would work transparently.
>>
>> <script type="application/ld+json">
>> {
>>   "@comment": "John listened to Pink with Steve at Anna's appartment on his iPod.",
>>   "@context": "http://schema.org",
>>   "@type": "ListenAction",
>>
>>>> On Nov 28, 2013, at 11:45 AM, Markus Lanthaler wrote:
>>>>
>>>> Hi,
>>>>
>>>> I've just realized that all (?) JSON-LD examples in schema.org<http://schema.org> are invalid
>>>> since they include comments. Just as JSON, JSON-LD doesn't support comments.
>>>>
>>>> Example 1 of http://schema.org/Action for instance begins as follows:
>>>>
>>>> <script type="application/ld+json">
>>>>   // John listened to Pink with Steve at Anna's appartment on his iPod.
>>>> {
>>>>   "@context": "http://schema.org",
>>>>   "@type": "ListenAction",
>>>>   ...
>>>>
>>>> The second line turns this into invalid JSON(-LD). It should thus be
>>>> rewritten to
>>>>
>>>> <script type="application/ld+json">
>>>> {
>>>>   "@context": "http://schema.org",
>>>>   "@type": "ListenAction",
>>>>   ...
>>>>
>>>>
>>>> Would it be possible to remove those comments at the beginning of all
>>>> examples? I fear that otherwise a lot of people will adapt this style which
>>>> will lead to severe interoperability problems.
>>>>
>>>>
>>>> Thanks,
>>>> Markus
>>>>
>>>>
>>>> --
>>>> Markus Lanthaler
>>>> @markuslanthaler
>>> --------------------------------------------------------
>>> martin hepp
>