The subnavigation menu (above) presents links to various (hacked-up, scribbled) examples of using the DOACC dataset. The dataset is published as RDF (RDF as RDF), mostly self-documenting and there are third-party server-side and client-side libraries specifically designed for RDF data-slinging.
The dataset, the DOACC and CCY ontologies are all maintained as git repositories made publicly accessible on Github:
Working with the DOACC dataset is to work with basic facts about altcoins (facts in DOACC are described in more detail in the Facts section and the concepts behind the facts are described in the Concepts section).
Shown below is an example of a fact in DOACC --- more specifically, a triple. The syntax highlighting shows the three parts: a globally unique identifier, a globally unique relation and a value and the latter’s datatype is declared to be an XSD string.
ccs:Dd5bd8eaf-b432-440b-9502-3707aa57ff93 doacc:symbol "DOGE"^^xsd:string ;
Fortunately, such simplified and formalised statements are computationally tractable. The code below fetches data from a server, identifies all the different protection schemes mentioned in teh dataset and prints to the console any skos:prefLabel values that it can find.
Handling the retrieval and processing via a callback is a necessary evil on the client side in order that the entire dataset is fully retrieved before processing begins. Server-side processing is less demanding of the user’s machine and the results can also be usefully cached for faster response.
One of the under-appreciated delights of working with RDF sources that draw from the same vocabulary is the ability to just (literally) add another set of statements. For example, we could reach out and pick up “in danger of being delisted” from the Bittrex API “getmarkets” call.
The call returns data of the form:
The information pertains to the coin whose doacc:name is "Whitecoin"^^xsd:string and whose doacc:symbol is "XWC"^^xsd:string, i.e. doacc:D3c844f6a-04ec-4eb0-a1df-8a096b8c76f2. The ^^xsd:string construction specifies the datatype of the information. The information is added in the form of new statements about the coin:
doacc:D3c844f6a-04ec-4eb0-a1df-8a096b8c76f2 doacc:endangered "True"^^xsd:boolean ; doacc:firstlisted "2014-04-14T00:00:00"^^xsd:dateTimeStamp .
The statements can be straightforwardly added to the existing DOACC graph either programatically or by reading a saved file of statements.
Although neither of doacc:endangered and doacc:firstlisted appears in the DOACC ontology, that’s not a barrier to private/informal use. It only starts to become an issue when you either want to publish your statements or want to perform reasoning on the dataset. One solution is to add the relations to a local copy of the ontology, another solution would be to lobby for the inclusion of the relations in the “official” DOACC ontology or simply submit a PR.
There are a few altcoins where the available Linux/Win/OSX binaries have been upgraded to v2.0 but the source code in the Github repository remains unchanged at v1.0. In such cases, the DOACC data for those coins is almost certainly partially and indeterminately outdated incorrect. In other cases, coin devs have made changes to the parameters, hash algo, logo, name, protection scheme --- much of which is recorded in the source but the corresponding DOACC statements have yet to be updated are incorrect. Plans are afoot to programatically check the veracity of the DOACC statements by cross-referencing the actual repository code.