Anytype'ta Property nedir? Metadata ile bilgiyi sorgulanabilir yapmak

[[Nesne, tür ve ilişki]] bölümünde Property'nin modeldeki yerini gördük. Burada asıl soru şu: bir Property açmak ne zaman işe yarar, ne zaman sistemi gereksiz yere ağırlaştırır?

Property ne işe yarar?

Anytype Properties belgesi spreadsheet benzetmesini kullanır: Object satır, Property sütun gibi düşünülebilir (Anytype, Properties).

Bir Task için:

• Status
• Priority
• Due Date

bir Book için:

• Author
• Status
• Rating
• Finished Date

gibi alanlar oluşturabilirsin.

Bu alanların değeri yalnız düzenli görünmek değildir. Yapılandırılmış veri daha sonra aranabilir, filtrelenebilir, sıralanabilir ve Query ile tekrar çağrılabilir.

İki görev: tarif etmek ve bağlamak

Anytype Properties belgesi Property'leri iki kullanımda toplar (Anytype, Properties).

1. Object'i tarif etmek

Bir Task:

• Status = In Progress
• Priority = High
• Due Date = Friday

değerlerini taşıyabilir.

Bir Book:

• Status = Reading
• Rating = 4
• Finished Date = 12 October

değerlerini taşıyabilir.

Bu yapı sayesinde "okumakta olduğum kitaplar" veya "yüksek öncelikli açık görevler" gibi sorular makinece cevaplanabilir.

2. Object'i başka Object'e bağlamak

Property'nin biçimi **Object** olduğunda değer başka bir Anytype Object'ine referans verir.

Örneğin:

• Book → Author → Person Object
• Task → Project → Project Object
• Meeting → Client → Organization Object

Bu yüzden Anytype'ta ilişki yalnız metin içine bırakılmış bir link olmak zorunda değildir. Bağın anlamını Property adıyla da tanımlayabilirsin.

Hangi Property biçimleri var?

Güncel Anytype belgesi şu Property biçimlerini listeler (Anytype, Properties):

Biçimi seçerken görsel görünüşten önce verinin ne olduğunu düşün. Tarihi Text olarak yazarsan tarih gibi filtrelemek ve sıralamak zorlaşır. Status için serbest metin kullanırsan "Doing", "doing" ve "In progress" gibi varyasyonlar üretirsin.

Type ile Property arasındaki fark

[[Sözlükte]] kısa tanım şuydu:

• **Type:** Object ne?
• **Property:** Object hakkında hangi yapılandırılmış bilgiyi tutuyoruz?

Anytype Types belgesine göre Type, birlikte uygulanacak Property'ler, View'lar ve Template'ler için bir kalıp görevi görür (Anytype, Types).

Örneğin **Book** Type'ına:

• Author
• Reading Status
• Rating
• Published Date

Property'lerini ekleyebilirsin.

Yeni Book Object oluşturduğunda bu alanlar aynı modelin parçası olur.

Ancak Property yalnız Type içinde yaşayamaz diye bir kural yoktur. Anytype, bir Object'e Type'ında bulunmayan ek bir Property de ekleyebileceğini belirtir. Aynı Property birden fazla Type'ta da kullanılabilir (Anytype, Properties).

Property açmadan önce sorulacak dört soru

Her bilgiyi Property yapmak iyi bir model üretmez. Şu dört sorudan en az biri "evet" değilse bilgiyi normal içerikte tutmak daha sade olabilir:

1. **Buna göre filtreleyecek miyim?**

Örneğin Status = Reading.

1. **Buna göre sıralayacak mıyım?**

Örneğin Rating yüksekten düşüğe.

1. **Bunu Query içinde kullanacak mıyım?**

Örneğin Due Date = Today.

1. **Bu değer başka Object'lerle ortak bir şema mı?**

Örneğin bütün Book nesnelerinde Author.

"Belki bir gün lazım olur" tek başına iyi gerekçe değildir. Property sayısı arttıkça giriş maliyeti de artar.

Query neden Property ister?

Anytype Queries belgesi Query'yi bilgi tabanına sorulan, kendini otomatik güncelleyen bir soru olarak tanımlar (Anytype, Queries).

Örnek:

Type = Book Status = Reading Rating ≥ 4

Yeni bir Book bu kurala uyduğunda Query sonucuna otomatik girer.

Property olmadan sistem "bu kitap okunuyor mu?" bilgisini güvenilir biçimde ayırt edemez. Yapılandırılmış Property burada metni veriye dönüştürür.

Query özellikle birden fazla Type'ta ortak Property kullandığında güçlenir. Belgenin örneğinde Book, Movie ve Game nesneleri aynı Genre Property'sini taşıyorsa tek Query ile Science Fiction olanların tamamı getirilebilir (Anytype, Queries).

View Property'yi nasıl kullanır?

View veriyi değiştirmeden onu nasıl gördüğünü düzenler. Anytype Views belgesine göre View üç temel araç kullanır (Anytype, Views):

1. **Layout**
2. **Filter**
3. **Sort**

Property, ikinci ve üçüncü parçanın yakıtıdır.

Örneğin bir Project View:

• Layout: Kanban
• Filter: Status is not Done
• Group: Status
• Sort: Priority descending

olabilir.

Aynı Object'ler başka bir View'da Calendar olarak Due Date Property'sine göre gösterilebilir. Veri aynı kalır; bakış değişir.

Select mi, Object mi?

Bu ayrım özellikle önemlidir.

**Select** değeri, önceden tanımlanmış seçeneklerden biridir.

Örneğin:

• Status = Planned
• Status = Active
• Status = Done

**Object** Property ise başka bir gerçek nesneye gider.

Örneğin:

• Author → Ursula K. Le Guin
• Project → Nitorel
• Assigned To → Ahmet

Eğer değer kendi notları, bağlantıları, Property'leri ve ilişkileri olan bağımsız bir varlıksa Object daha anlamlıdır. Yalnız sınırlı bir durum etiketi ise Select daha sade olabilir.

Üç örnek model

Kitap

**Type:** Book

• Author → Object
• Status → Select
• Rating → Number
• Started → Date
• Finished → Date

Böylece "Reading durumundaki kitaplar" veya "bu yıl bitirdiğim 4+ puanlı kitaplar" Query ile çağrılabilir.

Proje

**Type:** Project

• Status → Select
• Priority → Select
• Deadline → Date
• Owner → Object

View ile Kanban, Query ile yalnız aktif projeler üretilebilir.

Kaynak notu

**Type:** Source Note

• Source URL → URL
• Author → Object veya Text
• Captured → Date
• Topic → Multi-select

Burada Author'ı Object yapıp yapmama kararı kullanımına bağlıdır. Yazar hakkında ayrıca not, kitap ve bağlantı tutacaksan Object mantıklıdır. Yalnız kaynak satırında adını göstereceksen Text daha hafiftir.

En küçük işe yarar şema

Anytype Types belgesinin ipucu "Keep it simple" der: yerleşik Type'larla başla, ihtiyaç doğmadan çok sayıda Type açma (Anytype, Types). Aynı disiplin Property için de geçerlidir.

Başlangıçta bir Book modeli için şu üç alan bile yeterli olabilir:

• Status
• Author
• Rating

Bir ay kullandıktan sonra gerçekten ihtiyaç duyuyorsan Started Date veya Finished Date eklersin.

Bu yaklaşım [[YAML ve makinece okunabilir kasa]] yazısındaki ilkeyle aynıdır: **sorgulamayacağın alanı sırf düzenli görünsün diye üretme**.

Property'ler yapılandırılmış bağı kurar; editör linkleri ve backlinks ise serbest bilgi ağını tamamlar. Sıradaki bölümde [[bağlantı ve backlink]] modelini açacağız; ardından Query bu yapılandırılmış veriden canlı cevaplar üretecek.