Re: Restrictions on reverse term definitions

Hi,

On Mon, May 20, 2013 at 3:22 AM, Markus Lanthaler
<markus.lanthaler@gmx.net>wrote:

> 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 7.2.2.1.1 would need to take the property's container into
> consideration
> - Create Term Definition 10.5 would also need to allow @set
>
>
Do all agree that this should be done? I've made an issue of this:

    https://github.com/json-ld/json-ld.org/issues/253



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

I think so; I figure the data would be unpredictable otherwise. This should
be under the control of the context author, via the regular @container
mechanism.


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

Cheers,
Niklas



>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>