Re: Potential Formal Object from DERI over JSON-LD

On 10/19/2012 10:43 AM, Manu Sporny wrote:
> On 10/19/2012 12:04 AM, Peter F. Patel-Schneider wrote:
>> The technical issues are not as problematic as I had thought.
> Good to hear. :)
>

[...]

>> For example, LSON-LD MUST be stated as a way of writing down RDF
>> graphs
> I was hoping that "Appendix B: Relationship to Other Linked Data Formats
> and Data Models" made this clear, does it not? If not, what is the exact
> spec text you would like to see?

I want to see Section 3 defer to RDF concepts for all its base definitions.

Then I want to see something that states in a normative section that JSON-LD 
documents that have adequate context encode RDF graphs.

>
>> (with perhaps a simple generalization, although if linked data does
>> not allow bnode properties then I see no reason to allow bnode
>> properties in LSON-LD).
> Could you point to a part of the current JSON-LD spec that asserts that
> Linked Data does not allow blank-node properties? Why do you think it
> would be a good feature of a language capable of round-tripping RDF to
> not be able to express bnodes?

Huh?  I'm not requiring that JSON-LD not allow bnodes.  I'm requiring that 
JSON-LD not allow bnode properties.

>
>> JSON-LD nodes MUST be stated to be RDF nodes.  JSON-LD data values
>> MUST be stated to be RDF literals and mention both plain and datayped
>> literals.  JSON blank nodes MUST be stated to be RDF blank nodes.
> I believe that Richard is working on terminology alignment as we speak.
>
>> All the JSON ordered constructs allowed in JSON-LD MUST be stated to
>> be insignificant
> What do you mean by "JSON ordered constructs"? Do you mean the concept
> of the JSON 'array'?

Yes.
> If so, we cover this in "Section 4.9: Sets and Lists".

Arrays can occur in lots of places in JSON documents, only some of which are 
covered in 4.9, I think.

>
>> and there MUST be a test that tests this
> There are a number of tests for @set and @list. I added an issue to
> ensure that list order is maintained when round-tripping to/from RDF:
>
> https://github.com/json-ld/json-ld.org/issues/167
>
> I note that we don't have one for ensuring that a set isn't ordered, but
> how do you write that test?

You have two JSON-LD document that use arrays and that have different 
ordering, and you state that they encode the same RDF graph.
>
>> or MUST have a translation into something in RDF that is ordered, and
>> this translation should be prominent in the document.
> We support ordered arrays via @list. We support unordered sets via @set.
> We support round-tripping of both to and from RDF. All of this is
> covered in "Section 4.9: Sets and Lists" of the JSON-LD Syntax spec and
> all algorithms that could touch these data structures in the JSON-LD API.

Again, there are arrays in other places in JSON-LD.  In particular they are 
used for datasets.  Order cannot be significant there.

>
>> Examples MUST be stated to be RDF, not linked data.
> Which examples?

Well, for example, the figure that was in the previous version of the document.

> How do we state that an example is RDF (since RDF is
> just a data model)?
Huh?  You just say that this is an RDF graph.
>
>> In essence, for JSON-LD to progress in the RDF WG, it should align to
>> RDF, not linked data!
> Could you re-state this in a way that is actionable?

See my other messages.
>
>> There should be many more occurrences of "RDF" than "linked data".
> Number of times 'RDF' is mentioned in the spec: 59
> Number of times 'linked data' is mentioned    : 30

Yeah, sorry.  I used string quotes as a shorthand, when I should have said 
something like, references to RDF notions.
>
> Although, this is a bad metric for any spec, imho.


>
>> Consider the first bit of section 3.1 - it should say RDF in every
>> numbered point, except, perhaps, the last.
> We're going around in circles. That's where we started two years ago.
> Then we went to Linked Data. Then we went to the JSON-LD data model
> (after input from the RDF WG). Now you're asking us to go back to RDF in
> that section. I'd like the RDF WG group to give us clear direction on
> this, taking into account all of the /many/ discussions we've had on
> this point.
>
> -- manu
>
Well maybe the spec is going around in circles.  My view is that I'm calling 
in the marker in the previous version of the document about using RDF 
concepts.  If that cycles back closer to something in an old version, well 
then maybe the old versions were better than the version that was sent to the 
RDF WG.

peter

Received on Saturday, 20 October 2012 05:14:55 UTC