Merge @coerce with @context about json-ld.org

[lanthaler]

Yet another alternative was:

    "created": { "@iri" : "http://purl.org/dc/terms/created", "@coerce": "xsd:dateTime"}

We also discussed using @datatype or @type instead of @Coerce in this case.

[gkellogg]

Agreed in http://json-ld.org/minutes/2011-11-15/ that we would move @Coerce definitions into term definitions.

No agreement yet on the specifics of the syntax, or if @vocab is included and can be used to resolve terms in IRI positions during the parsing of the context in which it is defined. For example:

"@context": {
  "@vocab": "http://xmlns.org/foaf/0.1/",
  "Person": {"Person": "@iri" }
}

[gkellogg]

I just finished updating my implementation to accept both the old @Coerce model as well as one of the proposed new models. Here are some observations:

Requiring that data typing always be done in the context of a term definition requires more terms to be defined. For example, I I just wanted to set a datatype of xsd:date on dc:date, I'd need to create a term for dc:date, which wouldn't otherwise be necessary. We may want to consider an alternate syntax that doesn't require a term be be created. More of a problem when serializing an existing RDF graph, where you may have some standard namespace definitions, but not terms.

I find the {"@iri": "foo", "@Coerce": "xsd:date", "@list": true} notation to be in keeping with the overall style of JSON-LD. If the @iri is missing, I create an IRI for the term using the in-scope @vocab, which must be defined in a prior context. For example:

{
  "@context": [
    {"date": "http://www.w3.org/2001/XMLSchema#date", "term": "http://example.org/foo#"},
    {"foo": {"@iri": "term", "@coerce": "date"}}
  ],
  "foo": "bar"
}

Specifying that the term uses a list, just requires adding "@list": true to the object.

While using @Coerce is correct, I think that in actual use, people may use @datatype here, as they would otherwise use @datatype when defining a literal. We should consider either replacing @Coerce with @datatype, or allowing @datatype to act as an alias in this context.

The alternative of using objects with an IRI key seems shorter, but is less JSON-LD like.

For the time being, I'm going to accept either an @Coerce block (with the previous dt: [prop] syntax) as well as the Object notation. I still need to update the serializer based on these rules.

[gkellogg]

One thought about using the @context definition to perform datatype coercion on properties without defining a term. Consider that the key may be a term, prefix:suffix, or IRI. As a term matches an NCName, we can tell that this entry is for a term definition, otherwise, any @iri content is ignored, and the key is expanded to an IRI and used to specify the associated datatype/list coercion rules. For example:

{
  "@context": {
    "date": {"@iri": "dc:date", "@coerce": "xsd:date"},
    "dc:created": { "@coerce": "xsd:dateTime"}
  }
}

The first entry defines a term, which has values coerced to xsd:date. The second entry does not define a term, but indicates that properties with the IRI created by expanding dc:created have values coerced to xsd:dateTime.

This is important, as serializing RDF data to JSON can use pre-defined namespaces, but would not typically have any pre-defined terms. Terms aren't necessary for most RDF serialization cases, so avoiding their manufacture make sense.

[gkellogg]

Looking at some more tests, the fact that prefix or @vocab definitions need to be done before they are used in datatypes or term definitions creates a lot of blocks like the following:

    "@context": [
      {
        "xsd": "http://www.w3.org/2001/XMLSchema#",
        "dc": "http://purl.org/dc/terms/"
      },
      {
        "dc:date": {"@coerce": "xsd:date"}
      }
    ]

Doing multiple passes across a context would simplify this and lead towards greater acceptance, I would think. We could then do the following:

    "@context": [
      {
        "xsd": "http://www.w3.org/2001/XMLSchema#",
        "dc": "http://purl.org/dc/terms/"
        "dc:date": {"@coerce": "xsd:date"}
      }
    ]

[lanthaler]

I like the {"@iri": .., "@datatype": ..., "@list": true} notation but find the @list a bit confusing. As I interpret it the datatype would be applied to every list item, right? Isn't @list part of the data type of that property?

What about having {"@iri": .., "@datatype": ..} for non-list properties and {"@iri": .., "@list": { "@datatype": ... } } for lists? That would make it quite explicit that the datatype applies to the list items.

Supporting prefix:suffix coercions in the context would definitely have advantages, but why would you like to ignore @iri there? If it's present, we just could just use it. This would also allow to have some sort of namespace support which is heavily discussed these days (not in the context of JSON-LD but for plain old JSON).

Talking about using @vocab definitions in @context I'm strictly against supporting that. It will make contexts extremely difficult to understand and has the potential to break things. Just consider a scenario where a external context changes @vocab. That would probably break all subsequently defined contexts and would be very difficult to debug. The same applies to @base. Thus I still think it would be a good idea to drop @vocab and @base altogether. We can achieve everything without them and by using prefixes the overhead would be minimal.

Markus Lanthaler
@markuslanthaler

[gkellogg]

The thing is, this just doesn't seem much like the rest of JSON-LD. The pattern elsewhere is to use an object notation calling out particular semantics:

{"@iri": "http://example.com/"}
{"@literal": "foo", "@language": bar}

introducing a new layer seems like a step away from this. I can see your logic, but I think that adding "@list" to the prefix definition is in keeping with other syntactical cues in the language.

{"@uri": "http://schema.org/playlist", "@datatype": "@iri", "@list": true}

If we honored using "@iri", this could lead to inconsistencies, that could even be malevolent. Consider the following:

"@context": {
  "foaf:knows": {"@iri": "http://nothing" }
}

This implies that "foaf:knows" is now a term, not a prefix:suffix form, and that it's meaning can vary from that used as a prefix.

There's a separate issue on@base and @vocab (#26). We shouldn't conflate these issues. If we do keep them, then we need rules to ensure they're used appropriately. The issue of defining @vocab in an external context is really no different than defining a prefix in an external context.

[lanthaler]

OK, I see what you mean regarding @list and after having spent some more thoughts on it I agree with you. Using @list as you proposed aligns better with how the rest of JSON-LD is designed.

The only problem with it could be that some people will argue that it's used differently in different contexts, i.e., it expects a boolean within the context but an array of list items in the body of a JSON-LD document. Unfortunately I don't have an clean solution for that.. So perhaps we should reconsider putting @list into @datatype!?

Regarding allowing @iri within prefix:suffix definitions: I don't see this as a big issue. We won't be able to prevent malevolent definitions anyway. On the other hand it would allow us to map "terms" that contain a colon to an IRI. Just imaging a JSON document that was created by combining two other documents. The normal approach would be to prepend a namespace to every key in order to avoid collisions. The usage of a colon is widely used for such scenarios. A note in the spec about the potential misuse would do it IMHO.

Talking about @vocab and @base (#26) I don't think that should be seen as equal. You could see @vocab and @base as kind of global variables while a prefix was specifically (and intentionally) created. But that's another discussion, I agree.

Markus Lanthaler
@markuslanthaler

-----Original Message-----
From: Gregg Kellogg [mailto:reply+i-2240361-
[email protected]]
Sent: Monday, November 28, 2011 2:16 AM
To: Markus Lanthaler
Subject: Re: [json-ld.org] Merge @Coerce with @context (#40)

The thing is, this just doesn't seem much like the rest of JSON-LD. The
pattern elsewhere is to use an object notation calling out particular
semantics:

{"@iri": "http://example.com/"}
{"@literal": "foo", "@language": bar}

introducing a new layer seems like a step away from this. I can see
your logic, but I think that adding "@list" to the prefix definition is
in keeping with other syntactical cues in the language.

{"@uri": "http://schema.org/playlist", "@datatype": "@iri",

"@list": true}

If we honored using "@iri", this could lead to inconsistencies, that
could even be malevolent. Consider the following:

"@context": {
  "foaf:knows": {"@iri": "http://nothing" }
}

This implies that "foaf:knows" is now a term, not a prefix:suffix form,
and that it's meaning can vary from that used as a prefix.

There's a separate issue on@base and @vocab (#26). We shouldn't
conflate these issues. If we do keep them, then we need rules to ensure
they're used appropriately. The issue of defining @vocab in an external
context is really no different than defining a prefix in an external
context.

---

Reply to this email directly or view it on GitHub:
#40 (comment)

[lanthaler]

In preparation for today's telecon I've tried to collect all proposals for
issue #40 so far:

1. "foo": {"@iri": "http://uri.foo", "@coerce": ["xsd:date", "@list"] }

2. "foo": {"@iri": "http://uri.foo", "@coerce": "xsd:date", "@list": true}

3. "foo": {"@iri": "http://uri.foo", "@datatype": "xsd:date", "@list": true}

4. "foo": {"@iri": "http://uri.foo", "@list": { "@datatype": "xsd:date" } }

5. "foo": { "http://uri.foo": { "@list": "xsd:date" } }

[lanthaler]

It was decided to adopt option 3:

    "foo": {"@iri": "http://uri.foo", "@datatype": "xsd:date", "@list": true}

or

    "foo": {"@iri": "http://uri.foo", "@datatype": "@iri", "@list": true}

[lanthaler]

From: David I. Lehn:

In issue #40 and on the recent telecon call progress was made towards a syntax such as:

 "foo": {"@iri": "http://uri.foo", "@datatype": "xsd:date", "@list": true}

or

 "foo": {"@iri": "http://uri.foo", "@datatype": "@iri", "@list": true}

In IRC I commented that the '"@list":true' style seems non-optimal. To go along with @datatype I suggested '"@parsetype":"list"' or '"@parsetype":"@list"'. Dave Longley suggested the "@structure" keyword instead. That name seems a better choice. This syntax allows more flexibility to support types like "@set" or similar without
another '"@{type}":true' construct. Now in issue #44 we can see a use case of this in @contexts for framing. I'm thinking this is the right direction to head. This would make the above something like:

"foo": {"@iri": "http://uri.foo", "@datatype": "@iri", "@structure": "@list"}

Questions:
What @structure types might be needed other than @list and @set?
Could there be use cases for needing multiple @structure types at once?
How much does this complicate processing?
Would it be better to use arbitrary IRI types instead of "@list" style? Ie, '"@structure":"jsonld:list"' or something? Maybe @list and @set would be aliases for IRIs.

[lanthaler]

Response Markus Lanthaler:

It's true that the "@list: true" approach doesn't scale nicely but I think whenever possible we should avoid introducing new keywords. I though a bit more about this issue and came up with another possible solution for it, namely:

 "foo": {"@iri": "http://uri.foo", "@datatype": "@list[@iri]" }

or

 "foo": {"@iri": "http://uri.foo", "@datatype": "@list[xsd:date]" }

IMO this syntax would be intuitively understood by developers, it scales nicely (@set[...]) and wouldn't complicate processing too much. Of course the same syntax can also be used for @type to support arrays of objects. And
even if we merge @type and @datatype it would still work as @type would require an array of objects while @datatype would require an array of literals (whether they are JSON strings, numbers, or booleans doesn't matter).

 > Would it be better to use arbitrary IRI types instead of "@list"
 > style?  Ie, '"@structure":"jsonld:list"' or something? Maybe @list and
 > @set would be aliases for IRIs.

I think we agreed quite some time ago to not create a JSON-LD vocabulary..

[msporny]

http://json-ld.org/spec/ED/json-ld-syntax/20120122/#typed-values