W3C home > Mailing lists > Public > public-linked-json@w3.org > October 2011

Re: Merge @type and @datatype

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sat, 01 Oct 2011 15:44:21 -0400
Message-ID: <4E876D95.4020305@digitalbazaar.com>
To: public-linked-json@w3.org
On 09/28/2011 08:25 AM, Markus Lanthaler wrote:
> Sorry for spamming the mailing list today, but as it was quite silent here
> recently I would like to use the opportunity to discuss a number of things I
> came up with while I reviewed the spec. So there may be more mails coming
> :-)

Not at all, thank you for keeping the discussion going!

> This one is about merging @type and @datatype.
> 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.

Interesting... I don't see any reason why we couldn't make this change. 
It does simplify the spec a bit... @type and @datatype do different 
things as far as the triples they generate are concerned... I don't know 
if this would confuse authors. What @type does is dependent on its 
context. I don't know if we really have any other attribute like it that 
is context-dependent (except for @context, of course). One could 
consider @language one of those features (if we support it in @context).

> 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.

That logic makes sense to me. +1

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Standardizing Payment Links - Why Online Tipping has Failed
Received on Saturday, 1 October 2011 19:44:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:32 UTC