DIP-100

words

Background

In DCoSL, data will frequently be represented as a graph, with nodes and edges. Each node represents a piece of data and can be in any format; it could be a file in JSON, XML, CSV, JPG, binary, etc; could be a piece of code; could even represent something not digital, like a book. All it needs is some form of unique identifier or pointer to the data.

In DCoSL, by convention we will rely heavily on the JSON data format, given that JSON is so widely used in many p2p applications.

Definition

A word is a node which represents a single object in JSON.

Conventions

• each word has the top-level property: wordData
• each word optionally has a top-level property: metaData
• Within any graph, wordData.slug should be unique and may be used as a unique identifier. Additional unique identifiers may also be used but are not required.
• Cryptographic mutable identifiers (example: IPNS name) may also be used, but are not required.
• Human-readable unique node identifiers (slug) will be located under wordData, with non-human-readable identifiers located under metaData.
• wordData will contain default properties: slug, name, title, description (all strings; none required, except slug)
• If wordData.name exists, converting it into camelCase will generate wordData.slug with an optional suffix to ensure uniqueness (see example below)

Properties

By default, there are 4 properties in wordData:

• slug, which is required and must be unique within the context of any given conceptGraph
• name, which is not required and need not be unique
• title, which is not required and need not be unique
• wordTypes, which is an array, the contents of which are specified in a later DIP
• metaData, which is an object and contains data specified elsewhere

Declaration

See here.

Example:

{
  "wordData": {
    "slug": "fooBar_e12345",
    "name": "foo bar",
    "title": "Foo Bar",
    "wordTypes": ["word"],
    "metaData": {
      ...
    }
  },
  ...
}

In the above example, wordData.name and wordData.title are not presumed to be unique within the concept graph. However, wordData.slug must be unique. To enforce uniqueness, one suggested practice will be to make use of a cryptographic identifier such as nostr event id, file hash, or IPNS name; convert the name into camelCase; then add an underscore followed by the last 6 characters of the cryptographic identifier.

Cryptographic identifiers

(This section being moved to DIP-100b.md)

Publication

The publication of a word to nostr is described in DIP-101.