Re: JSON-LD & N3

Hi Henry,

On Sat, Jun 13, 2015 at 10:12 AM, Doug Schepers <schepers@w3.org> wrote:

> Hi, Henry–
>
> On 6/13/15 2:59 AM, Henry Story wrote:
>
>>
>>  On 12 Jun 2015, at 20:52, Robert Sanderson wrote:
>>>
>>> This is noted in annotation-protocol section 3.3.2:
>>>
>>> http://w3c.github.io/web-annotation/protocol/wd/#retrieve-a-known-annotation
>>> (Though as a very much in-flux ED, I have not fleshed out the related
>>> IANA considerations)
>>>
>>
>> So looking at those examples of annotations they do all look very
>> simple, and with hardly any structure.
>> Of course as a result the problem of a specific crystallisation/ profile
>> does not appear. But can annotations not be more complex? Could it not
>> be that they nest some information? And as soon as that happens the
>> problem of knowing how will be important to a client ( that does not use
>> RDF tools ).
>>
>
> The Web Annotation Data Model is deliberately simple. You can make large
> annotations (with very long-form bodies, or image or video bodies), and
> more complex examples (multiple targets, multiple bodies, etc.), but
> nesting happens by linking to another annotation (that is, annotating an
> annotation).
> So, it seems to me that the issue of
> crystallisation/profile/shape/canonical is not critical here.
>

Let's split this in to two questions:

1.  What happens when there's information beyond that specified in the OA
model?

I think that the recommendation to ignore information that is not
understood is sufficient here.
For example, perhaps an annotation wants to record the size of an image
that is being used as the body or target of the annotation.  It might use
exif:height and exif:width to do that, which are not in the OA JSON-LD
context.  A system that didn't understand this information would simply
ignore it.


2.  What is the general shape of the graph when following the OA model?

This is what the profile would identify and describe.  Other profiles might
specify additional features or mappings, for example to add in additional
properties of the objects being referred to in the annotation,
authorization requirements, further description of the actors or
provenance, etc.


 There's no need to define a new header (Accept-Shape) or a new media
>>> type, as the JSON-LD media type by design has a profile attribute.
>>> And there is a registry for such profiles, defined by RFC 7284.
>>>  (https://tools.ietf.org/html/rfc7284)   Its initial contents include
>>> flattened, expanded and compacted JSON-LD shapes.
>>>
>>
>> That is fine for a very limited number of profiles. But if an
>> application wanted something more precise than the three default ones
>> provided by JSON-LD then registration of human readable documents is not
>> yet very satisfactory
>
>
Hence we would register a new profile that is more precise than the three
default ones.
Exactly how that registration is made is specified in rfc7284, and while we
might be more explicit in the privacy of our own specification, we would
have to follow the IETF practice.


- it does not seem to me that any of those three
>> profiles are sufficient for the Activiy Streams 2 syntax for example (
>> but James M. Snell may be able to correct me here )
>> http://www.w3.org/TR/activitystreams-core/ .
>>
>
> This is a concrete claim that, if correct, we need to fix. We want to be
> compatible with Activiy Streams 2.
> Can you please explain how what we've defined is insufficient for Activity
> Streams 2 syntax?
>

As far as I understand you, Henry, you're saying that -compacted,
-flattened and -expanded are not sufficient for Activity Streams, rather
than anything to do with Open Annotation, right?  Thus AS2.0 would also
need to register a profile, which seems to be that the process is working
as expected, but should be discussed with the Social Web WG.


If so then what is needed
>> is a machine readable profile document, that can be used by LDP servers
>> to produce the correct shape for the user, without code needing to be
>> written for each different type of document on the LDP server!
>>
>
> With conflicting claims about the need for data shapes here, we need
> explicit examples in order to act. Can you please provide such examples, as
> evidence to reinforce your view?
>

A machine readable profile document would be lovely, but as frames weren't
accepted as part of the JSON-LD standardization work, I don't know of how
we could provide that.  It's certainly not in the remit of the Annotation
WG to standardize framing (nor LDP, nor Social). I brought it up to the RDF
Shapes WG at TPAC and they were also not interested in taking it forwards.

At the moment I think the best we can do is an implementation note that
provides the frames, sample code and a reference to the JSON-LD.org
specification.  As to the complexity of this, it took me exactly 23 minutes
to write a frame based solution that mapped from one annotation context to
another as a stand alone web service. The actual transformation code is
about 5 lines, plus some extra handling to avoid always looking up the
context documents and getting banned for hammering the W3C server :D

Rob

-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305