W3C home > Mailing lists > Public > public-linked-json@w3.org > May 2013

RE: Restrictions on reverse term definitions

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Sun, 19 May 2013 22:22:09 -0300
To: <public-linked-json@w3.org>
Message-ID: <00c101ce54f8$757f1b50$607d51f0$@lanthaler@gmx.net>
On Sunday, May 19, 2013 9:08 AM, Niklas Lindström wrote:

>     If an expanded term definition has an @reverse member, @id, @type,
>     and @language are not allowed. If an @container member exists, its
>     value must be null or @index.
> Why can't the definition contain "@container": "@set", to tell a
> compaction mechanism to always use an array?

This was probably an oversight. I just looked at my implementation and found
a reminder in the code which I obviously forgot.

The changes to fix this would be quite trivial:

- Compaction would need to take the property's container into
- Create Term Definition 10.5 would also need to allow @set

> And/or use "@type": "@id"
> to allow for use of IRIs as strings.

Reverse properties are always of type @id and will thus automatically
compact to strings if there are no other properties. Do you want to be able
to turn that automatic compaction off?

> Is it because the specified compaction doesn't make use of that (since
> it only uses reverses if it's explicitly given in the expanded form)?
> I can certainly understand that from the case of simplicity for that
> algorithm, but another compaction mechanism (e.g. using repeated re-
> embedding) could make use of @container or @type here. So I'm not sure
> if it's good to disallow this syntactically...

Good point.

Markus Lanthaler
Received on Monday, 20 May 2013 01:22:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:53:22 UTC