Re: HTTP POST and @subject IRI

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.

-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Monday, 7 November 2011 05:58:27 UTC