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

Re: New Draft comments: Publishing

From: Robert Sanderson <azaroth42@gmail.com>
Date: Tue, 29 Jan 2013 08:40:30 -0700
Message-ID: <CABevsUFYuFQcXBgGyQO29BL1AQ1vYmUo0PnzNm7OxX3ZiDBxVw@mail.gmail.com>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: public-openannotation <public-openannotation@w3.org>
Done :)

Rob

On Mon, Jan 28, 2013 at 3:29 PM, Antoine Isaac <aisaac@few.vu.nl> wrote:
> On 1/28/13 11:13 PM, Robert Sanderson wrote:
>>
>> 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.
>
>
>
> MAY/MAY could be ok.
> In fact putting a preference accounting for Accept headers may be tricky: if
> the graph is embedded, then it means that you get it at the same time as the
> description of the annotation, if I'm not mistaken. But let's not forget
> that the Accept header is the one sent by the client for negotiating the
> description associated with the URI of the annotation. I reckon that if
> there is trig/trix in the Accept header for the Annotation URI, it's a very
> good hint that a client can ingest trig/trix for other resources than the
> annotation one. It would be really weird otherwise. But I'm not sure we can
> assume it is always the case.
>
> Antoine
>
>
Received on Tuesday, 29 January 2013 15:41:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 29 January 2013 15:41:04 GMT