Re: Blank nodes as predicates [was Re: Input needed from RDF group on JSON-LD skolemization]

On 07/13/2013 02:23 PM, Markus Lanthaler wrote:
> On Saturday, July 13, 2013 12:41 AM, David Booth wrote:
>> On 07/12/2013 06:18 AM, Markus Lanthaler wrote:
>>> On Friday, July 12, 2013 5:00 AM, David Booth wrote:
>>>> On 07/10/2013 10:18 AM, Markus Lanthaler wrote:
>>>>> What if I would have some (out-of-band) knowledge that tells me
>>>>> that
>>>>>      _:b2 rdfs:subPropertyOf
> <> .
>>>>>      _:b2 rdfs:subPropertyOf
> <> .
>>>> It is not possible in RDF to do that, because the blank node label _:b2
>>>> has no meaning outside of the original graph.  There is no way, from
>>>> outside of that graph, to refer to _:b2 by name.  It has no name
>>>> outside of the original graph.
>>> Since I am the client and I have out-of-band knowledge and I am the one
>>> processing the graph I can simply inject that knowledge into the graph
>>> before processing it. So it's certainly possible. How could someone
> possibly
>>> prevent that?
>> If you are using standard tools then there is no way to inject a
>> statement about _:b2 into the graph before processing it, because _:b2
>> has no name that you can reference.  A standard JSON-LD extended-RDF
>> parser would take JSON-LD as input and produce extended RDF like this:
>>         ...
>>         [] [] true .
>>         [] [] false .
> In JSON-LD there's no way to have a property mapped to an unlabeled blank
> node. If you map it to a blank node, it will be mapped to a blank node
> identifier.
>> The only way, using standard tools, that you could inject the above
>> out-of-band knowledge would be to modify the *original* JSON document to
>> inject additional JSON properties that would end up being converted to
>> RDF using the same blank nodes.
> Why's that a problem?
>> In other words, you would have to: (a)
>> parse the document as pure JSON; (b) augment that JSON with your
>> out-of-band information;> (c) serialize back to JSON; and finally (d)
>> re-parse the result using a JSON-LD extended-RDF parser.
> That's trivial in every programming language I know

And (a) is often done regardless. All current JSON-LD processor 
implementations (and for the foreseeable future) reuse existing "pure 
JSON" parsers before doing anything else. (c) would be unnecessary 
because the JSON-LD API accepts pre-parsed objects. So the steps would 
actually be: 1. parse JSON, 2. add out-of-band information, 3. run the 
result through a JSON-LD extended-RDF processor. In normal operation, 
you may already be doing 1 and 3. So, it may be common that the only 
extra step is adding the out-of-band information. In any event, this 
isn't about something being an elegant solution, it's about making it 
possible for authors to more easily transition so that they don't opt to 
avoid transitioning entirely.

>> That does not sound like an elegant solution.  That sounds like a crude
>> hack.
> So?
> --
> Markus Lanthaler
> @markuslanthaler

Dave Longley
Digital Bazaar, Inc.

Received on Saturday, 13 July 2013 19:55:00 UTC