@id vs. url
I should clarify my current use of @id
vs url
Many platforms nowadays separate their API and web pages eg.
Data | Presentation |
---|---|
http://graph.facebook.com/ | http://facebook.com/ |
https://api.github.com/ | https://github.com/ |
https://api.twitter.com/ | https://twitter.com/ |
Besides that Linked Data deals with an issue, which many people find very tricky httpRange-14
Schema.org tends to use url and still doesn't make it clear how it relates to @id
https://github.com/schemaorg/schemaorg/issues/410
As you can find in examples elf-pavlik & hackers4peace, I use graph. subdomain for @id
(~API) and top level domains for url. This way people can follow url and use standard browser which requests text/html. While 'smart clients' can follow @id
and content negotiate for application/ld+json or text/turtle. In my case I will use 'httpRange-14' compliant pattern and use HTTP 303 redirect from @id
to url for text/html, similar @id
+ ".jsonld" for application/ld+json and @id
+ ".ttl" for text/turtle
I will provide more explainations soon, but I see interesting possibility of using this pattern. In practice top level domain will act as one of rendering proxies to present data stored on graph. subdomain. Some more explanations available here: https://github.com/solid/solid-spec/issues/20#issuecomment-145338047
@ahdinosaur do you plan to support content negotiation application/ld+json (MUST) and text/turtle (MAY) for values which you use for @id
?
- https://github.com/valueflows/agent/blob/master/examples/mikey.jsonld#L5
- https://github.com/valueflows/agent/blob/master/examples/craftworks.jsonld#L5
More details to come...