Data Provenance : Bir Verinin Gerçek Kaynağına Nasıl Ulaşırız?

Bir raporda öğrencilerin yüzde 12’sinin belirli bir hizmetten yararlandığını okuduğumuzu düşünelim. Sayfanın altında bir kaynak bağlantısı bulunuyor. Bağlantıyı açtığımızda başka bir rapora, oradan da bir veri dosyasına ulaşıyoruz. Peki elimizdeki oranı artık açıklayabilir miyiz? Hesaba hangi öğrencilerin katıldığını, eksik yanıtların nasıl işlendiğini ve hangi veri sürümünün kullanıldığını bilmiyorsak, kaynak arayışımız henüz tamamlanmış sayılmaz.

Veri biliminde bir sonucun dayanağını incelemek, bu tür sorulara yanıt verebilmeyi gerektirir. **Data provenance**, burada “veri kökeni ve işlem geçmişi” anlamında kullanacağımız kavramdır. W3C, provenance bilgisini bir verinin veya nesnenin üretimine katılan varlıklar, faaliyetler ve sorumluluk taşıyan aktörler hakkında bilgi olarak tanımlar. Bu bilgi, verinin güvenilirliğini değerlendirmeye yardımcı olur; tek başına doğruluğun kanıtı değildir \[1].

Kaynak bağlantısının ötesinde

Bir veri dosyasını indirdiğimiz platform ile veriyi üreten kurum aynı olmayabilir. Dosya, başka bir araştırmanın yeniden düzenlenmiş kopyası olabilir; birkaç kaynaktan birleştirilmiş veya belirli kayıtlar çıkarılarak paylaşılmış olabilir. Bu nedenle “Veriyi nereden indirdim?” sorusu ile “Bu veri nasıl oluştu?” sorusu farklı bilgiler gerektirir.

Üstelik her veri için tek bir başlangıç noktası bulunmaz. Bir ulaşım göstergesi; sensör ölçümleri, hava durumu kayıtları ve idari sınıflandırmalar birleştirilerek hesaplanabilir. Böyle bir göstergenin kökenini açıklamak, birbirine bağlanan kaynakları ve bunların işlenme biçimini incelemektir.

Bu yazıda data provenance, bir sonucun dayandığı verileri, dönüşümleri ve sorumluluk ilişkilerini birlikte ele alan çerçeveyi ifade ediyor. Yakın bir kavram olan *data lineage* ise veri akışını ve girdi-çıktı bağımlılıklarını anlatmak için kullanılıyor. Bu, anlatımı kolaylaştıran bir çalışma ayrımıdır; terimler farklı çalışmalarda örtüşebilir. Belirli bir sistemin neyi kaydettiğini anlamak için kullandığı terimden çok, tuttuğu bilgilere bakmak gerekir.

Veritabanı araştırmaları hangi soruları ayırıyor?

Provenance literatürünün temel çalışmalarından birinde Buneman, Khanna ve Tan (2001), *where-provenance* ile *why-provenance* arasında ayrım yapar \[2].

**Where-provenance**, sonuçta görülen bir veri değerinin kaynak veritabanındaki hangi konumdan alındığıyla ilgilenir. Örneğin rapordaki bir bölüm adının, hangi tablonun hangi alanından geldiğini sorar.

**Why-provenance**, bir sorgu sonucunun oluşmasını destekleyen kaynak kayıtlarını ele alır. Buradaki “neden”, araştırmacının çalışmayı yapma amacı anlamına gelmez. Soru, belirli bir sonuç kaydının hangi kaynak kayıtlarına dayanarak ortaya çıktığıdır.

Green, Karvounarakis ve Tannen’in (2007) çalışması ise kaynak kayıtlarının sonucun türetilmesine nasıl katıldığını cebirsel olarak temsil eder \[3]. *How-provenance* olarak anılan bu yaklaşımda, aynı sonucu üreten alternatif türetmeler ile birlikte kullanılması gereken kayıtlar ayırt edilebilir. Çalışmanın temel cebirsel çerçevesi, pozitif ilişkisel cebir sorgularına dayanır; bunu bütün veri işleme süreçlerini kendiliğinden açıklayan genel bir çözüm gibi değerlendirmemek gerekir.

Bu ayrımlar, bir sonucun kaynağını bilmenin farklı ayrıntı düzeyleri olduğunu gösterir. Bazen dosyayı tanımak yeterlidir. Bir hatanın nedenini araştırırken ise belirli bir hücrenin veya sonuç kaydının dayanaklarına kadar inmek gerekir.

W3C PROV ile işlem geçmişini tanımlamak

Farklı sistemlerin provenance bilgisini paylaşabilmesi için ortak bir temsil gerekir. W3C’nin PROV ailesindeki kavramsal veri modeli PROV-DM, bu amaçla üç temel kavramı kullanır \[4]:

|Kavram|Ne ifade eder?|Örnek|

|Varlık (*entity*)|Hakkında köken bilgisi tutulan şey|Ham veri dosyası, temizlenmiş tablo, rapor|
|Faaliyet (*activity*)|Varlıkları kullanan veya üreten süreç|Tekrarları ayıklama, hesaplama, görselleştirme|
|Aktör (*agent*)|Bir faaliyete veya varlığa ilişkin sorumluluk taşıyan kişi, kurum ya da çalışan yazılım|Analist, araştırma ekibi, otomatik işleme yazılımı|

Bu modelde bir hesaplama faaliyeti belirli bir veri dosyasını kullanır ve bir sonuç tablosu üretir. Sonuç tablosunun girdiden türediği, faaliyetin hangi aktörle ilişkili olduğu ve işlemin zamanı ayrıca belirtilebilir. Böylece “raporu ekip hazırladı” ifadesinin yanına, raporun nasıl üretildiğini incelemeyi sağlayan ilişkiler eklenir.

PROV, kayıtların ifade edilmesini sağlayan bir modeldir. Kayda geçirilmemiş bir işlemi kendiliğinden keşfetmez veya yazılan açıklamanın gerçeğe uygunluğunu garanti etmez. Bu nedenle temsil biçimi kadar, bilgilerin nasıl toplandığı da değerlendirilmelidir.

Yüzde 12’nin işlem geçmişi

Girişteki örneği ayrıntılandıralım. Aşağıdaki sayılar yalnızca konuyu açıklamak için oluşturulmuştur; gerçek bir araştırma bulgusu değildir.

Bir öğrenci anketinden 1.000 başvuru kaydı geldiğini varsayalım. Önceden belirlenmiş kurala göre, aynı katılımcının birden fazla başvurusunda yalnızca son başvurusu tutuluyor ve 100 tekrar kayıt çıkarılıyor. Kalan 900 kişinin 100’ü ilgili soruyu yanıtlamamış. Soruyu yanıtlayan 800 kişinin 96’sı hizmetten yararlandığını belirtiyor. Yanıt verenler içindeki kullanım oranı, 96/800 hesabıyla yüzde 12 oluyor.

Bu oranın provenance kaydı, yalnızca anket dosyasının adresini içermemelidir. Hangi dosya sürümünün kullanıldığı, tekrarların nasıl belirlendiği, eksik yanıtların hangi aşamada çıkarıldığı ve hesabın hangi kodla yapıldığı da belirtilmelidir.

Raporda “Öğrencilerin yüzde 12’si hizmeti kullanıyor” yazılması ise ayrı bir sorundur. Hesap, ilgili soruyu yanıtlayan katılımcılara aittir. Bu grubun bütün öğrencileri temsil edip etmediği, örnekleme ve yanıtsızlık bakımından ayrıca incelenmelidir. Provenance, paydanın neden 800 olduğunu görmemizi sağlar; örneklemin temsil gücünü kendiliğinden sağlamaz.

Ayrıca aynı ham dosyadan farklı bir sonuç üreten ikinci analizi düşünelim. Farkın bir hesaplama hatasından mı, tekrarları ayıklama kuralından mı, yoksa başka bir dosya sürümünden mi kaynaklandığı ancak bu ayrıntılar karşılaştırıldığında anlaşılabilir.

Bir verinin kaynağını araştırırken nasıl ilerleriz?

Kaynak araştırmasında hem yayımlanmış belgeleri okumak hem de eldeki sonucu sınamak gerekir. W3C’nin *Data on the Web Best Practices* belgesi, veri kökeninin açıklanmasını, sürüm bilgisinin belirtilmesini ve sürüm geçmişinin sunulmasını ayrı öneriler olarak ele alır \[5]. Küçük bir projede bu ilkelerden hareketle şu çalışma sırası izlenebilir:

Önce incelenecek iddiayı kesinleştirin. “Hizmet kullanım oranı” ifadesi yeterince belirli değildir. Oranın hangi döneme, hangi gruba ve hangi soruya ait olduğunu yazın. Orijinal soru metnini ve kullanılan tanımı bulmak, sayısal karşılaştırmadan önce gelmelidir.

Veriyi üreten kişi veya kuruma doğru ilerleyin. Bir grafikten rapora, rapordan veri tablosuna ve mümkünse toplama yöntemine ulaşın. Paylaşımı yapan platformun açıklamalarını, veri sözlüğünü ve yöntem eklerini inceleyin. Aynı sayının birçok sitede bulunması, bu siteler aynı kaynağı tekrar ediyorsa bağımsız doğrulama sağlamaz.

Kullanılan sürümü belirleyin. Erişim tarihi ile verinin yayımlanma veya revizyon tarihi farklıdır. Kaynak adresinin yanında sürüm numarasını, ilgili tabloyu ve uygulanan filtreleri kaydedin. Bir API’den veri çekiliyorsa isteğin parametrelerini de saklayın. Aksi hâlde aynı adrese daha sonra yapılan başvuru, önceki analizin girdisini vermeyebilir.

Dönüşümleri yeniden kurun. Birim değişikliklerini, birleştirme anahtarlarını, dışlanan kayıtları, eksik değer işlemlerini ve hesaplama kurallarını araştırın. Anket örneğinde tekrar kayıtları çıkarmak ile eksik yanıtları çıkarmak farklı işlemlerdir. Bunların hangi sırayla uygulandığı da kaydın parçası olmalıdır.

Sonucu yeniden hesaplayın ve belirsizliği belirtin. Ulaşabildiğiniz girdilerle aynı değeri üretmeyi deneyin. Sonuç farklıysa yuvarlamayı, filtreleri ve sürümleri karşılaştırın. Ham kayıtlara erişilemiyorsa incelemenin hangi düzeyde kaldığını açıkça yazın. Yayımlanmış bir tablodaki hesabı doğrulamak, o tablonun dayandığı ölçümleri doğrulamakla aynı kapsamda değildir.

Bu süreç her zaman ilk ölçüme kadar ulaşmayabilir. Belgelerin eksikliği, erişim kısıtları veya kaybolmuş sürümler nedeniyle bazı bağlantılar kurulamayabilir. Böyle durumlarda eksik halkaları tahmin ederek doldurmak yerine, hangi ilişkilerin belgelenebildiğini göstermek gerekir.

Kendi projelerimizde hangi kayıtları tutmalıyız?

Kaynağı araştırırken ihtiyaç duyduğumuz bilgiler, kendi çalışmamızı başkasına devrederken sunmamız gereken bilgiler için de iyi bir başlangıçtır. Bir öğrenci projesinde bunun için kapsamlı bir altyapı kurmak şart değildir. Ham girdiyi korumak, dönüşümleri kodla tanımlamak ve çalıştırma bilgilerini kaydetmek uygulanabilir ilk adımlardır.

Anket örneği için önerilen kayıt seti şöyle olabilir:

|Kayıt|Yanıtlaması gereken soru|

|Kaynak ve sürüm bilgisi|Hangi anket çıktısı kullanıldı?|
|Veri sözlüğü ve soru metni|Alanlar ve yanıt seçenekleri ne anlama geliyor?|
|İşleme kodu ve parametreler|Hangi kayıtlar, hangi kuralla elendi?|
|Ara çıktılar ve kayıt sayıları|Her aşamada kaç kayıt kaldı?|
|Kod sürümü ve çalışma ortamı|Hesap hangi kod ve yazılım sürümleriyle yürütüldü?|
|İşlem zamanı ve sorumluluk bilgisi|Çalıştırma ne zaman, kim tarafından yapıldı?|

Bu tablo, örnek proje için bir öneridir; bütün alanlar için zorunlu ve yeterli bir standart değildir. Makine öğrenmesi çalışmasında buna eğitim-test ayrımı veya rastgelelik ayarları gibi bilgiler de eklenebilir. Gerekli ayrıntı, yeniden yapılmak istenen işlemin kapsamına göre belirlenmelidir.

Daha büyük veri akışlarında bağımlılıkların otomatik kaydı yardımcı olabilir. Örneğin OpenLineage’in sütun düzeyindeki lineage modeli, çıktı sütunlarının hangi girdi sütunlarına dayandığını ve dönüşüm ilişkilerini ifade eder \[6]. Böyle bir kayıt, rapordaki alanın hangi girdilerden üretildiğini araştırmayı kolaylaştırır. Yine de kullanılan entegrasyonun hangi işlemleri yakalayabildiği kontrol edilmelidir.

Veri setinin kullanım bağlamı da işlem geçmişini tamamlar. Gebru ve arkadaşlarının *Datasheets for Datasets* çalışması; veri setinin oluşturulma amacı, bileşimi, toplama süreci ve önerilen kullanımları gibi konuların belgelenmesini önerir \[7]. Böyle bir açıklama, veri setinin hangi araştırma sorularında kullanılabileceğini değerlendirmeye yardımcı olur.

İzlenebilirlik bize neyi söyleyebilir?

FAIR ilkeleri, araştırma verilerinin bulunabilir, erişilebilir, birlikte çalışabilir ve yeniden kullanılabilir olmasını hedefler. İlkelerin R1.2 maddesi, veri ve üst verilerin ayrıntılı provenance bilgisiyle ilişkilendirilmesini öngörür \[8]. Köken bilgisinin yeniden kullanımla bağlantısı açıktır: Başka bir araştırmacı, verinin hangi koşullarda üretildiğini bildiğinde onu kendi sorusu için daha sağlıklı değerlendirebilir.

Ancak belgelenmiş bir süreçte de ölçüm hatası, seçim yanlılığı veya yanlış tanımlanmış bir gösterge bulunabilir. Hatta hatalı bir hesap, yeterince ayrıntılı kaydedilmişse aynı biçimde yeniden üretilebilir. Bu yüzden bir analizin yeniden çalıştırılabilmesi ile bilimsel olarak geçerli olması ayrı ayrı incelenmelidir.

Bir verinin gerçek kaynağına ulaşmak, o verinin üretimine ilişkin hangi iddiaların kanıtlarla desteklendiğini ortaya koymayı gerektirir. Çalışmanın sonunda elimizde kaynak adresiyle birlikte kullanılan sürüm, uygulanan işlemler ve açıklanamayan noktalar bulunmalıdır. Başka bir araştırmacı bu kayıtlarla sonucu denetleyebiliyor ve nerede ek bilgi gerektiğini görebiliyorsa, provenance bilgisi işlevini yerine getiriyor demektir.