Atıf Dosyası: Doçentlik Başvurusunun En Zahmetli Adımını Otomatikleştirmek

Geçen yıl iki makalemin yayın serüvenini bu blogda anlatmıştım. O süreçte farkına varmadan akademik yayıncılığın mutfağına girdim; veri toplamaktan dergi seçimine, hakem yanıtlarından atıf takibine kadar pek çok aşamayı yakından gördüm. Yakın çevremdeki akademisyen hocalarla konuştukça da aynı yakınmayı tekrar tekrar duydum: doçentlik başvurusu başlı başına yorucu, ama içinde öyle bir adım var ki herkesin gözünü korkutuyor. Atıf dosyası.

Bu yazıda hem bu dosyanın ne olduğunu hem de onu hazırlamayı saatlerden dakikalara indirmek için geliştirdiğim Atıf Dosyası adlı platformu anlatacağım. İki amacım vardı: hocalarımıza gerçekten işe yarar bir araç bırakmak ve uçtan uca bir mikro SaaS'ı tek başıma kurmanın nasıl bir şey olduğunu görmek. İkisi de oldu, ikisini de buraya yazdım.

Türkiye'de bir akademisyenin unvan basamaklarında yükselirken karşılaştığı önemli eşiklerden biri doçentlik. Başvuru, Üniversitelerarası Kurulun (ÜAK) belirlediği şartlara göre, Doçentlik Bilgi Sistemi (DBS) üzerinden yapılıyor. Aday yayınlarını sisteme giriyor; her yayının ve o yayına gelen atıfların belirli kurallarla puanlanmasıyla bir toplam çıkıyor. Jürinin değerlendirmesi sonunda barajı geçen kişi doçent unvanına hak kazanıyor. Sürecin yasal çerçevesi Doçentlik Yönetmeliğiyle çiziliyor.

Yayın bilgilerinin bir kısmı görece kolay giriliyor. DBS, makalenin DOI numarasından yazar listesini, cilt ve sayı bilgisini, sayfa aralığını ve özeti büyük ölçüde otomatik çekebiliyor. İşin asıl puan getiren ve asıl yorucu tarafı ise atıflar. Yazdığınız bir makaleye gelen her atıf, atfı yapan yayının endeksine göre farklı değerlendiriliyor. Burada karşımıza Web of Science çekirdek koleksiyonunun endeksleri çıkıyor: SCIE, SSCI, AHCI ve ESCI. Bir de ulusal düzeyde TÜBİTAK ULAKBİM'in işlettiği TR Dizin var. Derginizin hangi endekste tarandığını Clarivate'in Master Journal List'i üzerinden doğrulayabiliyorsunuz.

Yani tek bir atıf bile aslında küçük bir araştırma işi: atfı kim yapmış, hangi dergide, o dergi hangi endekste, atıf yazının neresinde geçiyor? Bunların hepsinin belgelenmesi gerekiyor.

Eskiden atıfları belgelemek daha sade bir işti. Atıf sayısını, hangi endeksten geldiğini ve atfın künyesini APA gibi bir biçimde bir Word dosyasına yazmak çoğu zaman yetiyordu. Vakit alıyordu ama hiç değilse mekanik bir işti.

14 Ekim 2025 tarihli Resmî Gazete'de yayımlanan yönetmelik değişikliğiyle birlikte değerlendirmede eserlerin niteliği, özgünlüğü ve alana katkısı daha fazla öne çıktı. Atıfların belgelenmesi de sıkılaştı. Yeni düzende artık her atıf için ayrı ayrı şunları hazırlamanız bekleniyor:

• Atfı yapan yayının kapağı ya da künye (ünvan) sayfası
• Yayının ilk sayfası
• Atfın geçtiği sayfa
• Kaynakçada sizin eserinize işaret eden satır

Üstelik bunların kâğıt üzerinde işaretlenmesi, atfın açıkça görünür olması isteniyor. Atıf dosyası dediğimiz belge tam olarak bu: her atıf için bu dört parçanın, doğru sırada, ilgili satırları vurgulanmış halde toplandığı tek bir PDF.

Şimdi bunu ölçeğiyle düşünün. Diyelim ki kırk atıfınız var. Her biri için birden çok PDF açmak, doğru sayfaları bulmak, ekran görüntüsü almak, ilgili cümleyi sarıyla işaretlemek, sonra hepsini sırasıyla tek belgede birleştirmek gerekiyor. Bu, bir akademisyenin en kıymetli kaynağını, yani zamanını, en verimsiz biçimde tüketen bir angarya. İşin kötüsü, yaratıcı ya da entelektüel hiçbir tarafı da yok; baştan sona mekanik.

Atıf Dosyası tam olarak bu mekanik yükü hedefliyor. Mantığı tek cümleyle şu: kaynak makalenizi tanıtırsınız, ona atıf yapan çalışmaların künyelerini ve PDF'lerini verirsiniz, sistem de her atıf için YÖK'ün istediği biçimde, doğru sayfaları seçilmiş ve atıf satırı sarıyla vurgulanmış tek bir PDF üretir.

Akış, dört adımlık bir sihirbaza bölünmüş:

1. Aday ve kaynak makale. Kendi makalenizin künyesini girersiniz: başlık, ilk yazar soyadı, yıl ve DOI.
2. Atıfları içe aktarma. Atıf yapan çalışmaları üç yoldan ekleyebilirsiniz: Web of Science'tan aldığınız dışa aktarım dosyasını yükleyerek, bir künyeyi yapıştırıp yapay zekaya ayrıştırtarak ya da elle.
3. PDF ve kapaklar. Atıf yapan makalelerin PDF'lerini yüklersiniz; sistem her PDF'i doğru atıfa eşleştirip metin içindeki ve kaynakçadaki atfı kendisi bulur.
4. Dosyayı oluşturma. Son adımda her şeyin özetini görür, dosyayı oluşturur ve indirirsiniz.

Kısaca ana sayfası ve bu dört adımlık akış şöyle görünüyor:

Platform şu an ücretsiz, kart bilgisi istemiyor ve yüklediğiniz belgeleri sunucuda şifreli saklıyor. Bu kararların arkasındaki mühendisliğe birazdan geleceğim; önce bir örnek üzerinden ne yaptığını göstereyim.

Anlatmak yerine göstermek daha iyi olur. Sistemde örnek bir aday hesabı oluşturdum. Adı Mehmet Yılmaz, bir bilgisayar mühendisliği bölümünde çalışıyor ve kaynak makalesi "Energy-Aware Task Scheduling in Edge Computing Using Deep Reinforcement Learning".

Buradaki bütün makaleler, dergiler ve atıflar gerçek değil; telif sorununu önlemek için, gerçeklerine biçimsel olarak benzeyen ama tümüyle kurgu olan örnek verilerdir. Amacım aracın akışını gerçekçi bir senaryoda göstermek.

İlk adımda aday ve kaynak makale bilgileri giriliyor.

İkinci adımda atıflar içe aktarılıyor. Bu örnekte üç çalışma Mehmet'in makalesine atıf yapıyor; üçü de listeye ekleniyor.

Üçüncü adım işin can alıcı kısmı. Atıf yapan makalelerin PDF'leri yükleniyor ve sistem her birini, künyesindeki DOI üzerinden doğru atıfa eşleştiriyor. Ardından her PDF'in içinde Mehmet'in makalesine yapılan atfı arıyor: hem metnin içinde hem de kaynakçada. Bulduğunda satırın yerini işaretliyor ve "Atıf bulundu" diyor.

Son adımda her şeyin bir özeti çıkıyor: kaç atıf var, kaçının PDF'i yüklenmiş, kaçında atıf tespit edilmiş. Buradan çıktı seçeneklerini belirleyip dosyayı oluşturuyorsunuz.

Sihirbazın dört adımı, sırasıyla:

"Atıf dosyasını oluştur" dediğiniz anda, az önceki bütün parçalar tek bir PDF'te birleşiyor. Her atıf için ayrı bir bölüm açılıyor ve o bölümde dört kanıt sayfası sırayla yer alıyor: yayının ünvan (kapak) sayfası, eserin başlık sayfası, atfın geçtiği sayfa ve kaynakça sayfası. Atfın geçtiği satır ve kaynakçadaki ilgili referans sarıyla vurgulanıyor; jürinin tek bakışta görmesi gereken yer tam olarak orası.

İşte örnek dosyadan bir atıfın dört kanıt sayfası, sırasıyla:

Oluşturulan her dosya hesabınızın işlem geçmişinde tutuluyor; istediğinizde tekrar indirebiliyorsunuz.

Mehmet'in üç atıflık örneğinde bu, otuz sayfayı aşan bir belge oldu ve birkaç saniyede üretildi. Aynı işi elle yapsaydınız, üç atıf için bile yarım saatinizi alırdı; kırk atıf için bir günü gözden çıkarmanız gerekirdi.

Bir bilgisayar mühendisi olarak en çok bu kısımda eğlendim, o yüzden biraz teknik detaya gireceğim.

Mimaride tek bir ilkeye yaslandım: sunum katmanı veriye dokunmaz. Kullanıcının gördüğü arayüz Nuxt 4 ile yazılmış bir Vue uygulaması, ama veritabanına, dosyalara ve dış servislere yalnızca Rust ile yazılmış arka uç erişiyor. Böylece kimlik doğrulama, yetki, şifreleme ve iş kuralları tek bir yerde toplanıyor; arayüz ne kadar değişirse değişsin güvenlik sınırı hep aynı yerde kalıyor.

Arka uç, actix-web üzerinde çalışan bir Rust servisi. Oturumları JWT ile yönetiyor, parolaları argon2 ile saklıyor ve isteklere oran sınırı uyguluyor. Veritabanı tarafında sqlx kullandım; sorgular derleme zamanında gerçek şemaya karşı doğrulanıyor, yani yanlış bir kolon adı daha kod çalışmadan derleyicide patlıyor. Tek kişilik bir projede gece yarısı yapılan hataları erkenden yakalamak için bu paha biçilmez.

Atıf tespiti nasıl çalışıyor?

En keyifli kısım atıf tespiti. Bir PDF yüklendiğinde, PDF işlerini gören ayrı bir Python servisi devreye giriyor. Önce pdfplumber ile sayfaların metnini ve her kelimenin sayfadaki koordinatını çıkarıyor. Sonra şu adımları izliyor:

1. Kaynakça sayfasını buluyor. Bunu ya "References" veya "Kaynakça" gibi başlıklardan ya da numaralı referans deseninden anlıyor.
2. O listede sizin makalenizi arıyor: önce DOI'nizi, bulamazsa başlık benzerliğini ve ilk yazar soyadınızı deniyor.
3. Eşleşen satırın referans numarasını yakalıyor. Örneğin "[4]".
4. Metnin gövdesinde aynı "[4]" işaretinin geçtiği sayfayı buluyor.
5. Hem metindeki atıf işaretinin hem de kaynakçadaki satırın koordinatlarını döndürüyor.

Bu koordinatlar elimize geçtikten sonra, çıktı PDF'inin üzerine reportlab ile yarı saydam sarı bir katman çiziliyor; jürinin görmesi gereken iki satır böylece işaretlenmiş oluyor. Yani "sarı vurgu" aslında bir görüntü işleme numarası değil, metnin konumundan hesaplanan kesin bir kutu.

Güvenlik ve şifreleme

Akademik bir belge kişisel emeğin ürünü; sunucuda düz dursun istemedim. Yüklenen her PDF ve üretilen her dosya diskte AES-256-GCM ile şifreli tutuluyor. Üstelik zarf şifreleme (envelope encryption) yaklaşımıyla: her dosyanın kendine ait bir anahtarı var, o anahtar da bir ana anahtarla şifrelenip saklanıyor. Böylece bir dosyayı silmek ya da paylaşmak gerektiğinde bütün sistemi değil, yalnızca o dosyanın anahtarını ilgilendiren bir işlem yapılıyor.

Bir de görünmeyen ama önemli bir karar var: veritabanı ve Python servisi yalnızca makinenin kendisini (127.0.0.1) dinliyor, dışarıya tamamen kapalı. İnternetle konuşan tek kapı, TLS'i sonlandırıp istekleri arka uca taşıyan nginx. Yani saldırı yüzeyi bilinçli olarak küçük tutuldu.

Künyeleri kolaylaştırmak

Atıfları elle girmek istemeyenler için iki kestirme var. Web of Science'tan aldığınız dışa aktarım dosyasını olduğu gibi yükleyebilirsiniz; sistem bu dosyayı ayrıştırıp atıfları tabloya döküyor. Ya da bir künyeyi serbest metin olarak yapıştırırsınız; bu durumda Crossref'in açık API'siyle DOI ve künye doğrulanıyor, Google Gemini de dağınık metni başlık, yazar ve yıl gibi alanlara ayırıyor. İkisi de zorunlu değil ama büyük listelerde epey vakit kazandırıyor.

Görsel dilde sade ve akademik bir yer seçtim: fildişi bir zemin, başlıklarda serif bir font, vurgu için teal yeşili ve atıf sarısı. Karanlık tema koymadım; bu, başvuru telaşındaki bir akademisyenin gündüz vakti hızlıca iş gören bir araç beklediğini düşündüğüm bilinçli bir karardı. Arayüzdeki her metin de baştan çok dilli altyapıya hazır yazıldı, çünkü ileride İngilizce bir sürüm eklemek isteyebilirim.

Bütün sistem tek bir sunucuda yaşıyor: nginx, Rust arka ucu, Python servisi ve PostgreSQL aynı makinede, systemd ile yönetiliyor. Tek kişilik bir proje için bu hem yönetimi basit tutuyor hem de maliyeti neredeyse sıfırlıyor. Mikro SaaS'ın "mikro" tarafı biraz da bu: küçük tutabildiğin sürece tek başına ayakta tutabiliyorsun.

Önümüzdeki dönemde eklemek istediğim birkaç şey var; özellikle endekse göre atıf puanını tahmini olarak hesaplayan bir katman ve başvuru öncesi bir ön kontrol gibi. Ama temel iş, yani angaryayı dakikalara indirmek, şimdiden çalışıyor.

Atıf Dosyası şu an herkese açık ve ücretsiz. Doçentlik yolundaki hocalarımıza küçük bir kolaylık olsun istedim; bana da uçtan uca bir ürünü tek başıma tasarlayıp ayağa kaldırmanın keyifli bir denemesi oldu.

Başvurunun resmi tarafını merak edenler için güvenilir kaynaklar:

• ÜAK Doçentlik Başvuru Şartları
• Doçentlik Bilgi Sistemi (DBS)
• Doçentlik Yönetmeliği (Resmî Gazete, 2018) ve 14 Ekim 2025 tarihli değişiklik
• TR Dizin ve Web of Science Master Journal List

Aracı denemek, geri bildirim vermek ya da bir hata bulursanız bana yazmak isterseniz çok sevinirim. En çok da, birinin başvuru telaşında bir akşamını geri kazandığını duymak isterim.