WHAT DO YOU RECOMMEND
Markdown export currently does not include any data about an object’s relations. This data should be included as YAML frontmatter.
HOW COULD IT BE DONE
E.g. If a Document object has a “Location” text relation and a “Tags” tag relation, prepend a YAML block to the Markdown document that looks like:
anytype_type: "Document"
anytype_relations:
- name: "Location"
type: "text"
content: "N St., Some City"
- name: "Tags"
type: "tag"
content:
- "Medical sciences"
- "Career"
Expressing relations as a list instead of a key-value avoids any issues with name clashes when two relations have the same name.
By default, export all relations associated with the object.
If the relation is an object relation, simply including the name and type of the target object should be enough.
REAL WORLD USE CASES
Lock-in is a major issue. One of the most important data when moving between tools is the relationships between each document, but these relationships are often destroyed during import/export. (E.g. exporting from Joplin will result in relative file links between MD files, but importing these directly into Anytype will conclude in thousands of broken links.)
The problem of broken links aside, plenty of important info is entered into relations as if they were form fields, so they’re not just metadata; they are part of the main body of data.
Having a basic YAML representation that Anytype itself understands will also make it possible to import relational data via Markdown, allowing users to pre-process their Markdown documents to fit Anytype’s model and import in a way that makes those documents immediately useful inside Anytype.
RECOMMENDED ALTERNATIVES
A JSON mapping between document titles and their associated titles? Terrible alternative, really. Most people and apps in the Markdown space already recognize YAML as the go-to structured data format.
I also considered translating tags into their #hashtag equivalents and embedding that into the Markdown content itself, but people might use multiple tag-type relations as a sort of “separation of concerns,” which will be lost if you just flatly convert everything into #plain_tags.
