Closed PonteIneptique closed 9 months ago
Fixed the typo in the title.
sounds like we need to do this
(These are my notes from looking into implementing this)
From reading the documentation, it's clear that we'll need a DTS ontology, expressed in JSON-LD, to which https://w3id.org/dts/api# redirects.
All DTS properties will need to be defined, and I strongly suspect we'll want to subclass hydra:Collection to define dts:Collection and dts:Navigation classes. We'll need a dts:Document class too.
We should probably host static JSON-LD documentation resolvable via a w3id URL (https://w3id.org/dts/doc ?) that's globally applicable. Implementations would obviously be free to define their own documentation at their own URI as well. The alternative is to provide a template and insist that implementers do it themselves.
If this all sounds reasonable, I will get to work on it. I'd hoped this was a fairly small task I could knock out in a day or two, but it's medium sized, so it may have to wait until things slow down over the holiday break.
Sounds good to me :)
Sounds good to me too.
During the RC Workshop in Duke, and given the current situation of Hydra, it has been decided to move away from their vocabulary, while acknowledging our inspiration from it. As a consequence, this issue does not stand anymore.
I looked at the Hydra doc for another API (a service API mostly but I wanted to document correctly each variation of the service...) : it looks like we are missing quite a bit of the Hydra specs, namely the documentation that should be accessible ( http://www.hydra-cg.com/spec/latest/core/#documenting-a-web-api )
It seems necessary, and if we look at the playground using any DTS example, it does not work : http://www.markus-lanthaler.com/hydra/console/?url=http://www.markus-lanthaler.com/hydra/event-api/