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

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. 

>  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 Sunday, 30 June 2013 14:26:19 UTC