IRI templates #108
Description
During WWW2012 in a number of conversations the need for IRI templates to upgrade legacy JSON documents to JSON-LD came up. The reason is that in some scenarios IRI are neither already in absolute form nor they can be interpreted as relative IRIs. To transform those IRIs to full, absolute IRIs, IRI templates would be needed.
This is the case in many of the current REST APIs. Let's look at an exemplary representation in Twitter's REST API:
{
"created_at": "Wed Apr 18 07:11:19 +0000 2012",
"id": 192510603515015170,
"id_str": "192510603515015168",
"text": "@vrandezo Do you think so as well? Don't know if you have been at my talk about #jsonld yesterday!? I think quite the opposite is the case..",
"source": "web",
"truncated": false,
"in_reply_to_status_id": 191908918031695870,
"in_reply_to_status_id_str": "191908918031695872",
"in_reply_to_user_id": 16511554,
"in_reply_to_user_id_str": "16511554",
"in_reply_to_screen_name": "vrandezo",
...
}
The in_reply_to_* are actually IRIs, but would need an IRI template to be correctly interpreted:
"in_reply_to_status_id_str": "191908918031695872", ---> http://api.twitter.com/1/statuses/show/{value}.json
"in_reply_to_user_id_str": "16511554", --> http://api.twitter.com/1/users/show/{value}.json
"in_reply_to_screen_name": "vrandezo", --> https://api.twitter.com/1/users/show.json?screen_name={value}
To be able to support such legacy JSON we would need to introduce support for IRI templates. On the other hand, @antoniogarrote's JSON-LD macros already support this use case and seem to be the better place for such functionality. We might also want to consider to include the JSON-LD macros into the official API or just include a pointer to it in the spec/the website.
@osma you were one of the persons I spoke to about this, maybe you would like to add some more information about your specific use case!?