On Thu, Aug 27, 2020 at 9:51 AM k-hen wrote:
> Thanks guys, yes it does certainly help :-)
>
> I'm really liking the idea of the single extra dimension for the
> attributes, and I'd like to help make them more prominent,
> there doesn't seem to be anything from the front-end to be able to
> nativ
Thanks guys, yes it does certainly help :-)
I'm really liking the idea of the single extra dimension for the
attributes, and I'd like to help make them more prominent,
there doesn't seem to be anything from the front-end to be able to natively
interact with them (like maybe a attribute subtree
On Tue, Aug 25, 2020 at 5:53 PM k-hen wrote:
> Yes, I think that workflow is extremely compelling!
> I think a full graph database integration is my ultimate goal, but this
> could be something really excellent to build off of.
>
> See here: https://github.com/totogo/awesome-knowledge-graph
> Sti
Yes, I think that workflow is extremely compelling!
I think a full graph database integration is my ultimate goal, but this
could be something really excellent to build off of.
See here: https://github.com/totogo/awesome-knowledge-graph
Still the same underlying principles though :-)
On T
There is another thing to think about here. Who else will need to work
with the system? It's one thing if it's only you. It's another if others
will be involved. Who among them is going to learn Leo's ins and outs?
This argues for having the steps of the workflow in external files - @clean
f
I wonder if this might be a place to use the workflow with rdf I wrote to
you about privately a few weeks back. Everything gets written as a
hierarchical list of classes, topics, properties, etc. (just indented
lists, no angle brackets or Turtle). Then you run my little parser to get
an rdf/x
Yes, this is accurate.
I think that XML has been somewhat supplanted by JSON, but there are
some json libraries which attempt to do similar things as xslt: like
https://github.com/tidwall/gjson and https://github.com/qntfy/kazaam fo
r example.
Note that while these essentially operate on the *doc
So let me see if I am getting some kind of a handle on this. The following
will not be complete; it's just responding to some of the elements.
1. *You need to produce documentation to fit some template not of your
choosing, probably in markdown or similar.*
The template is not the way you
Thanks Tom, I'm still trying to figure that out :-) but I'll try to list
out some of the things that I know...
1. I know that I want to use a literate programming style to describe the
requirements and the code for this system (unstructured+structured data)
2. I want to generally follow/work to
It would help if you could be more informative about what you are trying to
accomplish. Reading what you wrote below, it sounds like you want to make
a little markup language for Markdown. Maybe you can just use Markdown
itself (or asciidoc).
If you put some special character or term into hea
I keep flipping on how to sanely handle attributes.
My mind is more comfortable when I label nodes in meaningful *phrases* but
that's not how I want to represent them from a file output or coding
perspective.
I've been experimenting with jamming lots of information into the headline
using nam
11 matches
Mail list logo
