{"action":"created","issue":{"url":"https://api.github.com/repos/cdli-gh/Framework/issues/61","repository_url":"https://api.github.com/repos/cdli-gh/Framework","labels_url":"https://api.github.com/repos/cdli-gh/Framework/issues/61/labels{/name}","comments_url":"https://api.github.com/repos/cdli-gh/Framework/issues/61/comments","events_url":"https://api.github.com/repos/cdli-gh/Framework/issues/61/events","html_url":"https://github.com/cdli-gh/Framework/issues/61","id":303663119,"number":61,"title":"CDLI Framework REST API (incomplete)","user":{"login":"epageperron","id":14226547,"avatar_url":"https://avatars0.githubusercontent.com/u/14226547?v=4","gravatar_id":"","url":"https://api.github.com/users/epageperron","html_url":"https://github.com/epageperron","followers_url":"https://api.github.com/users/epageperron/followers","following_url":"https://api.github.com/users/epageperron/following{/other_user}","gists_url":"https://api.github.com/users/epageperron/gists{/gist_id}","starred_url":"https://api.github.com/users/epageperron/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/epageperron/subscriptions","organizations_url":"https://api.github.com/users/epageperron/orgs","repos_url":"https://api.github.com/users/epageperron/repos","events_url":"https://api.github.com/users/epageperron/events{/privacy}","received_events_url":"https://api.github.com/users/epageperron/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-03-08T22:56:42Z","updated_at":"2018-03-09T01:17:18Z","closed_at":null,"author_association":"OWNER","body":"## Summary\r\nWe need a solid API that can serve our data to machines and to our human interface in all required format, in the required granularity and order, including a full-fledged search service and authentication. This also means that the model layer must be tuned perfectly and the controller layer developed at least to cover the need of the API. \r\n\r\nThis issue will describe the general requirements, smaller issues can be prepared based on some of these requirements. \r\n\r\nhttps://book.cakephp.org/3.0/en/development/rest.html\r\n\r\nWe want to serve both XML and JSON, although apps will consume the JSON. Those structured outputs will be the same as the PHP objects fed to the human interface views.\r\n\r\n\r\n## Other links or relevant information\r\n\r\n<!--- What are steps we can follow to reproduce this issue? -->\r\n\r\n## Roadmap Data\r\n\r\n#### 🗓 Start Date: <!--- Accepts most date formats such as MM-DD-YYYY -->\r\n#### 🗓 Expected Date: <!--- Accepts most date formats such as MM-DD-YYYY -->\r\n#### 💪 Label: <!--- Pick the label that will dictate the color of the roadmap bar -->\r\n#### 📈 Progress (0-1): <!--- Current progress on the issue -->\r\n\r\n\r\nSee Gantt: http://cdli-dev.org/gantt/Framework/\r\n"},"comment":{"url":"https://api.github.com/repos/cdli-gh/Framework/issues/comments/371680838","html_url":"https://github.com/cdli-gh/Framework/issues/61#issuecomment-371680838","issue_url":"https://api.github.com/repos/cdli-gh/Framework/issues/61","id":371680838,"user":{"login":"epageperron","id":14226547,"avatar_url":"https://avatars0.githubusercontent.com/u/14226547?v=4","gravatar_id":"","url":"https://api.github.com/users/epageperron","html_url":"https://github.com/epageperron","followers_url":"https://api.github.com/users/epageperron/followers","following_url":"https://api.github.com/users/epageperron/following{/other_user}","gists_url":"https://api.github.com/users/epageperron/gists{/gist_id}","starred_url":"https://api.github.com/users/epageperron/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/epageperron/subscriptions","organizations_url":"https://api.github.com/users/epageperron/orgs","repos_url":"https://api.github.com/users/epageperron/repos","events_url":"https://api.github.com/users/epageperron/events{/privacy}","received_events_url":"https://api.github.com/users/epageperron/received_events","type":"User","site_admin":false},"created_at":"2018-03-09T01:17:18Z","updated_at":"2018-03-09T01:17:18Z","author_association":"OWNER","body":"About the architecture for serving LOD:\r\n\r\nHello Tom, I hope you are doing well! I have a question.. I was looking up the URIs for Pleiades and I was wondering why you chose to have the same uri for a place and for a descriptive page about that place? eg https://pleiades.stoa.org/places/579885  = a place and a page with info about that place) I want to implement uris for a bunch of things at the CDLI and I would have naturally done like what I see on Pleiades but the W3C seems to specify that one has to have an uri for the thing and then redirect from there ( so the uri doesn't resolve an to give an 200 OK, and ship the user either to a human or machine readable document, depending on the client.  (https://www.w3.org/TR/cooluris/#distinguishing …) If you could point me to what I am missing I would be very grateful. I just want to implement stable urls that would also be uris for artifacts and some of the metadata attributes. Thanks !\r\n \r\n Tom Elliott @paregorios@social.coop\r\n Émilie: hi! https://pleiades.stoa.org/places/579885  identifies a document (information resource); https://pleiades.stoa.org/places/579885#this identifies the ancient place itself (non-information resource). We use that pattern throughout. Check out the RDF: https://pleiades.stoa.org/places/579885/turtle  you’ll see <https://pleiades.stoa.org/places/579885#this > a <http://geovocab.org/spatial#Feature > and, a few lines below <https://pleiades.stoa.org/places/579885#this > foaf:primaryTopicOf <https://pleiades.stoa.org/places/579885 > that sets up the relationships between the two resources.\r\n\r\n\r\n"}}
{"actor":{"display_login":"epageperron"}}