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

Hi Markus,

I think I'm understanding better what you mean.  I hope you can bear 
with me if I've still misunderstood.  More below . . .

On 07/02/2013 04:40 AM, Markus Lanthaler wrote:
> On Tuesday, July 02, 2013 12:22 AM, David Booth wrote:
>> On 07/01/2013 10:33 AM, Markus Lanthaler wrote:
>>> On Monday, July 01, 2013 4:07 PM, David Booth wrote:
>>>> Yes, I am suggesting that the feature of permitting blank nodes in
>>>> that JSON-LD position -- the position that would result in blank
>>>> predicates
>>>> in the RDF model -- be removed.   Users would instead be required to
>>>> use URIs in those cases instead of blank nodes.
>>>
>>> Or, more likely, they would just not map those properties at all and the
>>> data would be lost due to that.
>>
>> I was referring to the JSON-LD document authors.  Do you mean that you
>> think authors would would only include those data elements in their
>> JSON-LD if they could use blank node predicates?
>
> Yes
>
>
>>> For example, you may have a JSON representation of a blog post and
>>> all its comments:
>>>
>>> ...
>>> comments: [
>>>     {
>>>       text: ...
>>>       author:
>>>         {
>>>           name: ...
>>>           .. other properties you are interested in ...
>>>         }
>>>     }
>>> ]
>>>
>>> You could extract the all persons by mapping name to foaf:name etc.
>>> and all other properties to blank nodes:
>>>
>>> {
>>>     "@context": {
>>>       "@vocab": "_:",
>>>       "name": "http://xmlns.com/foaf/0.1/name",
>>>       ...
>>>     }
>>> }
>>>
>>> and then just filter out the nodes which have a foaf:name.
>>>
>>> If you wouldn't map all other properties to blank nodes you wouldn't get
> any
>>> triples at all as we ignore unmapped properties (and their complete
>>> subtrees).
>>
>> AFAICT we seem to be talking about different things.  I am trying to
>> address the problem of what should be the standard RDF interpretation of
>> a JSON-LD document -- not what a particular client might choose to use
>> or ignore from that document.
>
> I don't think so. It may be the author of the document who decides to just
> expose parts of a JSON-LD document as "RDF". I anticipate that there will be
> quite some APIs that will gradually transform the JSON APIs to JSON-LD APIs.
> Without allowing bnode-predicates this becomes considerably harder to do as
> the example illustrates.

Okay, I think I now see what you mean.  You are talking about a 
situation in which an author is incrementally migrating from JSON to 
JSON-LD.  If that is correct, then I can see why the author may not want 
to take the time to look up and specify an appropriate context URI for 
each property.

But why couldn't the author just treat the properties as relative URIs 
instead of blank nodes?  I.e., why not do something like this instead:

 >>> {
 >>>     "@context": {
 >>>       "@vocab": "http://example/",
 >>>       "name": "http://xmlns.com/foaf/0.1/name",
 >>>       ...
 >>>     }
 >>> }

or even something like this, making use of the base URI:

 >>> {
 >>>     "@context": {
 >>>       "@vocab": "",
 >>>       "name": "http://xmlns.com/foaf/0.1/name",
 >>>       ...
 >>>     }
 >>> }

Wouldn't something like that work?  I don't yet see why specifically 
blank nodes would be needed for this.

>
>
>> Any client may ignore any information it
>> wants, but it is important that different JSON-LD standards-compliant
>> parsers, both parsing the same JSON-LD document in an attempt to obtain
>> the JSON-LD standards-compliant RDF interpretation of that JSON-LD
>> document, should obtain the same set of RDF triples (except for blank
>> node labels and possibly data type conversion).
>
> And that's the case right now. Every compliant JSON-LD parser is required to
> produce exactly the same generalized RDF dataset.

It is also good to have JSON-LD parsers produce the same *extended* RDF 
datasets if the user chooses to get extended RDF.  But the case that I 
am trying to address is the case where the user expects *standard* RDF 
-- ensuring that the mapping is deterministic with minimal information loss.

>
>
>> One possible way to achieve this is for the JSON-LD spec to disallow
>> blank nodes in positions that would be mapped to RDF predicates.  I
>> believe this means disallowing blank nodes as keys.  Instead, a user
>> would have to use a relative URI, a Compact URI or an absolute URI.
>>
>> Are there any important use cases that would be significantly impacted
>> by this change?
>
> Didn't I just answer that question?

Yes, I think I've now understood better what you meant.  :)

David

Received on Tuesday, 2 July 2013 17:01:52 UTC