Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
General Starting Introduction To The Project #2
As the first students expressed interest in the project, I write here some more insights about the things at this very early stage.
The objective for this project is to create a demo Web API implementing the HYDRA draft, that is an RDF-based framework. The entities defined in the specs are meant to describe the structure and usage of a generic Web API, to let an HYDRA-enabled ("intelligent" or "smart") client to connect to the API's entrypoint and automatically find out where and how to find the needed data.
In this scenario the layers involved are:
The objective is generally to let different HYDRA-enabled clients to exchange data each other. These clients can be running on any kind of machine, but the focus for this automation are IoT (connected) devices (industrial or consumer or research).
Different concepts and classes are involved. An RDF domain has to be defined for the metadata exchange to work.
To make the demo interesting I suggested we should leverage space exploration and astronomy, so the graph can be based on these vocabularies: https://github.com/chronos-pramantha/RDFvocab/blob/master/ld%2Bjson/Spacecraft.json I can suggest possible operations to be requested to the API. Resources are well connected to popular repositories, so we can reach a great amount of knowledge without storing too much.
Please enlist questions and comments below.
PS. the stack to be used has to be decided yet. We should tend to use a full-Python implementation, except for the lower layer where a graph database is required, we are free to experiment so we can suggest anything in the beginning. At first impression I would avoid Triple Stores and try to use a Graph Database or try to prototype something with Apache TinkerPop or also Spark GraphX, to gain in flexibility to switch to different solutions. At first I would prefer to not get concerned into stability and scalability but just try to reach the first working tool, to let the things to be iterated.
UPDATE: To have a better insight, one of the proposed design is described at #3
UPDATE: Gitter chat available here
UPDATE: Check also this architectural proposal
If I may, I would recommend using rdflib, there is also Apache Jena which is good, however they do not provide a Python API. Rdflib has a learning curve, but all in all it is much more powerful than any other tools that I have used.
@Mec-iS suggeseted that I post this here for better feedback
I have been going through the Hydra Proposal for the last couple of days and have been trying to understand what both Hydrus and Hydra is.
Here is all that I have understood:
Hydra is an XML namespace that uses RDF and provides tags to define Linked Data in a Graph Database. Hydra also allows us to define API Documentation along with other types of data, that would allow us to expose server APIs for clients to exchange data with servers without the need of clients to use only hyperlinks.
Hydrus is a python based web app, that is used to demonstrate the capabilities of Hydra using a Space Exploration example.
This is similar to the example given on github, where a user requests the distance between Mars and Earth.
Please let me know if what I have understood is correct or not.
If possible, I would also like to know what more I can do to work/start working on this project for GSoC.
@chrizandr, you wrote
that's not stricly correct, as Hydra has no (direct) relation to XML. Hydra is a vocabulary, i.e. a set of IRIs (in RDF/Linked Data, we use IRIs to identify any thing of interest: classes, attributes and relations, instances, datatypes...).
More generally, Hydra describes the available HTTP operations and what they mean/do. Dereferencing a hyperlink is just one particular HTTP operation (GET), although indeed it is the most common.
But overall, I think you git it right :)
There are different possible designs that I am proposing. I would like to discuss with you all students and mentors which one is the most interesting and viable:
I would like to have your opinion about which one (or both?) can be the best one to fully express and test Hydra-features. I would be happy to see both working but if I need to choose I would say no.2 because its domain is much more defined and limited, that is a good thing for a test.
Keep studying the spec and asking questions (here or writing to the public HYDRA list firstname.lastname@example.org introducing yourself). Start studying how Levanzo implemented a server in Clojure to serve an HYDRA API, take as much inspiration as possible to develop a similar server in Python.