json-ld / json-ld.org Goto Github PK

In the spec, @subject is used to denote the subject of an item, and @iri is used to denote a value which is an IRI. However, from chaining, the distinction seems to go away. For example, consider the following two graphs:

{
  "@subject": "http://greggkellogg.net/foaf#me",
  "foaf:homepage":
  {
    "@iri": "http://greggkellogg.net/"
  }
}

and

{
  "@subject": "http://greggkellogg.net/foaf#me",
  "foaf:homepage":
  {
      "@subject": "http://greggkellogg.net/"
  }
}

From step 2.6.1 in the spec, the first use of "@subject" ("@" in that version) generates a triple in the same way that step 2.2, for "@iri", does.

We could simplify the spec by either removing "@iri", or replacing "@subject" with "@iri". Of course, using the aliasing mechanism we've discussed, the other could continue to exist as semantic sugar in the default context.

So, @subject works the same as @iri when given in an object of a property, so @iri could be considered redundant
(albeit more understandable at least for @Coerce). The question would be if @iri is sugar for objects with only that key (an no other properties), or if it works just like @subject.

Ivan Herman: So what is the relationship of the semantic web and linked data? Section 2.4 says "The semantic web, just like the document-based web, uses IRIs for unambiguous identification." which then comes a little bit out of the blue…

Gregg Kellogg: Good point, we should be consistent in our terminology. I'd suggest we try to remove explicit use of "semantic web", except in some section that might describe the relationship between linked data and the semantic web

Markus Lanthaler: I've tried to get an understanding of the difference of the SemWeb and Linked Data quite some time ago (http://bit.ly/gYr8iB) and it wasn't that clear. So I would just propose to drop "Semantic" Web altogether.

Kingsley Idehen: +1. We have a project name and vision combo [1], a syntax for expressing semantics via directed graphs that's associated with a number serialization formats [2], and the product of a specific kind of directed graph [3] all conflated for reasons I'll never understand, especially as the incoherence resulting from these actions remains the biggest source of inertia afflicting all the aforementioned.

Items referenced in the paragraph above:

1. The Semantic Web Project
2. RDF
3. Linked Data

There should be some space at the beginning of lines in the edit and render areas,
so that the text doesn't run into the left border.

The edit area should use monospace font.

The edit area lengthens manually; the render area lengthens automagically.
It would be nice to add a control to let the user shorten the render area,
to optimize use of limited screen real estate.

In JSON arrays are defined as being ordered lists, the underlying data model of JSON-LD is a directed graph which is inherently unordered. So there is a conflict. Either we bias the approach towards JSON and convert arrays to ordered lists or we design JSON-LD so that it treats arrays as unordered sets.

Treating arrays as ordered lists by default will probably result in "messy" RDF and some argue the developers most of the time don't care about the order anyway.

There are basically three possible solutions we came up with on the telecon:

• leave everything as it is (arrays are considered as unordered sets)
• consider arrays as ordered lists, add @set keyword
• introduce a mechanisms to define in the context how to treat arrays by default

Proposal by Niklas Lindström:

Hi all!

The majority of scenarios where I use RDF contain lots of language-tagged literals. Although there is support for this using the "@language + "@literal" object construct, I find that this is often cumbersome to use in practice. Since I believe that language-literals are very common in general, I'd like to suggest some options.

1. Add JSON-LD support for declaring a document-wide language directive (within the context or at the top level, i.e. where "@context" and the optional "@base" appear). This is for scenarios where there is one dominant language for a given resource.

This would enable us to use @language like this:

 {
    "@context": ...,
    "@language": "en",
    "@subject": "http://example.org/",
    "title": "The Example"
  }

yielding:

  <http://example.org/> :title "The Example"@en .

Multiple values would work as well, so:

  {
    ...,
    "keyword": "Example", "Draft"
  }

would yield:

  <http://example.org/> :keyword "The Example"@en, "Draft"@en .

To make this play well with any plain literals (i.e. xsd:string literals in RDF 1.1), there are two alternatives:

A) If "@language" is given at the top level, every plain string value in the JSON would become language-tagged unless it's coerced (i.e. the property used for a string is defined in a "@Coerce" directive). Plain literals in the RDF 1.0 sense could be coerced using an empty key (or perhaps "@plain") in coerce if necessary.

Of course any literal given in "expanded form" would, just like in RDFa, not be parsed using the top level language. I.e. it would naturally not have any effect on literals with an explicit "@datatype" (or empty "@language").

B) If the majority of values in a document are expected to be non-datatyped (and non-coerced) plain literals, it would be more reasonable to provide a special coercion token, say "@langliteral" (or perhaps "@Localized"), which cause values for terms declared with this coercion to be tagged with the top-level language. In the example above, that'd mean adding:

  "@coerce": {
    "@langliteral" ["title", "keyword"]
  }

to the context.

2. There could also be a mechanism to make data where there are literals in several languages easier to use. We could define a special coercion called "@langmap", which expects values to be objects with the languages as keys. Thus this:

  {
    "@context: {
      ...,
      "@coerce: {
        "@langmap": [title]
      },
    },
    "@subject": "http://example.org/",
    "title": {"en": "The Example", "sv": "Exemplet"}
  }

would yield:

  <http://example.org/> :title "The Example"@en, "Exemplet"@sv .

This mechanism would of course also work when there is only one language for the value of a property.

Multiple values per language would look like:

  {
    ...,
    "keyword": {"en": ["Example", "Draft"], "sv": ["Exemplet", "Utkast"]}
  }

yielding:

  <http://example.org/> :keyword "The Example"@en, "Draft"@en, "Exemplet"@sv, "Utkast"@sv .

(Of course I think that the current expanded form is necessary at times as well. But the suggestions I present here are to facilitate a compact form, similar to the existing "@Coerce" feature; both to be used for simplifying data into a more JSON-"native" form. I have come across needs for both of these forms when exposing data in web services aimed for non-RDF-savvy developers (and e.g. when creating JSON from RDF to index in ElasticSearch).)

If I had to pick one, I'd say no. 2 is more versatile. But I've found no. 1 very desirable to get the simplest kind of JSON out (in web services).

In any case, this issue is important for me.

Given the resolution of #34, it was noticed that @context elements could be specified along with term/prefix definitions. For example:

"@context": {
  "title": "http://purl.org/dc/terms/title",
  "description": "http://purl.org/dc/terms/description",
  "identifier": {"http://purl.org/dc/terms/identifier": "xsd:string"},
  "publisher": {"http://purl.org/dc/terms/publisher": "@iri"},
  "created": {"http://purl.org/dc/terms/created": "xsd:dateTime"},
  "authorList": {"http://purl.org/ontology/bibo/authorList": ["@list", "@iri"]}
}

Alternatively, the combination of @list with @iri could be specified as an object:

  "authorList": {"http://purl.org/ontology/bibo/authorList": { "@list": "@iri" }}

Message archive includes the following:
http://lists.w3.org/Archives/Public/public-linked-json/2011Oct/0093.html
http://lists.w3.org/Archives/Public/public-linked-json/2011Oct/0094.html
http://lists.w3.org/Archives/Public/public-linked-json/2011Oct/0095.html
http://lists.w3.org/Archives/Public/public-linked-json/2011Oct/0100.html
http://lists.w3.org/Archives/Public/public-linked-json/2011Nov/0000.html
http://lists.w3.org/Archives/Public/public-linked-json/2011Nov/0003.html
http://lists.w3.org/Archives/Public/public-linked-json/2011Nov/0004.html
http://lists.w3.org/Archives/Public/public-linked-json/2011Nov/0005.html
http://lists.w3.org/Archives/Public/public-linked-json/2011Nov/0010.html
http://lists.w3.org/Archives/Public/public-linked-json/2011Nov/0012.html
http://lists.w3.org/Archives/Public/public-linked-json/2011Nov/0014.html

Altough we've removed @base, the issue remains where relative IRIs (who seem to be still supported) and terms may clash. For instance, consider this data (assuming it is located at http://example.org/):

{
  "@context": {"homepage": "http://xmlns.com/foaf/0.1/homepage"},
  "@id": "homepage#me",
  "homepage": {"@id": "homepage"}
}

Currently, the triple for this data would become:

<http://example.org/homepage#me>
    <http://xmlns.com/foaf/0.1/homepage> <http://xmlns.com/foaf/0.1/homepage> .

Not the intended:

<http://example.org/homepage#me>
    <http://xmlns.com/foaf/0.1/homepage> <http://example.org/homepage> .

This is because the @id given for homepage would be found among the terms and not be resolved against "http://example.org/".

There are various ways of resolving this:

1. Only allow full IRIs. That will probably be problematic since there are many good use cases for them, e.g. for referencing contexts, and if nothing else it is most certainly common practise for linking on the web.
2. Not allow relative IRIs that might be confused with terms, e.g. by requiring non-full IRI paths to start with either "/" (i.e. be absolute) or "./" (which is already a requirement in the URI spec if the first segment contains a colon, to disambiguate from a protocol). This could work but perhaps suffers in part of the problems of 1 (since it isn't uncommon for relative links to be given as only the leaf segment of a path).
3. Don't allow terms or CURIEs as values in @id (including for coerced values). That's problematic since there are many needs for these, both in contexts and in certain instance data cases for referencing e.g. classes and properties (and as @type is basically defined as {"@id": "rdf:type", "@type": "@id"}). We could have two different keywords, one for taking TERMorCURIEorAbsIRI values (mainly used in coercion, possibly named @term), and one for only IRIs or perhaps CURIEorIRI. (See RDFa 1.1 for the definitions of these.)

Reported by Thomas Steiner:

On http://json-ld.org/spec/latest/ (as published on 8/23) section 4.1 seems to start very abruptly.

The @vocab feature is not properly introduced, it feels like one sentence got missing during some copy and paste operation or so.
Also, the listing under 4.1 does not make use of @vocab at all. Maybe this is on purpose, most probably it is not...

Gregg Kellogg wrote:

• Straight-forward representation of data in JSON using forms based on existing practice,
• Ability to represent data as triples (subject-predicate-object or entity-attribute-value),
• Ability to supplement with additional semantic information (e.g., @context for defining terms, prefixes and datatypes),
• Compatible with RDF data representations,
• Use of simple terms as attribute names,
• No requirement to provide datatyping information of values explicitly within representation (but ability to do so),
• Ability to represent relationship between an entity and one or more other entities, either by referencing document as a URI, to a representation included within the JSON-LD document, or as a sub-element of another entity

In one of Gregg's last updates to the spec the normalization was changed to return a string containing an RDF serialization "which will most likely be something in an N-Triples like format" instead of a JSON-LD document. This makes it impossible for a JSON-LD parser to interpret a normalized JSON-LD document. Effectively the result of normalization is not even valid JSON-LD anymore.

If we keep this, it would not only render the media type option form=normalized useless but also prevent storing normalized documents and retrieving them at a later point since JSON-LD parsers would have to include a N-Triples parser and a N-Triples to JSON-LD conversion as well.

IMHO there are basically two options to solve this issue:

• return a JSON-LD representation in the form of a string
• or completely remove normalization and all the references to it from JSON-LD (syntax and API)

Is it possible to have multiple contexts in a JSON-LD document? I think we discussed this already but we haven't come to a conclusion yet.

So, what I mean is something like

{
  "@context": { ... },
  "name": "Markus",
  ... some more data ...
  "details": {
    "@context": { ... },
    "name": "My Company"
  }
}

where the second context overwrites the first one. From reading the spec (active context) I would conclude that it is possible but I'm not sure. We should be a bit clearer in this regard.

There is a controversial discussion on the mailing list whether CURIEs should be removed from the spec or not. One argument for doing so is that it is unknown if the current practice of vocabulary mixing in Turtle, RDFa, etc. might change based on precedents like schema.org and that it is easier to add a feature to a spec than to remove one.

Some arguments by Danny Ayers:

These are the arguments in favour of CURIES:

• smaller payloads - a definite plus, but as we're only talking at maximum a couple of thousand of bytes, not a game-changer
• reduced hassle when typing - amount of benefit is debatable, it assumes a lot of JSON-LD docs will be hand written, not necessarily the case
• easier serialization - I could be wrong, but I suspect being able to push out terms in the same namespace is going to be easier with than having to do it term-by-term

and against:

• increased cognitive load - one of the anti-namespace brigade's arguments is that people are more likely to make mistakes. I reckon they overstate the case, but that still leaves this as a minor negative
• complexity of parsing - the strongest argument against, IMHO. I'm pretty sure your typical developer will have less trouble extracting discrete name-value pairs than extracting discrete name-value pairs AND extracting name-value pairs by resolving prefixes
• the perception that namespaces are harmful - impossible to quantify, but then again worth bearing in mind

The last example in section 7.2 [1] contains an error

{
"@context": {
...
"@context": {
^^^^^^^^
"@list": ["foaf:nick"]
}
},
...
"@subject": "http://example.org/people#joebob",
"foaf:nick": ["joe", "bob", "jaybee"],
...
}

the second '@context' should be '@Coerce'.

Reported by pierre-antoine.champin (a) liris.cnrs DOT fr

Using the words subject, property (note we aren't using predicate) and object might confuse some people. The subject has to be a JSON object, the (LD graph) object doesn't. We could mitigate that by talking about nodes which have properties whose values might be other nodes or a literal value.

The current test-suite is pretty RDF-centric. I've made changes to describe tests as being of type jld:SPARQLTest for those that exist. We can probably use this for JSON-JSON tests just as easily.

If normalization is required, and we can count on the BNode serialization algorithm, then we could probably remove SPARQL and just do straight comparison to N-Triples.

Gavin Carothers and Ivan Herman have asked whether the normalization algorithm should be moved to an external specification. Since the normalization algorithm is meant to be generic and applicable to any RDF graph, moving the algorithm into a separate document makes sense.

However, the group should be very sensitive to the issue that depending on an external document requires that the dependency be a W3C REC at or around the same time that the JSON-LD spec goes to REC. That is, we cannot have an external dependency that is not a W3C Recommendation as well.

In today's telco (http://json-ld.org/minutes/2011-11-29/) we discussed using using CURIEs in the key position within an @context object to describe @datatype coercion rules. This needs comes about because of the desire to fully utilize JSON-LD compact form in a generic RDF transformation without requiring a processor to automatically create term definitions. For example, consider the following expressed in Turtle:

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://greggkellogg.net/foaf#me>a foaf:Person;
  foaf:name "Gregg Kellogg";
  foaf:homepage <http://greggkellogg.net/>;
  foaf:birthday "1957-02-27"^^xsd:date .

I would like to be able to take advantage of the foaf:birthday range datatype in a JSON-LD representation; if the processor must automatically create a prefix (say, "foaf_birthday") there is some risk with colliding with a definition in another context. The rule would be that if the key is an NCName, it is taken as a term definition, otherwise normal IRI expansion rules apply. Allowing a CURIE to be used in the key position, could allow something such as the following:

{
  "@context": {
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "foaf": "http://xmlns.com/foaf/0.1/",
    "foaf:birthday": {"@coerce": "xsd:date"}
  },
  "@subject": "http://greggkellogg.net/foaf#me",
  "@type": "foaf:Person",
  "foaf:name": "Gregg Kellogg",
  "foaf:birthday": "1957-02-27",
  "foaf:homepage": "http://greggkellogg.net/"
}

This was also briefly discussed on the mailing list:

http://lists.w3.org/Archives/Public/public-linked-json/2011Nov/0041.html

See:
http://lists.w3.org/Archives/Public/public-linked-json/2011Aug/0106.html

The escaping of forward slashes behavior must be specified in the normalization section so implementations are consistent. I recommend normalizing such that all forward slashes are NOT escaped.

Should we add support for null in JSON-LD? There is a difference between a triple where the object is null to a non-existent triple. I think we should support that, but there are a number of issues:

• we use null to specify something that has been 'framed' as non-existing.
• a frame specifying output elements that don't exist is serialized using 'null'. e.g., foaf:homepage: "null"
• helps programmers to not put in checks to ensure that a key exists, only need to check for 'null' value.
• kind of strange in RDF too - a property that doesn't exist as null.
• if JSON-LD treats null as rdf:nil, we may have a round-tripping issue.

Manu Sporny: application specific, empty set can be correct, others would say that database NULL is correct, others would use null in yet another different way.

Alternative would be to define something like jsonld:null or json:null to represent it or a new keyword @null (but most people, including myself, are reluctant to add a keyword for that).

Gregg Kellogg suggests "[]" as no value - RDF does something like that.

Ivan Herman: It is the first time I see the term "Web Vocabulary" (later in 2.4). Why not simply "Vocabulary"?

In the current spec we have @base and @vocab to change the base IRI for objects and properties (but nothing for subjects). I think that's unnecessarily complicated and inconsistent.

I would thus propose to merge @base and @vocab to @base and make it work as it currently does in HTML and Turtle, i.e., @base would overwrite the base IRI for all relative IRIs in the document.

How is the base URL for properties and values determined in JSON-LD Basic?

The base URL for properties is determined in this order:

1. @vocab if it exists
2. the @context URL if one exists
3. the document URL if it exists
4. the JSON-LD namespace: http://purl.org/json-ld/terms#

The base URL for relative IRIs in values is determined in this order:

1. @base if it exists
2. the document URL if it exists
3. the JSON-LD namespace: http://purl.org/json-ld/items#

The document URL would have to be provided by the application utilizing the JSON-LD processor.

Following the best practice in the spec, @context should be at the top of the JSON-LD output in the playground. I've already changed all the examples, i.e., the inputs in commit b9a46cd. The processor still needs to be changed.

I assumed Dave programmed the playground, that's why I assigned this issue to him.

This issue is about making it easier for frames to specify that certain predicates should always be represented as JSON arrays (sets) wherever they occur. One approach is to allow explicit @structure directives to augment a frame's context, such as:

  "@context": {
      "vcard:tel": {
          "@iri": "http://www.w3.org/2006/vcard/ns#tel", 
           @structure": "@set"
       }
  }

Why is this important? Let's say we're working with data where a certain predicate is allowed to take mutiple objects. For instance, with the vCard RDF ontology, the v:tel predicate can point to multiple telephone number objects:

  {
    "@context": {
      "foaf": "http://xmlns.com/foaf/0.1/",
      "sp": "http://smartplatforms.org/terms#",
      "vcard": "http://www.w3.org/2006/vcard/ns#"
    },
    "@subject": "http://localhost:7000/records/00001/demographics",
    "@type": "sp:Demographics",
    "foaf:gender": "male",

    "vcard:tel": [{
      "@type": [
        "vcard:Pref",
        "vcard:Tel",
        "vcard:Cell"
      ],
      "rdf:value": "800-888-8888"
    }, {
      "@type": [
        "vcard:Tel",
        "vcard:Home"
      ],
      "rdf:value": "800-777-7777"
    }]
}

What happens when there's only one telpehone number? It depends on how the data are framed. If a frame doesn't force consistency, we have to make up for it by adding complexity to app logic:

if (patientRecord["v:tel"].constructor == Array) {
  processPhoneNumbers( patientRecord["v:tel"] );
} else {
  processPhoneNumbers( [patientRecord["v:tel"]] );
}

Yuck! So we'd better get the frame right, with something like:

[{   
  "@context": {
      "foaf": "http://xmlns.com/foaf/0.1/",
      "sp": "http://smartplatforms.org/terms#",
      "vcard": "http://www.w3.org/2006/vcard/ns#"
    },

  "@type": "sp:Demographics", 
  "vcard:tel": []
}]

So far, so good. But what if vcard:tel is used in more than one position in the hierarchy? The frame has to explicitly reflect this everywhere the predicate might appear, e.g.:

[{   
  "@context": {
      "foaf": "http://xmlns.com/foaf/0.1/",
      "sp": "http://smartplatforms.org/terms#",
      "vcard": "http://www.w3.org/2006/vcard/ns#"
    },

  "@type": "sp:Demographics", 
  "vcard:tel": [],
  "sp:emergencyContact": {
         "vcard:tel": []
  },
  "sp:insuranceProvider": {
         "vcard:tel": []
  },
  "sp:primaryCareDoctor": {
         "vcard:tel": []
  },
  "sp:caseManager": {
         "vcard:tel": []
  }
}]

This gets verbose! And all I really want to say is "anytime vcard:tel appears, the object should be a JSON array."

One proposal for this was an additional field @structure directive in the context of the frame, allowing the body of the frame to stay shallow. My frame could then be as simple as:

[{   
  "@context": {
      "foaf": "http://xmlns.com/foaf/0.1/",
      "sp": "http://smartplatforms.org/terms#",
      "vcard": "http://www.w3.org/2006/vcard/ns#",
      "vcard:tel": {"@structure": "@set"}
    },

  "@type": "sp:Demographics"
}]

From Kingsley Idehen:

1. Syntactic incompatibility != conceptual incompatibility
2. Microdata, Microformats, RDFa all provide syntax for embedding graphs within HTML documents
3. Linked Data is about using de-referencable URIs in object (resource) description (respresentation) oriented graphs where each URI resolves to a representation of its referent i.e., graph based structured data representation via hyperlinks.

Currently we do not support lists of lists since Gregg got into some problems in trying to make them work algorithmically and didn't have a real use case.

We should discuss whether we would like to support that or not and what happens if someone uses that feature nevertheless.

There are some issues with the form=framed API. How should it be done? The input to the framing document requires a frame document and a data document which both could be a fairly large JSON objects

If a web service needs to frame, what to send in request header? Send Accept: application/ld+json;form=framed with post data?
Otherwise, URI encode large JSON data in header?
Or, provide frame out-of-band, with URI of frame document?

There are some issues with all approaches:

• Passing a frame IRI out-of-band could lead to denial of service attacks to a server because it's cheap to force a server to download huge amounts of data
• not everyone can provide frame as URL
• if both documents are POSTed you can't cache the response

So the question is if we really need to support this?

Should framing be done locally?
Should it be removed from the main spec and moved to the test spec/document?

This was raised in ISSUE #30:

How do you differentiate between a valid JSON-LD frame and a valid JSON-LD document?

Originally raised on the mailing list:

@literal is used to set the value of a property when it is typed or it's language is specified. The name @literal is based on RDF. Something like @value might be easier for JSON developers to understand.

Considering that we have merged @type and @datatype (#31) I think this would make JSON-LD even simpler:

{
   "@value": "2010-05-29T14:17:39+02:00",
   "@type": "xsd:dateTime"
}

might be easier to remember and easier to understand for average developers than

{
   "@literal": "2010-05-29T14:17:39+02:00",
   "@type": "xsd:dateTime"
}

I would like to discuss the type coercion feature which I find a bit confusing.

The reason is that it works the other way round as it is normally expected by developers/programmers. An exemplary type coercion definition looks as follows:

"@coerce":
{
  "xsd:integer": "age",
  "@iri": "homepage"
}

Which says that age is an integer and homepage is an IRI. I expect that an average developer would try to specify it exactly the other way round:

"@coerce":
{
  "age": "xsd:integer",
  "homepage": "@iri"
}

What was the rationale of doing it the other way round? Isn't it even in the processing algorithms more handy if it is stored in the second form?

The current spec says nothing about how data in context documents is treated. Will it be discarded? Will it be included?

This applies only if we also add @context to context documents (#30) - _which has been decided_

In 5.11.4 Shallow Comparison Algorithm step 3) Compare the property values against one another, the order in which each property is examined is not specified. I presume it is in lexicographical order.

The world "alpha/beta property" may add some confusion, perhaps it's intended to be the union of the values of all properties in the node.

We do not define if JSON-LD is case-sensitive or not. All they keywords are currently in lowercase but is that a requirement?
I would say no.

IANA Considerations (and possibly elsewhere), "form" and "format" are used inconsistently and somewhat interchangeably. I think this needs careful cleanup. Related to this -- I think there should be full syntax (possibly EBNF, possibly Unix "commandline usage"-style) and sample string(s) shown here, including the (all?) optional parameter(s),

Differences between "form" and "format" are inconsistent because we haven't decided exactly what they're going to be yet (still editing that section)... but it'll probably be "form" ... with values being "compacted", "expanded", "framed", "normalized"
[Ted Thibodeau Jr.]

As far as fully syntax - we could do EBNF/etc. Standard practice in IETF is to just list the parameters and possible parameter values.
[Manu Sporny]

We still have to define how we detect whether an IRI is an absolute IRI or not (this should be easy as we just have to look for a colon and an undefined prefix). We also have to define whether we allow stuff like "../" and "./" in relative IRIs and suffixes. Doing so would require IRI normalization and would go beyond pure textual concatenation.

The Wikipedia entry for JSON-LD could use more references (eg, to the API and Graph Normalization docs and the Playground).

In the current spec we rely on XML Schema for automatic typing. This is problematic as it causes several data round-tripping issues:

• no distinction between xsd:decimal and xsd:double (round-tripping)
• "doubles" are normalized to "%1.6e" which might be lossy
• JSON datatypes do not really match the XML datatypes:
  • xsd:boolean = { true, false, 0, 1 }
  • xsd:decimal = allows leading +, zeroes
  • xsd:double = has INF, -INF, NaN; 64-bit prec.

To my best knowledge XSD doesn't even have a resolvable representation (vocabulary) in RDF. So it isn't even Linked Data.
Furthermore the use of XSD creates a dependency on the XML Schema specification which I consider a huge overkill.

I know, we talked about this already when we discussed the support for NULL (ISSUE-11) but I would like to discuss this again on the mailing list. Should we create a simple vocabulary for the JSON type system? Considering that the type system is quite small, it should be straightforward to do so.

We would then have something like e.g. json:number or json:string. This would eliminate all our round-tripping issues at a very low price. It would also allow us to eliminate the @iri keyword (which is just syntactic sugar) if we would like to do so as we could introduce a json:iri.

What are your thoughts? I think it's worth the little effort and I'm quite sure that it would be a vocabulary that would be reused quite often on the Web. Just consider the number of JSON-only Web APIs right now.

What should we do in API when things go wrong? Raise expections? Return null?

Consensus on the telecon was that we shoud raise exceptions in case of error and just return valid data.

What should we if your frame didn't match your input?

• return null
• return {}

Most people opted for returning {} at the telecon but there might be some implications that should be further investigated.

@type is used to set the type of the active subject.
@datatype is used to specify the datatype for a literal.

Since @datatype has always to be used with @literal in an object it is kind of redundant. E.g. consider the following:

...
  { "@literal": "4.8", "@datatype": "xsd:decimal" }
...

It would be invalid to create something like

{ "@literal": "Markus", "@type": "foaf:Person" }

I understand that in a RDF world the distinction is necessary, but in JSON-LD we do not need to distinguish the two keywords as they can't be misinterpreted.

So I would like to propose to merge @datatype and @type to @type (ISSUE-31). I think this won't cause any problems in the already implemented algorithms and just require a change from @datatype to @type. The reason behind this is that both, @type and @datatype, specify the "data type" of a construct, the only difference is that the one addresses subjects while the other addresses objects.
Since simplicity is one of the design goals of JSON-LD, the reduction of keywords is desirable.

Reported by Thomas Steiner:

On http://json-ld.org/spec/latest/ (as published on 8/23) section 3.11 seems to contain an error in the first listing.

The first occurrence of @Coerce should most probably be @context.

To have a smoth upgrade path from simple (existing) JSON APIs/feeds to JSON-LD we should consider adding a HTTP Link header (RFC5988) to link from the plain JSON document to the JSON-LD context document. I would suggest a link in the following form:

Link: <http://www.example.com/context.jsonld>; rel="describedby"; type="application/ld+json";

or (I'm not sure if MIME type parameters are allowed)

Link: <http://www.example.com/context.jsonld>; rel="describedby"; type="application/ld+json;format=context";

To link from a context document to an instance document we could add a "data" or "instance" MIME type parameter. E.g.

Content-Type: application/ld+json; data=http://www.example.com/context.json

There were also some discussion on the mailing list to add a format=context parameter to the MIME type. So it might look as follows:

Content-Type: application/ld+json; format=context; data=http://www.example.com/context.json

Reading the current spec, there is a lot of repetition in "Multiple Typed Literals for a Single Property".

Couldn't we simplify this drastically by allowing arrays of literals? Something like

{
  ...
  "@subject": "http://example.org/articles/8",
  "modified": 
  {
    "@literal": [
      "2010-05-29T14:17:39+02:00",
      "2010-05-30T09:21:28-04:00"
    ],
    "@datatype": "dateTime"
  }
}

Instead of having to write

{
  ...
  "@subject": "http://example.org/articles/8",
  "modified": 
  [
    {
      "@literal": "2010-05-29T14:17:39+02:00",
      "@datatype": "dateTime"
    },
    {
      "@literal": "2010-05-30T09:21:28-04:00",
      "@datatype": "dateTime"
    }
  ]
}

The spec describes defining an @context in terms of having an "active context". This allows terms and prefixes to be used within a @context definition, if they are defined earlier.

Update the spec to ensure that this is clear, and to allow both from contexts defined in a higher object, and those that precede within an array of contexts.

In the current spec it is not clear where prefixes (CURIES) are allowed. Are they just allowed in properties and objects or also in subjects!?

Do objects using prefixes have to be coerced using @iri? If so, how do we distinguish between IRIs and prefixes without using CURIE's square brackets? How do we distinguish between IRIs and prefixes in properties?

Currently there is no way to distinguishing a context document from an instance document if it isn't know beforehand. There are a couple of options to solve this issue:

• create a new MIME type
• use the form MIME type parameter, i.e., form=context
• include @context also in pure context documents

Using a MIME type (parameter) for this is problematic for client-side JavaScript implementations. Including @context also in context documents seems to be a straightforward and simple way to do it. The only issue then is to ensure that there isn't any data in a context document - but I'm not even sure if we need to do that.

Perhaps we also just say it's not important to be able to distinguish it because a client has to know what it requests!?

Philip Jägenstedt wrote:

http://json-ld.org/playground/

Bug report for Opera:

1. click "Person"
2. nothing happens

Alternatively:

1. click "Person"
2. click "Expanded" (you see some JSON)

The two sections Vocabulary Prefixes and IRI Expansion are confusing and inaccurate in the current spec. They could be easily misinterpreted.

Since there's no way to specify if a mapping in the context is for a prefix or a term. The result of the, admittedly silly, example.

{
 "@context": { "payment": "http://example.com/payment/" },
 "payment:payment": "done",
 "payment:amount": 20.4
}

could be expected to be the following:

<> <http://example.com/payment/http://example.com/payment/> "done" .
<> <http://example.com/payment/amount> "20.4"^^xsd:double .

Markus wrote:

I thought a bit more about the recent discussions here on the mailing list and came to the conclusion that it might be better to split the JSON-LD spec into two parts:

1. JSON-LD (the language)
2. JSON-LD Processing (APIs, algorithms, etc.)

I think doing so would reflect the fact that different people are interested in different aspects of JSON-LD. Of course, everyone has to understand JSON-LD the language, thus we should really put a strong emphasis on a simple, short, and easy to understand spec for that.

The rest of the e-mail thread can be found here:

http://lists.w3.org/Archives/Public/public-linked-json/2011Sep/0017.html

Today in #json-ld, Manu and I discussed improving the compact form serializers to produce shorter, more compartmentalized, digest-able output. The optimization is primarily against @iri-keyed blocks, esp. with predicates having multiple IRI targets.

Any value like { @iri: /joe } should be automatically compacted to just "/joe" and a coercion rule should be added to the @context.

We also briefly speculated whether this should be described as a new form, eg. "short".

In any case, there should be a form where all non-data terms are separated into @context sections as much as possible. This will help pave the way for JSON-LD Web Services to encourage plain k/v pairs with "default @context". And support /really/ thin clients that don't have any LD know-how (@iri) whatsoever (ignore all @).

Explicit example:

{ "@context": {"foo": "http://example.com/foo#"}, "foo:bar": [{ "@iri" : "http://example.com/blah" }, { "@iri" : "http://example.com/blah" }] } }

optimized to:

{ "@context": {"foo": "http://example.com/foo#", "@Coerce": {"@iri": ["foo:bar"]}}, "foo:bar": ["http://example.com/blah", "http://example.com/blah"] }