@id vs. url

[elf-pavlik]

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 schemaorg/schemaorg#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: solid/solid-spec#20 (comment)

@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...

[ahdinosaur]

@elf-pavlik thanks for the overview on this. with some reflection, you're right that we should use @id to reference our API endpoints, while url references more of a "homepage". combining the two only adds unnecessary complexity. i'll update my examples appropriately, cheers.

[fosterlynn]

@elf-pavlik @ahdinosaur I agree.

[fosterlynn]

@elf-pavlik this is open and also on the meeting agenda.... wondering if there are any open questions on this one..... ?

[elf-pavlik]

@fosterlynn @ahdinosaur unless you use HTTP 303 for URIs which you use as value of @id, I would recommend adding to all of them #id at the end, as in: https://github.com/valueflows/resource/blob/master/examples/valueflows.jsonld#L9

More background (which I don't necessary suggest to dive into) https://www.w3.org/wiki/HttpRange14Webography

Myself I will still decide if I will also add #id to data which I publish or experiment more with HTTP 303 approach 😨

[fosterlynn]

Myself I will still decide if I will also add #id to data which I publish or experiment more with HTTP 303 approach 😨

@elf-pavlik If you're fearful, then I'm terrified!! 😄

Can I leave this to you guys? (I think I am now just returning empty result when the @id doesn't find anything in the database. I will change it when we decide what is best.)

[almereyda]

Reading through this, I just remember having read about naming conventions in hypermedia APIs yesterday. Of course this is not of concern here anymore, as @id is being used for the Hypertext/-media References right now. But we can keep it in mind for future occurences of hrefs.

for some reason decided against the universally accepted href or Hypertext Reference property, instead opting to use url or the uniform resource locator as the link URI identifier:

Personally, I would recommend staying with the uniform href attribute as it denotes a reference to a hypertext link and is not as exclusive as an URL- which is not (although it commonly is) to be confused with URI. But you can read more on that here.

via

[almereyda]

We have moved the ValueFlows organization from GitHub to https://lab.allmende.io/valueflows.

This issue has been closed here, and all further discussion on this issue can be done at

https://lab.allmende.io/valueflows/valueflows/-/issues/45.

If you have not done so, you are very welcome to register at https://lab.allmende.io and join the ValueFlows organization there.