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

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

On 07/01/2013 10:33 AM, Markus Lanthaler wrote:
> On Monday, July 01, 2013 4:07 PM, David Booth wrote:
>> On 07/01/2013 05:41 AM, Markus Lanthaler wrote:
>>> You seem to suggest that we remove a mechanism that allows to map
>>> data to something close enough to RDF that some RDF systems already
>>> support.
>>
>> 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?

>
>
>>> IMO, that's also information loss.
>>
>> I would consider it a feature loss rather than information loss, since a
>> user could still represent the information.  The user would just have to
>> use a URI instead of a blank node.   Is there an important use case for
>> permitting blank nodes in the JSON-LD position that would map them to
>> blank node predicates in RDF?  If so, what is it?
>
> If you look at JSON, you could say that all properties are effectively
> bnodes because they have just local meaning. Sometimes you wanna preserve
> that data when transforming the JSON-LD using one of the transformation
> algorithms.
>
> Another use case is, for instance, if just wanna extract nodes of a certain
> type. Let's say all persons that occur in a graph. In that case it is enough
> to map the properties you are interested in to IRIs and threat all the
> others as blank node predicates.
>
> 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.  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).

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?

David

Received on Monday, 1 July 2013 22:22:20 UTC