Re: JSON-LD Telecon Minutes for 2013-05-14 / RDF-ISSUE-128 and RDF-ISSUE-129

On May 18, 2013, at 6:54 PM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> I just had a chance to look at the minutes and have a couple of questions. Unfortunately I'll be on a plane on Tuesday so I would like to discuss these things beforehand on the mailing list.
> 
> Peter, I'm sending this mail to you directly as well as there's a question for you at the very bottom.
> 
> 
>> Topic: RDF-ISSUE-129: Lossless conversion
>> 
> [...]
>> Gregg Kellogg:  I wonder if the flag is in the wrong place
>> Gregg Kellogg:  perhaps there should be an expansion flag such
>>   that when we expand we turn all numeric data types into ? data
>>   types so that the consumers can choose how data is handled
>> Sandro Hawke:  I like that
> 
> Could you please explain in detail how the change you propose would look like?
> 
> We did that quite some time ago but decided to move the conversion between native types and strings to to/from RDF because that's where the complexity has to live. If you are staying within JSON-LD you shouldn't have to worry (or even know) about that.

Yes, we did discuss it before, but I think that the RDF round-tripping loss, and general need for developers to be able to use native types, have come into perspective. By always doing a full value-object based transformation of typed literals, we eliminate the data loss issue, but make it less convenient for developers to just use the native types. The problem is, that as a publisher, you really don't know what the intention of the consumer is, so imposing some behavior, through defaults in the core transformation algorithms, can lead to a bad experience. If it's really for the convenience of the developers, then doing it through algorithms run on the consumer side seems to really fit this target, and allows us to be more comprehensive.

My thought was that the fromRdf algorithm would always use full value objects for typed literals (e.g., like _use native types_=false). An added flag to expansion, passed through from compaction, flatten and framing, would allow value objects with numeric or boolean XSD types, to be transformed to the native JSON representation, or vis-versa. This means that there could be data loss, but this would happen only in the client application, where the application is in full control of the use of the data.

More specifically, in the Expansion Algorithm after step 8.4:

[[[
If the _use native types_ flag is true, the value of result's @value member is a string, and the value of result's @type string is xsd:boolean, xsd:float, xsd:decimal, xsd:double or a type derived from any of these datatypes (as defined in section 3 of [XSD]), transform the string into a native representation (using language currently in section 10.6).

Otherwise, if the _use native types_ flag is false and the value of result's @value member is a native value using canonical representation for the datatype in result's @type member, defaulting to xsd:boolean or xsd:double, depending on if value is a boolean or number.
]]]

At one time, all this was encapsulated in the Value Expansion Algorithm, but now it doesn't seem to be. Does this step capture all the places where a value might need to be transformed? If not, then we should consider re-writing Value Expansion and using that in the different locations.

Alternatively, we could consider doing this transformation as part of the Compaction or Value Compaction Algorithms, but Expansion seems better to me.

>> Sandro Hawke:  we many need to refer to a different spec
>>   regarding futures - the DOM WHATWG one might change.
>> Sandro Hawke:  hard requirement is to refer to stable things. it
>>   is hard to argue that the "living spec" is stable
>>   ... not saying we change the reference, but change how we use
>>   the reference
>> Manu Sporny:  We don't actually reference the Futures spec
>>   directly. We only use the Future concept in our spec, not the API
>>   itself.
>> Sandro Hawke:  if they change Futures, then every piece of
>>   software using futures would be broken and have to change
>> Manu Sporny:  Being pedantic, but the spec wouldn't change, just
>>   the implementation.
>> Sandro Hawke:  The director probably won't be okay with that. You
>>   shouldn't build on specs that are not stable
>>   ... We have to hard-code it with the current view of futures
>>   so that if it changes, we use the old version of futures
> 
> Hmm... that kind of surprises me. JSON itself e.g. is not a IETF standard but just an informational note. HTML5 is referencing a large number of living standards:
> 
> http://www.w3.org/html/wg/drafts/html/master/iana.html#references
> 
> In this case I think it makes no sense to hardcode the reference to a specific version because as Manu says, we just use the concept of a Future. The JSON-LD API should be based on what browser vendors implement - and that will be the WHATWG living standard.

The difference between DOM and JSON is that JSON quite stable, whereas who knows how much change might come to DOM?

Gregg

>> Topic: RDF-ISSUE-128: Mandatory profiles
>> 
> [...]
>> Gregg Kellogg: question is, can a server respond with any time,
>>   even if it doesn't match what's in the ACCEPT header.
>> Gregg Kellogg: … This includes type parameters, needs research.
>> Manu Sporny:
>>   http://lists.w3.org/Archives/Public/public-rdf-
>> comments/2013May/0038.html
>> Manu Sporny:  if the above satisfies Peter's comments then we
>>   should use that.
>> Niklas Lindström:
>>   http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
>> Niklas Lindström:  it sounds like we're restating the rules of
>>   content negotiiation
>> Stian Soiland-Reyes: I don't think you need to do 406 if it's
>>   just the profile parameter that can't be satisfied (it might be
>>   satisfied, the server just don't know that)
>> Manu Sporny:  we need to make sure we're not duplicating spec
>>   text
> 
> Peter already clarified that
> 
> <snip>
> [he] would be satisfied if the following passage in Section E,
> 
>    "The profile parameter may be used by clients to express their
> preferences in the content negotiation process."
> 
> was modified to something like:
> 
>    "The profile parameter MAY be used by clients to express their
> preferences in the content negotiation process. If the profile parameter is
> given a server SHOULD return a document that is structured based on the
> profiles in the list which are recognized by the server."
> </snip>
> 
> http://lists.w3.org/Archives/Public/public-rdf-comments/2013May/0034.html
> 
>> From listening to the audio, you weren't sure whether a server MUST be return a 406 Not Acceptable if it can't honor the profile. That's certainly not true - in fact most existing systems don't do that (as Manu already said).
> 
> The thing we are talking about here is called proactive negotiation. Here's the relevant snippet from the HTTP spec:
> 
>   A user agent cannot rely on proactive negotiation preferences being
>   consistently honored, since the origin server might not implement
>   proactive negotiation for the requested resource or might decide that
>   sending a response that doesn't conform to the user agent's
>   preferences is better than sending a 406 (Not Acceptable) response.
> 
> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-3.4.1
> 
> I would thus like to make the following
> 
> PROPOSAL: Change the following passage in Section E,
> 
>    "The profile parameter may be used by clients to express their
>     preferences in the content negotiation process."
> 
> to:
> 
>    "The profile parameter MAY be used by clients to express their
>     preferences in the content negotiation process. If the profile
>     parameter is given a server SHOULD return a document that 
>     honors the profiles in the list which are recognized by the
>     server."
> 
> 
> The only change I made to Peter's proposal is to generalize the "structured based on the profiles" to "honors the profiles".
> 
> Peter, would that would that address the concerns you raised in RDF-ISSUE-128:
> 
> http://www.w3.org/2011/rdf-wg/track/issues/128
> 
> 
> Cheers,
> Markus
> 
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
>

Received on Sunday, 19 May 2013 20:21:21 UTC