- From: Niklas Lindström <lindstream@gmail.com>
- Date: Mon, 7 Nov 2011 08:47:43 +0100
- To: Dave Longley <dlongley@digitalbazaar.com>
- Cc: public-linked-json@w3.org
On Mon, Nov 7, 2011 at 6:58 AM, Dave Longley <dlongley@digitalbazaar.com> wrote: > On 11/06/2011 09:20 PM, Markus Lanthaler wrote: >>> >>> The service is responsible for how it interprets its input; it could >>> very well be expecting to receive a blank node and then provide it with >>> a global identifier. In fact, this is likely how a service that assigns >>> global names (IRIs) to blank nodes would work. >> >> I agree that the service is responsible for how it interprets its inputs, >> but how do you distinguish between a blank node that should remain a blank >> node and a blank node that should be converted to an IRI? > > You don't. The service that was described creates a new resource with the > content you posted at a URL of the server's choosing when you post to it. So > it doesn't matter what you put in the @subject field, really. The server > will decide what goes there. It just seemed to me that omitting it entirely > made the most sense (or may for a lot of use cases). > >>> If the service is unable to alter the input before it is stored for >>> later retrieval, then I can see using the other solution (@subject: ""), >>> but this actually seems a lot messier to me. I would prefer to retrieve >>> an object with a fully-populated @subject, and not have to rely on >>> storing information about where I retrieved it in some separate state >>> container. >> >> Gregg's suggestion doesn't necessarily implies that the JSON-LD document >> stays exactly the same, it just implies that the information contained in >> it >> stays the same. By using a relative IRI in a POST you are able to express >> that it's up to the server to create an absolute IRI. Of course the server >> is free to rewrite the JSON-LD document to contain the absolute IRI when >> retrieved later. > > I don't see how this is any different from the blank node case. By omitting > a @subject, that can inform the server that it is free to rewrite the > JSON-LD document to contain the absolute IRI of the location where it > chooses to store the resource. It seems to me that either solution is > reasonable. How about using '{"@subject": null, ...}' in this case? Since 'null' is undefined (and hence this should not imply a blank node AFAIK), it might be a reasonable approach? (Albeit a bit application-specific perhaps. I suppose 'null' could represent an unbound variable.) Best regards, Niklas
Received on Monday, 7 November 2011 07:48:40 UTC