Logseq DB Journals: günlük sayfa artık #Journal tag'iyle nasıl çalışıyor?

[[İlk bölümde]] dosya sürümündeki Journals davranışını gördük.

DB sürümünde günlük mantığı kaybolmuyor.

Veri modeline dahil oluyor.

Journal bir tagged page

Resmî DB belgesine göre journal page, #Journal tag'ine sahip.

Bu küçük değişiklik önemli.

Çünkü [[tag sistemi]] ortak properties taşıyabiliyor.

Yani #Journal tag'ine eklediğin bir property bütün journal sayfalarında görünür.

Örneğin:

• Mood
• Energy
• Focus
• Location

gibi günlük alanları tek tek her güne eklemek yerine tag üzerinden tanımlayabilirsin.

Bugünün sayfası otomatik oluşur

Journals view güncel günü otomatik oluşturur.

Bu, Logseq'in journal-first çalışma biçiminin devam ettiğini gösteriyor.

Yeni DB modeli olsa da ürünün giriş ritmi değişmiyor:

**önce bugüne yaz, sonra gerektiğinde yapıya bağla.**

Doğal dil ile tarihe gitmek

Resmî belge çift köşeli bağlantı içinde doğal dil tarihlerini destekliyor.

Örnek davranışlar:

• Today
• This Friday
• Last Friday
• Next Friday

gibi ifadeler belirli journal gününe referans verebilir.

Bu, tarih yazmak yerine niyeti yazmayı kolaylaştırıyor.

Date picker

Slash komutuyla Date picker açılabilir.

Picker:

• ok tuşlarıyla gün değiştirebilir,
• input alanında doğal dil kabul edebilir,
• seçilen tarihi journal page'e bağlar.

Örneğin "next week" gibi ifade gerçek tarihe dönüştürülebilir.

Bu davranış için Logseq, resmî belgede kullandığı natural-language date kütüphanesine de bağlantı veriyor.

Date property ile Journal ilişkisi

[[Date property]] değerleri journal page'e link oluşturur.

Bu yüzden task Deadline veya başka bir Date property, yalnız metadata taşımaz.

Aynı zamanda o tarihli journal sayfasıyla bilgi ağı kurar.

Örneğin bir proje node'unda Review Date = 20 Ekim ise, tarih değeri 20 Ekim journal'ına bağlanabilir.

Bu günlük sayfayı pasif günlükten zaman indeksine dönüştürür.

Önceki ve sonraki gün

Journal günündeyken:

• g n → next day
• g p → previous day

kısayolları kullanılabilir.

Bu, günler arasında klavye ile akışı korur.

Journal'a property eklemek ne zaman mantıklı?

Günlük sayfa her gün oluştuğu için aşırı metadata hızla bakım yüküne dönüşür.

Şu tür alanlar mantıklı olabilir:

• gerçekten günlük ölçülen durum,
• haftalık gözden geçirmede kullandığın sayı,
• query ile süzdüğün bilgi.

Şunlar gereksiz olabilir:

• her gün boş kalan on alan,
• yalnız estetik dashboard için metadata,
• hiçbir query/view içinde kullanılmayan seçenekler.

Örnek günlük modeli

Başlangıç için:

• Focus → Number
• Mood → Text choices
• Review → Checkbox

yeterli olabilir.

Her journal'da aynı üç alan görünür.

Bir ay sonra gerçekten hangi alanların kullanıldığı belli olur.

Task ile Journal'ı birleştirmek

[[Task modelinde]] Deadline ve Scheduled Date property'dir.

Bu iki alan sayesinde görevler zaman eksenine bağlanır.

Journal ise o günün bağlamını taşır.

Bu iki sistemi aynı şey yapma.

Task:

**ne yapılacak?**

Journal:

**o gün ne oldu / ne düşündüm / neye baktım?**

Aralarında tarih bağlantısı olması yeterli.

Karar

DB sürümü Journal'ı kaldırmıyor; onu type/tag sisteminin içine alıyor.

Asıl kazanım:

**günlük sayfayı her gün yeniden şablonlamak yerine #Journal üzerinden ortak davranış verebilmek.**

Ama günlük notun temel değeri hâlâ aynı: bugünün bağlamını hızlı yakalamak.