Re: JSON-LD & N3

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.


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

It would also help if you can provide clear use cases and/or code 
examples that highlight the problems.


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

Regards–
–Doug

Received on Saturday, 13 June 2015 17:12:25 UTC