Re: New Draft comments: Publishing

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 Monday, 28 January 2013 22:30:15 UTC