W3C home > Mailing lists > Public > public-openannotation@w3.org > January 2013

Re: New Draft comments: Publishing

From: Robert Sanderson <azaroth42@gmail.com>
Date: Mon, 28 Jan 2013 15:13:22 -0700
Message-ID: <CABevsUHcv2TRDkS5XezUsw29LNXFL_HpQZQ56p_jiRz0mGexhg@mail.gmail.com>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: public-openannotation <public-openannotation@w3.org>
On Mon, Jan 28, 2013 at 2:45 PM, Antoine Isaac <aisaac@few.vu.nl> wrote:
>>> 1. Names in JSON serialization specification
>> This was just to be more "JSON-friendly" rather than a strict 1:1
>> mapping into RDF.  The expectation was that developers wanting a JSON
>> serialization which happens to be RDF would be more comfortable with
>> these object/hash property names.

> Yep, I had missed this one.
> I think that here the benefits of homogeneity (for understanding the spec
> and for maintaining it) are too big to ignore. In fact if members of the
> group feel the properties should be JSON-friendly, then I'd rather have the
> RDF properties JSON-friendly, too!


To explain the the rationale behind "has[Class]", it was (not safe for
consensus warning!) to avoid the tendency to put literals as the
object of the predicate.  So hasBody was thought to better imply that
there was a resource as the object, compared to body which implied
(due to Annotea and other specs) a literal.

And I buy the homogeneity argument.  Having to do one thing in one
serialization and another in JSON would be a pain for those who
implement JSON plus other RDF formats.

So, if there are no objections, I'll change them over to be 1:1 with
the rdf predicates.

>>> 2. The paragraph on embedding RDF graphs in 5.2 ("An unusual [...]
>>> serialized resource") could be quite confusing. Especially, it reads a
>>> bit
>>> out of synch with 5.4, which recommends using named graphs.

>> * SHOULD just refer to a dereferencable HTTP URI for the graph
>> * if the graph is embedded:
>>     * SHOULD use Content in RDF
>>     * MAY use Named Graphs IFF trig/trix is requested with content
>> negotiation
> Are we sure we want to express a preference here (SHOULD vs. MAY) between
> Content in RDF and NGs? I personally think we could keep them on a par --
> though I won't be fighting for it till death.

So MAY / MAY ?

The rationale here was that if the client doesn't request trig/trix,
and there isn't a resolvable URI, then you have to support Content in
RDF anyway.

On the other hand, if a client DOES ask specifically for trig/trix,
then you surely SHOULD give it to them.

I'll try to reformulate 5.2 and 5.4 in this manner.

>>> 3. Is oa:equivalentTo transitive?
>> I believe so.  If A equiv B, and B equiv C, then A equiv C.
>> (and C equiv B, and C equiv A, and B equiv A)
> OK, then I think it's worth being mentioned. It always help (at least people
> like me) to get the intended semantics.


Received on Monday, 28 January 2013 22:13:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:38:21 UTC