Linked Data
One of the major benefits of using an attestation registry such as Verax for storing data, is that it consolidates public data points from various dApps into a unified on-chain datastore. This reduces the proliferation of fragmented data silos, with dApps using their own individual on-chain storage.
Using a consolidated data store makes it much easier to index the data and derive valuable insights. However, there remains a challenge when we start composing attestations from multiple different sources that each have their own naming conventions and semantic definitions for the attestation data.
To illustrate this with an example, consider an attestation for a person.
Attestation from Issuer A:
Attestation from Issuer B:
We don't know if those attestations are using the property "name" in the same way, or "address" in the same way, etc. This introduces ambiguity, which creates friction for the developer that is trying to consume and compose attestations from different sources.
To make matters worse, attestation issuers may use different naming conventions when referring to the same thing. Consider the two following examples:
Attestation from Issuer A:
Attestation from Issuer B:
Even if both attestation issuers are using fields that have the same semantic meaning, one of them is using camelCase while the other is using under_scores. This becomes a major headache for consumers of the attestations, as they have to account for the naming conventions of different issuers.
Contexts to the rescue
Let's look at the example above, but this time both attestations are based on schemas that have the same context value:
Attestation from Issuer A:
Attestation from Issuer B:
Now both issuers are using the same naming convention, which makes it way easier to consume and compose the attestations.
Custom Naming Conventions
Of course, the example above does not always apply in practical situations. Often, an attestation issuer already has an established naming convention, and it is not feasible for them to change this naming convention to align with other shared vocabularies. That's OK, because we can use custom contexts!
Custom contexts are based on a custom schema that allows an issuer to create an attestation, which links their custom fields to properties in a shared vocabulary. Let's take the example above, but this time the context
property in the schema metadata points to an attestation that looks like this:
Shared Vocabularies
Many other ontologies are available, and you can discover ones that may be better suited to your specific use case using the following directories:
Conclusion
Using shared vocabularies / ontologies is a powerful way for dApps to allow easy access to their data, making it much more likely for other dApp developers to consume those attestations. Adopting shared ontologies will allow us to develop semantically rich on-chain reputations and will allow for sophisticated permissionless discoverability of services and dApps that drives real value to users.
Last updated