Re: HTTP POST and @subject IRI

On Mon, Nov 7, 2011 at 6:58 AM, Dave Longley <> 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,

Received on Monday, 7 November 2011 07:48:40 UTC