Official response to RDF-ISSUE-163: Determine if @type overloading is acceptable for JSON-LD 1.0

Hi Simon, Adrian,

Thank you for your feedback on the JSON-LD specifications. This is an
official response to RDF-ISSUE-163: Determine if @type overloading is
acceptable for JSON-LD 1.0, which is being tracked here:

http://www.w3.org/2011/rdf-wg/track/issues/163

Both of you commented on the mechanism that JSON-LD uses to specify type
information associated with a subject and an object. Simon noted that
the meaning of @type can be confusing as it is sensitive to the context
in which it is used. In general, when @type is used in a JSON-LD
Context, it specifies the datatype for a particular value associated
with a term. When used in a JSON-LD document body, it specifies the
rdf:type of a subject.

As both of you may or may not know, initially there were two separate
mechanisms for this behavior. @type to set rdf:type, and @datatype to
set the datatype for a particular value associated for a term. The group
decided to reduce the number of special keywords that must be used and
generalize the mechanism to just @type. This sets the type of a node in
a graph. As Simon mentioned, this leads to a slight amount of confusion
for first time authors, but experience has shown that a simple reading
of the specification or a tutorial make the usage more clear.

Both the JSON-LD group as well as the RDF WG have decided to keep the
feature as-is for the time being, while adding some editorial text to
clarify the use of @type in the JSON-LD Context vs. the JSON-LD document
body.

We believe this strikes the right balance between the choices that were
in front of the groups. Please respond as soon as possible to this email
to tell us whether or not you are satisfied with the decision of the group.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Tuesday, 22 October 2013 08:38:46 UTC