Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
Components
==========
This is a rough sketch of the involved components of this project.
Look at `componets.png` for a little illustration of the involved
components.
`Collector`
-----------
* Given some source of ULO/RDF files (Git repository, HTTP server,
local file system), the `Collector` processes/cleans up these files
and forwards them to the `Importer`.
* Implement core functionality as library with command line and web
front end.
* Can be implemented in any language. I'll probably pick Go as I'm
pretty productive in it.
`Harvester`
-----------
* Low Priority. Just an idea I had. But it might go against the idea
of using MathHub as a centralized place for data.
* Converts arbitrary source data (e.g. Coq) to ULO/RDF.
* The generated RDF is *volatile*, it does not need to be stored to
any repository. Rather it is directly forwarded to a `Collector`.
* I'm not sure if this makes any sense actually as it might be
difficult to track changes and so on.
* Can be implemented in any language that makes sense for the given
source format.
`Importer`
----------
* Essentially a wrapper around a database. Written in the language
that best fits the database. In particular, GraphDB only has good
Java/JVM programming support.
* Accessed w/ a simple file upload API. You upload a file and get a
path returned that shows you the current state of the import.
`Endpoint`
----------
* Again, like the `Importer`, this is a wrapper around the database.
* Might be optional if applications accesses the database directly.
Certainly when it comes to querying I will not introduce a custom API
as querying is a problem way way more complicated than a simple
import.