epageperron
commented
6 years ago About the architecture for serving LOD:
Hello 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 !
Tom Elliott @paregorios@social.coop É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.
attackpiggy
Summary
We 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.
This issue will describe the general requirements, smaller issues can be prepared based on some of these requirements.
https://book.cakephp.org/3.0/en/development/rest.html
We 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.
Other links or relevant information
Output types : (for all entities, cat data, text, annotations, etc)
Output files (not to be processed but to download generally by humans and in extra of the files above) : Catalogue data :
For authentication :
Roadmap Data
🗓 Start Date:
🗓 Expected Date:
💪 Label:
📈 Progress (0-1):
See Gantt: http://cdli-dev.org/gantt/Framework/