Re: Agenda: Web Annotation Teleconference 9 Sept 2015

Rob,

thanks. I understand better where you come from; I also understand (I think) why you proposed the compartmentalized contexts.

TL;DR
- I stay by my -1 for the compartmentalization
- As for the "@id"/"id" and "@type"/"type", I will not lie down the road if the group decides to revert the earlier decision (re also to Benjamin's mail, although that particular problem can probably be solved if we chose other terms). That being said, I am still not convinced of the wisdom to do the revert.

The longer argument:

The point is, as I said in my earlier mails: there is nothing special, in this sense, in "id" vs. "@id" (or "type" vs. "@type").  Your argumentation about possible conflicts also holds for any JSON-LD term for which we define mapping to a full (URL) name *if* another vocabulary (AS in this case) chooses *another* term and a mapping to the same full name. (I presume that is the reason for your compartmentalization idea.) This is a more general problem of how to do integration of JSON-LD data within the same application when several vocabularies are mixed and if the implementation does not want to go to the underlying RDF model but want to stay on the JSON level instead.

(The JSON-LD API does give an implementer *some* help to handle this, b.t.w.: instead of using compaction, use the Expanded Document Form[1]. All the term aliases would disappear and be replaced by the full name. I realize, however, that the expansion would also restructure the JSON part a bit, though, which would complicate things. There may be a need for an "Expansion Lite API" that just expands the aliases...)

The logic of the argument, if followed through, would require us to synchronize with AS very closely to cross-check the various JSON-LD terms that we or they would choose to define in the respective contexts, and avoid any clashes. And why only AS? We should do the same with LDP, with the CSV Metadata Vocabulary, the JSON-LD representation of schema.org, etc. And what about other vocabularies to come?  This does not scale. Or more exactly: the only way to avoid these is *not* to use the possibility to map a term to a URI in @context, ie, only use prefixed terms everywhere instead (just like Turtle does). I do not think we want to go there.

The tension we have seems to be between

1. Ensure that implementers who want to *integrate* data have an easy (easier) way of integrating OA with other, JSON-LD based serializations of data; and
2. Ensure that the terms we use are the most amicable possible to pure JSON users/implementers when creating and reading OA data

Acknowledging that what "amicable" is in #2 is also a matter of personal taste. But we cannot avoid that.

My approach is to favour #2 over #1 whenever possible. That is why I keep by my -1 for compartmentalization. That is also why I am  not convinced about the revert for "id"/"@id". (Although, *personally*, I am not bothered by the "@" character at all, but there was a reason why the group felt a change was good.) However, because I recognize the very special nature of "@id"/"id" and "@type"/"type" mainly in terms of their ubiquitous usage, I will not lie down the road if those are changed by a WG decision.

Thanks

Ivan

P.S. I am not authorized to post mails to the AS mailing list; it is a bit disagreeable that we get this discussion cut into two different threads. Oh well...

[1] http://www.w3.org/TR/json-ld/#expanded-document-form <http://www.w3.org/TR/json-ld/#expanded-document-form>


> On 08 Sep 2015, at 19:08 , Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> 
> On Mon, Sep 7, 2015 at 12:22 AM, Ivan Herman <ivan@w3.org <mailto: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 <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 <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


----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704