Re: Agenda: Web Annotation Teleconference 9 Sept 2015

On Mon, Sep 7, 2015 at 12:22 AM, Ivan Herman <ivan@w3.org> wrote:
>
> ##  Compartmentalized Contexts
>  * Have a base context that defines the JSON-LD keys the WG would like
> everyone to use for *our* predicates/classes
>  * Have an additional context for non OA predicates and classes that we
> recommend
>
> I am not in favour or separating these two, I do not see the reason for
> it. The more @context-s the user has to add to his/her JSON file the worse
> is imho. Actually, I am not even sure where this proposal comes from, did
> we discuss this? B.t.w., we are not defining or, in your term, taking
> authority for any of those terms; essentially, give an easy access to
> vocabularies like skos or iana, or terms like foaf:Person.
> Ie: -1 for that from my point of view.
>

>  * Revert the @id and @type change, or at most have it in a third,
> optional context
>
> I am not sure there is, indeed, a problem, see my separate mail on the
> subject:
>


The proposal comes from me to resolve the issue of conflicting contexts
between WGs.  As discussed on the last call, we want to discuss concrete
proposals in order to make faster progress, rather than designing by
committee and spending 3 months per issue.  The alternative would be to
have task forces to work on issues in parallel, but (as chair) I feel like
we do not have sufficient active participants in the WG to productively
divide our efforts.


I'll try again to explain the issue:

If we want to use the output from other WGs, such as the Social Web WG, *in
a pure JSON environment*, then we should conform to their expectations of
what the JSON-LD will look like.  Similarly people with a focus on
ActivityStreams that want to use our model in their JSON, should respect
what we want it to look like.

Perhaps I should not take this for granted, and instead we're going to
re-work all of the ActivityStreams JSON-LD mappings, and there is no intent
to use anything other than the names of the predicates?  Thus the
interoperability would be only at the model or RDF level, not at the
practical level of JSON based clients.  Given that we would then need to
write tests, implementations and so forth for it separately from other WGs,
I am strongly -1 to reinventing wheels.  This entire process and
organization is about interoperability between systems, after all.

Assuming then that we do want to allow existing AS clients to read our use
of AS resources, then we should not generate JSON that those clients cannot
understand.

In order for that to actually work in practice, the absolute minimum is to
use @id and @type for several reasons:

1.  An AS system that looks at the resource in the as:Collection will try
to determine its class by looking for @type.  It won't find it, and have no
way of knowing what to do with the resource.
2.  When compacted, *all* of the @id and @type keys will turn into id and
type if we define them in our context.  Thus an AS client will not even be
able to find the type and URI for the AS resources, let alone the
Annotation resources.

And repeat for all other uses of an Annotation is used along with other
content.  It would force everyone to create their own contexts to use our
model in JSON-LD, even if they wanted to use all the same keys other than
id/type.



> https://lists.w3.org/Archives/Public/public-annotation/2015Sep/0082.html
>
> at this moment, unless there really *is* a major problem, I do not see any
> new issue/evidence that would warrant us to revert the decision. I
> certainly do not want to make this decision without further discussions.
>

In that mail you ask if it's correct ... Yes, it is correct.

Here is the JSON-LD playground demonstration to prove it:
http://tinyurl.com/o2e7y8p

Note that the input has @id and @type for the ActivityStreams content and
id and type for the Annotation. After compaction, the Annotation context's
use of id and type clobber the ActivityStream content keys.


Rob

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