Open kvistgaard opened 1 year ago
SA currently extends org.commonmark
library to identify the YAML frontmatter, so one can chain a SA clause to query those properties. One usage example is here
I haven't seen the key::value
method before, so I must investigate.
About the wikilinks, I am curious about what type of interpretation you would expect, it will probably need to be something like the way SA currently interprets regular links, as in:
[A document with a link](http://www.example.org)
@prefix fx: <http://sparql.xyz/facade-x/ns/> .
@prefix xyz: <http://sparql.xyz/facade-x/data/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
<http://www.example.org/document> a fx:root .
<http://www.example.org/document> a xyz:Document .
<http://www.example.org/document> rdf:_1 <http://www.example.org/document/paragraph/1> .
#
<http://www.example.org/document/paragraph/1> a xyz:Paragraph .
<http://www.example.org/document/paragraph/1> rdf:_1 <http://www.example.org/document/paragraph/1/link/1> .
#
<http://www.example.org/document/paragraph/1/link/1> a xyz:Link .
<http://www.example.org/document/paragraph/1/link/1> xyz:destination "http://www.example.org" .
<http://www.example.org/document/paragraph/1/link/1> rdf:_1 "A document with a link"
OK, I found this link documenting Logseq properties: https://docs.logseq.com/#/page/properties
I am curious about what type of interpretation you would expect
I would expect a specific SA property so that it's easy to distinguish and work with internal links (in most cases, they can be a resource of type Note, unless it has a specific type:
or type::
or is a::
declaration, but let's keep it simple for now).
So, if we have two MD files A.md and B.md, and A.md contains a paragraph saying:
Something about [[B]]
then
<http://www.example.org/document/paragraph/1> a xyz:Paragraph ;
xyz:mentions <URI of B> .
(I don't remember now in SA what will be the property linking the paragraph URI with the string Something about [[B]]
, that's why I didn't add it in the example,)
Now, the URI of B is often provided is some way by the tool but if there is a too bg diversity then the file path of B can be used.
Then in many cases the inverse relationship becomes interesting: find me all paragraphs (and in which documents they are) which mention B or C, for example.
Some of these tools, have not only page (note) references with [[wikilinks]] but also block references, which in Clojure/Datalog tools like Logseq[^1], Roam Research and Hulunote (there are two more are with (( )) and in Obsidian there is another mechanism) have dereferencible URIs, where one paragraph can mention another.
[^1]: By the way, I have used Logseq to publish a SHACL wiki and a SPARQL wiki. The latter one needs update and one of the things to add is a page about SA.
There is a growing number of tools for personal knowledge management, a sizable part of which uses MD with [[wikilinks]]. This includes Obsidian (with over 1 mln users), Logseq, Foam, Dendron, acreom, Cosma, nb, Drafts, Emanote, Nota, Zettlr, Supernotes, bangle.io and more. Most of them use GitHub flavour of MD or are very close to it, but more importantly, they all use
[[ ]]
syntax for internal links to build a graph of MD files. Since SA already supports MD, recognizing this structure will allow traversing the graph of MD files regardless of the tool used for creating it.A growing number of these tools support properties. There is some variation there,
key: value
(from YAML, and within---
front matter, e.g. in Obsdian) orkey::value
(from Roam, e.g. Logseq) where the [[key]] is a separate, linked MD file.It's maybe worth noting that Logseq already has some RDF capabilities, thanks to @cldwalker .