Re: Input needed from RDF group on JSON-LD skolemization

[Moving to public-linked-json@w3.org]

Response to one more comment from Pat, which I hadn't before noticed . . .

On 06/30/2013 10:25 AM, Pat Hayes wrote:
>
> On Jun 27, 2013, at 10:19 PM, David Booth wrote:
>
>> [Copying public archive www-archive.w3.org for lack of a better
>> option]
>>
>> PROBLEM SUMMARY
>>
>> GOAL: Any two JSON-LD-compliant parsers should produce the exact
>> same RDF triples when parsing the same JSON-LD document, except for
>> blank node labels and (possibly) datatype conversions.
>>
>> CURRENT PROBLEM: JSON-LD  is intended to be a concrete RDF syntax,
>> but the JSON-LD data model has some extensions to the RDF data
>> model, and this causes some non-determinism and/or important
>> information loss when interpreting JSON-LD as RDF.
>
> Wait. There are two issues getting muddled here. Yes, there can be
> information loss in JSON-LD ==> RDF. No, it does not follow that the
> mapping is nondeterministic or ambiguous. So information loss does
> not compromise the GOAL as stated.
>
> Pat .
>> At present, the results of JSON-LD-compliant parsing of a JSON-LD
>> document to produce a set of RDF triples is non-deterministic
>> because JSON-LD allows blank node predicates and RDF does not.
>
> That is a nonsequiteur. There is a perfectly deterministic algorithm
> to map JSON-LD into RDF, with information loss. Option (a) below, for
> example.

No, option 1 below is a **potential solution** to the problem.  It is 
not what the spec currently says.  The spec is currently 
non-deterministic.  It is non-deterministic because there is a mismatch 
between what the mapping algorithm produces and what RDF allows, and the 
spec does not specify how that mismatch must be resolved -- leaving it 
up to the parser to decide.  That means that two JSON-LD-compliant 
parsers may not produce the same RDF triples (aside from blank node 
labels and (possibly) datatype conversions) when parsing the same 
JSON-LD document.  That's a problem, and that's what I am trying to 
address.  Does that clarification help?

David

>
>> The JSON-LD specification currently suggests three potential
>> solutions but does not mandate one of them: (a) discard triples
>> that contain blank node predicates; (b) retain triples that contain
>> blank node predicates; or (c) skolemize blank nodes that are used
>> in the predicate position.
>>
>>
>> RANGE OF POTENTIAL SOLUTIONS
>>
>> 1. Change JSON-LD to prohibit JSON-LD blank nodes in positions
>> where the RDF interpretation of JSON-LD would cause them to be
>> mapped to illegal RDF blank nodes.
>>
>> Pros: Easy enough spec change.
>>
>> Cons: Loss of JSON-LD functionality?  (Is there an important use
>> case for having blank nodes in predicate positions in JSON-LD?)
>>
>> My comments: This seems to me like the best available option.
>>
>>
>> 2. Change RDF to permit blank nodes as predicates.
>>
>> Pros: Avoids information loss.
>>
>> Cons: Not possible in the current RDF working group, because it is
>> specifically specified in the charter as being out of scope:
>> http://www.w3.org/2011/01/rdf-wg-charter "Some features are
>> explicitly out of scope for the Working Group . . . Removing
>> current restrictions in the RDF model (e.g., . . . blank nodes as
>> predicates"
>>
>> My comments: To my mind, this would have been a second-best option
>> if it were available.
>>
>>
>> 3. Change the JSON-LD-to-RDF-model mapping to specify that illegal
>> triples are discarded.
>>
>> Pros: Easy change to the JSON-LD spec.
>>
>> Cons: Significant information loss when interpreting JSON-LD as
>> RDF.
>>
>> My comments: Not acceptable, due to the information loss.
>>
>>
>> 4. Require skolemization of bnodes that appear in the predicate
>> positiont.   (Note that if skolemization of a bnode is performed,
>> it must be performed uniformly on all instance of that bnode that
>> arise from that JSON-LD document.)  RDF-standards-based
>> round-trippable skolemization would permit round-tripping of the
>> skolemized bnodes back to the original JSON-LD even if the return
>> trip is performed by a different party.
>>
>> Pros: Avoids information loss.
>>
>> Cons: (a) More complex than other options; (b) To avoid possible
>> URI clashes, the skolemizer would need a user-specific URI prefix
>> as a parameter, such as
>> http://example.com/.well-known/genid/alice/
>>
>> My comments: Complex, but acceptable.
>>
>>
>> Are there other options or pros/cons that I did not list?  Which
>> options would be preferable, acceptable or not acceptable to you?
>>
>> I suggest adopting #1, but also adding a note to the JSON-LD spec
>> that recommends that parsers offer an *option* (disabled by
>> default) to retain triples with a blank node predicate.
>>
>> Thanks, David
>>
>>
>
> ------------------------------------------------------------ IHMC
> (850)434 8903 or (650)494 3973 40 South Alcaniz St.
> (850)202 4416   office Pensacola                            (850)202
> 4440   fax FL 32502                              (850)291 0667
> mobile phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>
>
>

Received on Monday, 1 July 2013 21:14:32 UTC