ISSUE-31: Merge @type and @datatype / JSON-LD Telecon Minutes for 2011-10-18

>From reading the minutes and listening to the telecon recordings I think there have been quite some misunderstandings. Let me try to elaborate a bit on the consequences of merging @type and @datatype. 

@type can be used to set the type (think class) of a JSON object. For example you can use it to say that a specific JSON object in a JSON-LD document represents a person (foaf:person). On the other hand, @datatype, is used to specify the datatype of a JSON property. The only way to do that is when the extended form is used (in all other cases @coerce is used): 

{
  ...
  "property":
  {
    "@literal": "value",
    "@datatype": "whatevertype"
  }
}

At the same time @type can't be used in such a construct as it would result in invalid triples. So having

{
  ...
  "property":
  {
    "@literal": "value",
    "@type": "whatevertype"
  }
}

is invalid anyway. Thus, there is really no need to have two terms to set the datatype of a JSON object/property. In the telecon and on the mailing list some people argued that this will result in more invalid data. But I can't why this would be prevented by having two keywords? I think quite the opposite will happen, a lot of developers will probably use @type and @datatype in the wrong places if we have both of them.

Aliasing @datatype to @type as suggested on the call isn't a solution either. Processors would then have to check the surrounding tags to resolve the conflict - that's exactly the behavior we need when we merge the two. So either we disallow aliasing @datatype to @type or we just move on and merge them.

The only thing developers could get wrong is to use a class type when they mean a datatype or vice versa. But that can't be prevented by keeping @datatype and @type separate. I can't see with the best will in the world one argument to keep both of them. But perhaps someone will teach me better.


--
Markus Lanthaler
@markuslanthaler

Received on Saturday, 22 October 2011 15:12:32 UTC