Is the Philosophy of Knowledge Valuable for Practice?

tomp · June 21

@ZettelDistraction said:

@tomp said:

...

That is a useful example of associative expansion, but it does not yet demonstrate Level 5 emergence. It shows low-friction search prompting an associative user. Pre-existing links do no work in these examples, and I do not yet see a Zettelkasten-specific the effect.

What baseline would distinguish the contribution of the system from ordinary full-text search or an outline? And what result would count against the claim that the system supports expansion or emergence?

An outline is very useful because its growth represents the semantics (usually tacit or not well articulated) of the user. It can provide more "semantic channels", as I call them, than cards and intercard links do, so it complements them.

ZettelDistraction · June 21

I don't mean to be rude, but the methodological question remains unanswered. I lack the patience to do more than clean up my Zettel template at this point.

harr · June 22

@ZettelDistraction said:
My Zettelkasten has become a roach motel for ideas: they check in, but don't check out.

Zettelkasten as a death trap for ideas? That's dark. :-)

@ZettelDistraction said:
I have yet to encounter evidence that philosophical distinctions improve what enters the system or what comes out.

I think that philosophical distinctions help clarify the goals of your system.

For example, if you believe that knowledge is made of discrete knowledge building blocks, then you might want to have notes that are discrete as well.

If you believe that ideas are independent of sources and should be made "your own", then you might optimize for a writing style that decontextualizes ideas and makes sense to you personally.

If you value social epistemology, then you might want to have notes that reflect social context and that clearly distinguish between own thoughts and other people's thoughts. You might want to optimize your language for compatibility with other people.

However, these distinctions shouldn't matter much, if your Zettelkasten is just a final resting ground for old ideas. :-)

@ZettelDistraction said:
I've never been surprised by following links in my Zettelkasten. Appalled and embarrassed, yes, but surprised, never.

I'm surprised when I rediscover notes that I had forgotten about. I'm surprised when I approach old notes with new questions, because I see them differently. I'm sometimes surprised by random findings that feel serendipitous.

On the other hand, "surprise" might be the wrong word. I have a Zetttelkasten, because I want it to produce such "surprises". I want a tool that resurfaces forgotten content and that allows me to looks at collected content with a different perspective. There's nothing mystical about it. :-)

ZettelDistraction · June 22

@harr said:
Zettelkasten as a death trap for ideas? That's dark. :-)

That's right, blame the victim of his Zettelkasten.

I think that philosophical distinctions help clarify the goals of your system.

That changes the claim. Philosophical vocabulary might inform design choices such as note granularity, decontextualization, provenance, audience, but that isn't evidence that those choices improve what enters the system or what comes out.

Even if knowledge consisted of discrete building blocks, it would not follow that notes should. Decontextualizing an idea may make it feel like one's own while destroying provenance. Distinguishing my thoughts from other people's thoughts is useful, but attribution and provenance do not require social epistemology

However, these distinctions shouldn't matter much, if your Zettelkasten is just a final resting ground for old ideas. :-)

More victim blaming! The final resting ground is the observed outcome. Maybe Ahrens shouldn't have called his Zettels permanent notes.

I'm surprised when I rediscover notes that I had forgotten about. I'm surprised when I approach old notes with new questions, because I see them differently. I'm sometimes surprised by random findings that feel serendipitous.

I don't doubt the report. Rediscovering a forgotten note is retrieval; approaching it with a new question is reinterpretation. What remains unidentified is the contribution of the Zettelkasten over full-text search, an ordinary archive, or a simpler note system. Roach motels have their surprises.

Here is what I mean by a benchmark. Freeze the system under test at a named repository commit and record its behaviorally relevant configuration. For each claim, specify:

Under task $(T)$, feature $(X)$ improves outcome $(Y)$ over baseline $(B)$, and result $(R)$ would count against the claim.

The repository should separate the system specification from the experiments:

BENCHMARK.md
docs/
    SYSTEM.md
    OBSIDIAN.md
    ZOTERO.md
    PANDOC-LATEX.md
    SESSION-PROTOCOL.md
config/
    system-profile.yaml
benchmark/
    claims.yaml
    retrieval/
        tasks/
        results/
    thread-resumption/
        tasks/
        results/
    citation-export/
        tasks/
        results/
    structural-reliability/
        tasks/
        results/

For example:

claim: Linked chains improve resumption of dormant research.
task: Continue an abandoned line of inquiry from a frozen set of notes.
baseline: The same notes with curated link navigation unavailable.
primary_outcome: Blinded evaluation of the resulting argument.
secondary_outcomes:
  - useful notes incorporated
  - provenance errors
  - unsupported claims
  - completion time
  - link-maintenance cost
failure_condition: No material improvement in the finished work.

Reports of surprise and serendipity identify phenomena that might be tested. They do not yet identify what caused them, whether a simpler system would perform as well, or what result would count against the explanation.

But first I need to restore the self-documenting Zettel template in the GitHub repository.

UPDATE: The benchmark also requires a session protocol. In my case, every work session begins by starting Obsidian and Zotero. The protocol should specify when timing begins, whether startup and indexing time count, which applications and plugins are available, and when the system is considered ready for the task. This belongs in docs/SESSION-PROTOCOL.md

tomp · June 22

@ZettelDistraction said:

Here is what I mean by a benchmark. Freeze the system under test at a named repository commit and record its behaviorally relevant configuration. For each claim, specify:

Under task $(T)$, feature $(X)$ improves outcome $(Y)$ over baseline $(B)$, and result $(R)$ would count against the claim.

The repository should separate the system specification from the experiments:

A plan like this is likely to fail, because the effects to be measured are usually very contingent and dependent on the practitioner and his state of mind at some particular moment. That's why I cast my levels as "levels of thinking support" rather than as e.g., practices or guarantees - what features are likely to support a person hoping for these kinds of results. Luhmann knew this contingent aspect very well:

"...[communication with the slip box] becomes productive only at the moment of evaluation, and is thus bound to a certain time and is to a high degree accidental."

I'm not saying that some kind of measurement or test is inherently impossible, just that it can't be done the way you are suggesting. One might as well try to compare two dating apps by asking which one leads to more cases of true love. If you could figure out how to measure the incidence of true love, even then you would need a great number of cases to get statistically reliable results, except that the statistics would be questionable because the people involved are not going to be drawn from a homogeneous population. And after working through all that you might realize that what counts most is true love that lasts for a long time, say at least ten years, and how are you going to measure that?

ZettelDistraction · June 22

@tomp said:
A plan like this is likely to fail, because the effects to be measured are usually very contingent and dependent on the practitioner and his state of mind at some particular moment.

You say measurement is not inherently impossible, only that it cannot be done the way I suggest. What do you propose instead? What comparison would preserve the contingencies you describe while still allowing the claim to fail?

I agree that practitioner–system interactions and momentary state matter. That changes the design and limits the inference; it does not eliminate the possibility of comparison. “Accidental” is not a synonym for “unmeasurable,” and heterogeneity is a design problem rather than a dispensation from testing.

I am not proposing to measure “true love.” A benchmark can test narrower claims under specified conditions: retrieval, thread resumption, production of a useful connection, or completion of a draft. Then the question is whether this is interesting. The benchmark need not determine whether some dating app produces true love; it can begin by asking whether it gets a second date [eww gross!].

If “supports expansion or emergence” means only that something may occur for some receptive practitioner in some unspecified state at some accidental moment, then it is not a testable claim. I do not know what observation would count against it, or what distinguishes the claimed support from ordinary association and chance.

harr · June 23

@ZettelDistraction said:

@harr said:
Zettelkasten as a death trap for ideas? That's dark. :-)

That's right, blame the victim of his Zettelkasten.

In case you're joking: I enjoy a dark sense of humor. :-)

In case you're not: I'm curious how much agency you attribute to your zettelkasten.

@ZettelDistraction said:
That changes the claim.

The claim didn't make much sense to me. How can anyone provide "evidence that philosophical distinctions improve what enters the system or what comes out", when "improve" and "system" are so undefined?

What kind of system are we talking about? Do you mean any kind of Zettelkasten? Do you mean a particular kind of Zettelkasten? Where do you draw the line between "this is part of the system" and "this is outside the system"?
What kind of entities do you have in mind that cross the system boundary? What is it that enters the system? What is it that comes out of the system?
And how would you measure improvement of those entities?

@ZettelDistraction said:
Philosophical vocabulary might inform design choices such as note granularity, decontextualization, provenance, audience, but that isn't evidence that those choices improve what enters the system or what comes out.

Yes.

@ZettelDistraction said:
Decontextualizing an idea may make it feel like one's own while destroying provenance. Distinguishing my thoughts from other people's thoughts is useful, but attribution and provenance do not require social epistemology

Yes. For example, you can easily give credit in a footnote, if that's enough for your purposes.

@ZettelDistraction said:
More victim blaming! The final resting ground is the observed outcome. Maybe Ahrens shouldn't have called his Zettels permanent notes.

Are you serious about turning this into a blame game?

@ZettelDistraction said:
I don't doubt the report. Rediscovering a forgotten note is retrieval; approaching it with a new question is reinterpretation.

Yes.

@ZettelDistraction said:
What remains unidentified is the contribution of the Zettelkasten over full-text search, an ordinary archive, or a simpler note system.

This is an example where I'd find a personal attribution helpful. Whose claim do you have in mind? And what are those claims exactly?

@ZettelDistraction said:
Roach motels have their surprises.

I tend to discard them after a while. Why keep dead bugs around? :-)

@ZettelDistraction said:
Reports of surprise and serendipity identify phenomena that might be tested.

How would you describe these phenomena, so that they can be tested?

@ZettelDistraction said:
They do not yet identify what caused them, whether a simpler system would perform as well, or what result would count against the explanation.

Yes.

@ZettelDistraction said earlier:
My claim is that without a benchmark or reference system, these accounts remain anecdotes. They may accurately report an experience, but they cannot establish what caused it, whether a simpler system would have worked as well, or what result would count against the explanation.

Yes. But who claimed that they are more than just anecdotes?

ZettelDistraction · June 23

The last reply missed the methodological point. Once the system is said to “support” expansion or emergence, the question is what distinguishes that support from ordinary search, association, or chance—not whether anecdotes are permissible. Some benchmark or comparison is therefore needed. I proposed one, to be developed after I restore my self-documenting Zettel, but the reply ignored it. I don’t think rereading the exchange will help.

I will restore the self-documenting Zettel in my GitHub and leave it at that.

harr · June 23

@ZettelDistraction said:
The last reply missed the methodological point.

Your reply ignored my questions. :-) But I don't mind adding a few words.

@ZettelDistraction said:
Once the system is said to “support” expansion or emergence, the question is what distinguishes that support from ordinary search, association, or chance—not whether anecdotes are permissible.

That's a good question. But in order to make such a comparison you need to define what exactly you are comparing. Each of the terms is vague at best. What do you mean by "ordinary search"? What hypothesis about "emergence" are you testing?

@ZettelDistraction said:
Some benchmark or comparison is therefore needed.

Yes. And there lies the problem. How do you define such a benchmark? And what are the evaluation criteria?

@ZettelDistraction said:
I proposed one, to be developed after I restore my self-documenting Zettel, but the reply ignored it. I don’t think rereading the exchange will help.

It does. :-) Let me go through the elements of your proposal:

Freeze the system under test at a named repository commit and record its behaviorally relevant configuration.

What exactly is a "behaviorally relevant configuration"? Whose behavior do you have in mind—the system's? And what exactly do you include in that "system"? Is it just a bunch of files on a server? They don't behave unless someone interacts with them. So do you also include the user? If you want to examine user behavior, what behaviors specifically are of interest to you? Is that behavior independent of a particular person? Would another person interact with the same zettelkasten in the same way?

For each claim, specify:

Under task $(T)$, feature $(X)$ improves outcome $(Y)$ over baseline $(B)$, and result $(R)$ would count against the claim.

How would you know that outcome "improves"?

For example:

claim: Linked chains improve resumption of dormant research.
task: Continue an abandoned line of inquiry from a frozen set of notes.
baseline: The same notes with curated link navigation unavailable.
primary_outcome: Blinded evaluation of the resulting argument.
secondary_outcomes:
  - useful notes incorporated
  - provenance errors
  - unsupported claims
  - completion time
  - link-maintenance cost
failure_condition: No material improvement in the finished work.

So many vague and subjective terms. What is "research"? When does it become "dormant"? What makes notes "useful"?

If you wanted to demonstrate how difficult such a benchmark would be, then you succeeded. :-)

I have a much simpler take on this. The burden of proof lies with the person who makes the claim. And the bolder a claim gets, the more Iikely I will quote Carl Sagan: "Extraordinary claims require extraordinary evidence". So if someone claims phenomena like emergence, they better have some evidence. From this point of view it matters, if anecdotes are permissible as evidence.

The burden of proof is one of the reasons why I prefer to say "Alice claims" instead of "something is said to".

So if you claim that it is possible to run benchmarks with a zettelkasten, then the burden of proof lies with you. Good luck. :-)

ZettelDistraction · June 23

@harr said:
The burden of proof lies with the person who makes the claim.

Agreed. Let Alice claim that a Zettelkasten “supports” expansion or emergence. Alice must define the claim, provide evidence, and say what would count against it.

But who claimed that they are more than just anecdotes?

Then no system-level claim has been established. If these are merely autobiographical reports, there is nothing for me to disprove. If they are offered as evidence of what a Zettelkasten supports, Alice bears the burden.

So if you claim that it is possible to run benchmarks with a zettelkasten, then the burden of proof lies with you.

Please identify where I made that claim. What I said was conditional: if claims about Zettelkasten-specific effects are to amount to more than anecdotes, some benchmark or comparison is necessary. I said I would work on a benchmark after restoring my self-documenting Zettel; I did not claim that a satisfactory benchmark had been shown possible.^†

Your questions show that operational definitions are needed. They do not show that comparison is impossible. If you mean only that a benchmark needs definitions, I agree. If you mean that no benchmark is possible, that is your claim to support. Moreover, if “supports,” “expansion,” and “emergence” are too vague to benchmark, they are too vague to sustain the original claim.

Proposing a test does not transfer Alice’s burden to the person asking how her claim could be tested. Good luck. :-)

†. I then exited the discussion. I no longer think the benchmark is worth pursuing here.

ZettelDistraction · June 23

@harr said:
I think that philosophical distinctions help clarify the goals of your system.

The claim that philosophical distinctions improve Zettelkasten practice appears to be more than autobiographical. By your own standard, Alice must define the claimed improvement, provide evidence, and say what would count against it. “They have helped me” is an anecdote. Extraordinary evidence may be unnecessary, but some evidence beyond that anecdote would be useful.

harr · June 23

@ZettelDistraction said:
Please identify where I made that claim. What I said was conditional: if claims about Zettelkasten-specific effects are to amount to more than anecdotes, some benchmark or comparison is necessary. (…)

Same here. :-) I also phrased it conditionally: "(…) if you claim that it is possible to run benchmarks with a zettelkasten, then the burden of proof lies with you."

@ZettelDistraction said:
Your questions show that operational definitions are needed. They do not show that comparison is impossible.

Yes.

@ZettelDistraction said:
If you mean only that a benchmark needs definitions, I agree. If you mean that no benchmark is possible, that is your claim to support.

I can't imagine how such comparisons would work in practice, but I wouldn't rule them out in principle. Let's say: I believe it when I see it. :-)

@ZettelDistraction said:
Moreover, if “supports,” “expansion,” and “emergence” are too vague to benchmark, they are too vague to sustain the original claim.

Yes! (Unless of course the original claim somehow provided precise enough definitions.)

@ZettelDistraction said:
Proposing a test does not transfer Alice’s burden to the person asking how her claim could be tested.

Yes. Alice has the burden of proof that her claim can be tested. But Bob does have the burden of proof that his proposed test actually tests Alice's claim.

@ZettelDistraction said:

@harr said:
I think that philosophical distinctions help clarify the goals of your system.

The claim that philosophical distinctions improve Zettelkasten practice appears to be more than autobiographical. By your own standard, Alice must define the claimed improvement, provide evidence, and say what would count against it. “They have helped me” is an anecdote. Extraordinary evidence may be unnecessary, but some evidence beyond that anecdote would be useful.

This is the argument I had in mind:

A zettelkasten is a personal knowledge management system (PKMS).
A PKMS manages "knowledge".
In order to manage knowledge, we need to define goals. What does the "management" of knowledge entail? How do we know that we managed knowledge well?
In order to define such goals, we also need to define what we mean by "knowledge" for the purpose of our zettelkasten.
The philosophy of knowledge explores various concepts of "knowledge", that might be of value here.
thus: The philosophy of knowledge can have practical value for a zettelkasten, because it can help clarify goals by clarifying what we mean by "knowledge".

The examples were invitations to explore different paths. For example if you take the path of Analytical Philosophy it might lead you to a world where this sentence makes sense: "The atoms of atomic notes are knowledge-building blocks." If you take other paths they might lead you somewhere else.

I find our conversation interesting because of how you apply logical thinking. I'm surprised when you read something as a claim where I had a more social or explorative intention. I love this kind of surprise, because it prompts my curiosity. Thanks!

ZettelDistraction · June 24

@harr said:
I can't imagine how such comparisons would work in practice, but I wouldn't rule them out in principle. Let's say: I believe it when I see it. :-)

Then we agree: you have not shown that comparison is impossible. You have shown only that operational definitions would be required.

@harr said:
Alice has the burden of proof that her claim can be tested. But Bob does have the burden of proof that his proposed test actually tests Alice's claim.

Yes. Bob bears that burden after Bob presents a test as adequate. That still does not transfer Alice’s burden to Bob. If Alice claims that a Zettelkasten supports expansion or emergence, Alice must define the claim, provide evidence, and say what would count against it.

@harr said:
The philosophy of knowledge can have practical value for a zettelkasten, because it can help clarify goals by clarifying what we mean by "knowledge".

Here can is doing the work. I do not dispute bare possibility. Almost anything can occasionally help someone think. The interesting question is whether philosophical distinctions are likely to improve Zettelkasten practice, for whom, under what conditions, and compared with what simpler alternative.

Nor does calling something a “personal knowledge management system” entail that its goals require a philosophical account of knowledge. Operational goals can be specified directly: retrieval, provenance, resumption of dormant work, error reduction, draft quality, maintenance cost.

@harr said:
I'm surprised when you read something as a claim where I had a more social or explorative intention.

The sentences had propositional content. If the intent was only social or exploratory, there is no need to defend an evidential claim. But that trades away support for the practical value of philosophy in Zettelkasten practice for exploration.

ZettelDistraction · June 26

The Zettel specification in https://github.com/flengyel/Zettel is done.

It now does the needed work: it defines the self-documenting note specification, distinguishes ordinary notes from the explanatory specification, leaves format mostly unspecified, reserves the index IDs, states the id/title/H1 relationship, and keeps configuration out of the README.

I trust this CC BY-SA 4.0 template has not demolished the Zettelkasten consulting business. Next, I need to audit the Zettel wiki and update the software configuration. The README is about as good as I can make it. It only took years to write.

As for the drift from “philosophical distinctions are useful in Zettelkasten practice” to impressionistic exploratory fog: the README clarifies the object under discussion.

ZettelDistraction · June 26

Correction: "leaves the <ID> format mostly unspecified."

harr · June 29

@ZettelDistraction said:
As for the drift from “philosophical distinctions are useful in Zettelkasten practice” to impressionistic exploratory fog: the README clarifies the object under discussion.

Does it?

It calls the object under discussion a "single digital Zettelkasten". But where does the README clarify what you mean by "Zettelkasten"?

You're pointing to rather foggy external resources that explore various options. But you don't specify your own methodology. For example:

Does a new zettel have to connect to a "previous" zettel? This is Luhmann's basic rule. See also The Great Folgezettel Debate. If it did, the YAML section could include a non-optional link to the zettel being followed.
Should zettels require a title? Very few of Luhmann's zettels did have titles. How do you justify that your method requires titles?
Should zettels be self-explanatory or can they rely on the context of "previous" or connected zettels? See also Atomicity.
Can zettels be based on questions or normative claims? For example, questions are an important element in Joel Chan's methodology.
Should all zettels be phrased as propositions? Why? Why not?

These are questions where the philosophy of knowledge matters.

ZettelDistraction · June 29

@harr said:
It calls the object under discussion a "single digital Zettelkasten". But where does the README clarify what you mean by "Zettelkasten"?

This is a bad-faith switch of object. The object under discussion was the self-documenting Zettel specification I said I was restoring. It is not a specification of the Platonic Zettelkasten, complete with necessary and sufficient conditions, the statement of which is likely a fool's errand.

The README does the work it was written to do: it defines the self-documenting note specification, distinguishes ordinary notes from the explanatory specification, leaves the <ID> format mostly unspecified, reserves the index IDs, states the id/title/H1 relationship, and keeps configuration out of the README. Operational matters, definitions of terms, and examples go in the Zettel Wiki, which the README now explicitly identifies as under construction.

So no, the README does not settle every Zettelkasten controversy. Why would it? A README whose purpose is to state a format is under no obligation to state a theory of Folgezettel, atomicity, question-notes, normative claims, proposition form, or Luhmann orthodoxy.

Does a new zettel have to connect to a "previous" zettel?

Not in this specification. This system uses WikiLinks, SEE ALSO, and index notes. It does not require Folgezettel. If I later want a Folgezettel rule, it belongs in the Wiki or system documentation, not in the note-format README. In fact, I do not want a Folgezettel rule. The format works with or without Folgezettel, and it would be silly to impose one in a format specification.

Should zettels require a title?

In this system, yes. The README states the convention: title: consists of <ID>, one space, and <TITLE>, and the H1 is the <TITLE> portion. “Luhmann rarely used titles” is historically interesting; it is not an argument against this digital Markdown convention.

Should zettels be self-explanatory or can they rely on the context of "previous" or connected zettels?

That is a methodological design question, not a README-format question. The specification defines where body content, SEE ALSO, and references go. It does not pretend to settle atomicity.

Can zettels be based on questions or normative claims?

Nothing in the specification forbids them.

Should all zettels be phrased as propositions?

No such rule appears in the README.

These questions may be useful questions for a page in the Zettel Wiki. They do not show that the README failed at its purpose, and they do not show that philosophy of knowledge is necessary. They show only that note systems have design choices.

This is exactly why operational boundaries matter. One must distinguish artifact, format, method, implementation, configuration, and evaluation. Perhaps epistemological distinctions can help here after all: not by defining knowledge in the abstract, but by preventing a switch from the self-documenting Zettel specification to the Platonic Zettelkasten.

A format specification is not defective because it refuses to become a metaphysics of Zettelkasten.

ZettelDistraction · June 29

@harr said:
Should zettels require a title?

In this note-format specification, yes. As for universal Zettelkasten norms, no claim is made.

Very few of Luhmann's zettels did have titles.

Irrelevant to this specification.

How do you justify that your method requires titles?

I don't. No such justification is owed. “Luhmann rarely used titles” is not an objection to this note-format specification unless you smuggle in a normative premise I do not make: that my system must follow Luhmann’s practice. That is your presumption, not mine.

harr · June 30

@ZettelDistraction said:
This is a bad-faith switch of object.

I reject that characterization. The README states:

This repository documents the conventions I follow for a single digital Zettelkasten.

and

This README is a note-format specification. It documents the conventions used in this repository for one digital Zettelkasten.

Admittedly, I could have phrased more precisely: the "object under discussion" is a README file; the object of the README file is a documentation of conventions; the object of those conventions is a "Zettelkasten".

@ZettelDistraction said:
The object under discussion was the self-documenting Zettel specification I said I was restoring. It is not a specification of the Platonic Zettelkasten, complete with necessary and sufficient conditions, the statement of which is likely a fool's errand.

What do you mean by "Platonic Zettelkasten"? Do you mean the platonic idea of Zettelkasten? I agree that chasing such an ideal is pointless. What gave you the impression I would be interested in such an ideal?

@ZettelDistraction said:
So no, the README does not settle every Zettelkasten controversy. Why would it? A README whose purpose is to state a format is under no obligation to state a theory of Folgezettel, atomicity, question-notes, normative claims, proposition form, or Luhmann orthodoxy.

The README is obliged to deliver what it promises. In this case the conventions you chose to follow for your Zettelkasten.

Nobody asked you to state theories or settle controversies. I'm asking about your personal design choices.

@ZettelDistraction said:

Does a new zettel have to connect to a "previous" zettel?

Not in this specification. (…) In fact, I do not want a Folgezettel rule. (…)

Thanks!

@ZettelDistraction said:

Should zettels require a title?

In this system, yes. (…)

Thanks!

@ZettelDistraction said:
These questions may be useful questions for a page in the Zettel Wiki. They do not show that the README failed at its purpose, and they do not show that philosophy of knowledge is necessary.

I don't claim that philosophy of knowledge is necessary.

I claim that it is relevant. I claim that philosophy of knowledge helps better understand methodological problems, explore a wider range of options and find better justifications for your design choices.

@ZettelDistraction said:
They show only that note systems have design choices.

Yes. And it's precisely those choices that I expected to find in a README that promises to document someone's individual conventions. :-)

@ZettelDistraction said:
This is exactly why operational boundaries matter. One must distinguish artifact, format, method, implementation, configuration, and evaluation. Perhaps epistemological distinctions can help here after all: not by defining knowledge in the abstract, but by preventing a switch from the self-documenting Zettel specification to the Platonic Zettelkasten.

We agree on the operational boundaries.

That's why I'm asking what you mean by "zettel" and "zettelkasten" in the context of your README. How do you define those terms?

You made the switch yourself by introducing a "Platonic Zettelkasten" in this discussion, when I explicitly asked about your own methodology. :-)

@ZettelDistraction said:
A format specification is not defective because it refuses to become a metaphysics of Zettelkasten.

I agree. However, you created a dependency on discussions about the "metaphysics of Zettelkasten" by linking external discussions instead of simply providing your own definitions.

harr · June 30

@ZettelDistraction said:
It is not a specification of the Platonic Zettelkasten, complete with necessary and sufficient conditions, the statement of which is likely a fool's errand.

I'd like to hear from people who think that is possible to specify "the Platonic Zettelkasten". But this might be a topic for a separate thread.

ZettelDistraction · June 30

@harr said:
The README is obliged to deliver what it promises. In this case the conventions you chose to follow for your Zettelkasten.

It does. The README specifies the Markdown note format used in my digital Zettelkasten. That is what it promises.

@harr said:
I'm asking about your personal design choices.

See the README.

@harr said:
I claim that philosophy of knowledge helps better understand methodological problems, explore a wider range of options and find better justifications for your design choices.

That is your project, not mine. I am not soliciting “better justifications” for my design choices.

@harr said:
However, you created a dependency on discussions about the "metaphysics of Zettelkasten" by linking external discussions instead of simply providing your own definitions.

No. Background links are not dependencies. They do not determine the Markdown format, the YAML front matter, the id/title/H1 relationship, the reserved index IDs, SEE ALSO, References, WikiLinks, hashtags, or citations.

If a promised note-format convention is missing, identify it. Otherwise there is no README objection.

harr · June 30

@ZettelDistraction said:
If a promised note-format convention is missing, identify it. Otherwise there is no README objection.

Thanks for updating the README. Now I find the scope much better defined.

Zettelkasten Forum

Is the Philosophy of Knowledge Valuable for Practice?

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion