There are two main ontologies in use. They provide definitions of the terms used in statements about cryptocurrencies.
DOACC is for general statements about algo, pow/pos, ico/no ico, premine, etc. and is based on concepts used by developers in online forum announcements, primarily bitcointalk. One altcoin advertises “algo: x11”, another mounts a crowdfunding ICO, yet another announces “PoS 2.0”. All three are surface features of a deeper conceptual separation reflecting different approaches taken to i) protecting the public ledger, ii) distributing the coins and iii) choice of PoW scheme.
And so the DOACC vocabulary includes general altcoin concepts such as “protection scheme”, “distribution scheme”, and “proof-of-work scheme”.
CCY is for making statements of technical detail; blockhash, scriptSig, txin/out, etc.
The CCY vocabulary is an expansion and adaptation of Melvin Carvalho’s CC ontology. The additions are mainly for making additional statements about i) blockchain contents and ii) the values bound to a range of program variables that effectively profile the coin.
The submenu navigation on this page offers links to descriptions of the more salient concepts. The DOACC and CCY OWL ontology pages present all of the concepts, their properties and how they are used to describe an altcoin and its features.
The remainder of this introduction attempts to cast illumination from several different angles, emphasising the essential utility of the approach.
ccs:Dd5bd8eaf-b432-440b-9502-3707aa57ff93 a doacc:Cryptocurrency ; doacc:block-reward "500000"^^xsd:string ; doacc:block-time 60 ; doacc:coin ccs:D5e6e149c-2bf3-48e0-a8ab-4ca0a1f424a4 ; doacc:comment "supported"^^xsd:string ; doacc:date-founded "2013-12-08"^^xsd:date ; doacc:distribution-scheme ccs:Dc10c93fb-f7ec-40cd-a06e-7890686f6ef8 doacc:expiration "listed"@en ; doacc:image "dogecoin_doge.png"^^xsd:anyURI ; doacc:incept "2013-12"^^xsd:string ; doacc:pow ccs:D338257f8-402f-4c76-969b-6fc041d52e40 ; doacc:protection-scheme ccs:D451a49d8-c9e7-46e5-8b8d-bcbe16f75c24 ; doacc:protocol ccs:Db8ade99f-11f1-476b-ae77-03c005c1bb66 ; doacc:source <https://github.com/dogecoin/dogecoin> ; doacc:symbol "DOGE"^^xsd:string ; doacc:total-coins "100000000000"^^xsd:string ; doacc:website "http://dogecoin.com/"^^xsd:anyURI ; rdfs:comment "Scrypt-based, re-target every 4 hours, variable block reward, 100 billion total coins."^^xsd:string ; skos:prefLabel "Dogecoin"@en .
It's a little more than just a diagram, it’s a hand-executed illustration of how facts are modelled in an RDF graph.
Here’re the actual boxes and arrows for DOACC’s model of Dogecoin, as rendered by the machine.
Facts can be shuffled around and re-presented. The following graph contains three statements of fact about Namecoin, Litecoin and Dogecoin respectively, each stating that the entity is a cryptocurrency:
This puts us in a strong position with respect to precise references. Each individual coin has its own unique UUID identifier. In addition, rdf:type is also a unique reference. And the same is true of our very own doacc:Cryptocurrency.
There is no ambiguity or vagueness about the facts, every concept used to express them is clearly identified and defined, e.g. the W3 definition of rdf:type
“A triple of the form: R rdf:type C states that C is an instance of rdfs:Class and R is an instance of C.”
It’s all very carefully done, no loose ends, no vague, hand-wavy stuff, just precise, formal definitions which make sense to both humans and machines, in their own respective fashion.
It is the associated ontology which carries the above-mentioned definitions of the terms which are used in the “domain of discourse” (in this instance, cryptocurrency).
For example, the concept doacc:date-founded is defined as follows:
or, in a hopefully more readable serialization:
In addition to the basic (language-specific) labels and text strings, the definition asserts that the relation is a owl:DatatypeProperty of a doacc:Cryptocurrency whose value is a rdf:Literal (a string).
It’s an owl:DatatypeProperty because the value is a literal datum point rather than a pointer to an instance of say, a doacc:ProtectionScheme because if it were, the relation would instead have to be declared to be a owl:ObjecType with a specified range of doacc:ProtectionScheme).
The purpose of all this is to enable the machine to process unaided what it reads in the ontology and to be able to look up those definitions when they are referenced in statements about individual coins .e.g.:
The p2p protocol used by Bitcoin is also used by nearly all of the “1st gen” altcoins, it’s a defining characteristic. However, “next generation” cryptocurrencies typically (but not always) use a entirely different protocol and only a relatively few of the nextgens use another nextgen’s protocol (cryptonote, nxt, etc.), it’s almost an identifying characteristic. At the most recent count, there have been 35 different cryptocurrency protocols developed thus far, several are primarily asset-issuance vehicles.
2ndgen alts are sufficiently different to 1stgen alts to need an ontology of their own and that is very clearly an ecumenical matter best devolved to the development team.
Not recorded as the features / properties are idiosyncratic to the specific asset issuance vehicle.