Re: framing and @reverse - java implementation proposal

Hello Markus,

On Wed, Jul 30, 2014 at 3:35 AM, Markus Lanthaler <markus.lanthaler@gmx.net>
wrote:
>
>
> Cool. Would be cool if you could provide a link to that app.
>

It's not yet online, but I will share it once it's functional.


> >  2. an extension of the compacting algorithm to allow the definition
> >  of multiple reverse statements for the same property, but different
> >  target types
>
> What exactly do you mean by target?
>
>   (A) <---- reverse of property --- (B)
>
> Is (A) the "target" or (B)? If it is (B) the value of the property in
> JSON, then there's only one possible type, namely a IRI.


>
> The second feature is covered in
>
>
> https://github.com/pduchesne/jsonld-java/blob/FRAMING_REVERSE/core/src/test/resources/custom/framing-reverse-0002-frame.jsonld
>
> but I don't see why you need to "change the compaction algorithm" or the
> context for that matter if you are specifying the type inline anyway:
>


OK, this deserves some more explanations.
Using the same data types as in the test data below :
 - assume types Library, Book, Article
 - assume property 'containedIn', where   [Book | Article]  --containedIn-->
 Library
 - i need to frame a dataset, so that the 'containedIn' property is
reversed into two different properties depending on the target type
('books' or 'articles'), yielding :
    Library --books-->    [Book]* ;
            --articles--> [Article]*

The whole problem is that the framing context needs to contain two reverse
statements for the same property, and located in the same node in the frame
 :
    "books": {"@reverse":"containedIn"},
    "articles": {"@reverse":"containedIn"}

with the frame
{ "@type" : "Library",
  ...
  "books" : {"@type" : "Book"},
  "articles" : {"@type" : "Article"}
}
the framing algorithm, when expanding reversed properties, properly selects
'Book' and 'Article' instances, but then merges everything in a single
@reverse statement (because both 'books' and 'articles' are mapped on the
same property) :
{ ...
  "@reverse" : {
    "ex:containedIn" : [
        { book instance },
        { book instance },
        { article instance }
    ]}
}

Then the compacting phase, responsible for producing the actual 'books' and
'articles' members, is unable to distinguish what goes where, and will
regroup all instances (Book and Article) in one of the two matching reverse
statements, yielding :
{ ...
  "books: [
        { book instance },
        { book instance },
        { article instance }
    ]
}

Since the compacting algorithm (at least in its java implementation) does
not have access to the frame (only the framing result and the context), the
types bound to "books" and "articles" must be added to the context to get
the expected result.


>    articles": {"@reverse":"ex:containedIn", "@container": "@set", "@type":
> "ex:Article"},
>
> and
>
>     "articles": {
>         "@type": "ex:Article"
>     }
>
> are both kind of saying the same thing. So why do you include ex:Article
> in the context as well (the resulting document includes @type: ex:Article
> as well)?


As explained above, the @type in the frame is required to properly select
instances when doing the framing (normal usage).
The @type in the context @reverse statements (added by me to the spec) is
required as a hint to the compacting algorithm, so that it can group Book
and Article instances in their respective properties (namely 'books' and
'articles').


> Anyway, using @type this way is incorrect. In the context, @type can just
> be used to set the type of literals, i.e., strings. You can't use it to
> type nodes (objects).
>

That was my guess, but I didn't want to add a new keyword to the spec
without a first feedback from the community. I think the best way would be
to add a "@subtype" or "@targettype" (for the lack of a better name) that
can be used in @reverse statements.

But before that, is this functionality a reasonable update to the spec ?

I hope i was clear enough,
thank you for reading this far,

--p.

 @pduchesne