Openid Ve Kimlik Yönetimi

Web 2.0 ile birlikte kullanılmaya başlayan web site ve servis sayısının artmasıyla birlikte kimlik yönetimi konusunda bazı sıkıntılar oluşmaya başladı. İlk sıkıntı her site için profil bilgilerinin doldurulma zorunluluğu. Diğer sıkıntı ise tüm bu servisleri kullanmak için oluşturduğumuz kullanıcı adı ve şifrenin akılda tutma zorunluluğu. İlk madde bir nevi tembellik olarak düşünülse bile bence ikincisi çok ciddi bir problem. Eğer servisleri aynı yerden alıyorsanız bunu tek kullanıcı hesabıyla yapmak mümkün. Örneğin google hesabıyla gmail, gtalk, analytics, blogger gibi hizmetlerden yararlanabilirsiniz. Bunun için yerli pilli network ü de örnek olarak gösterebiliriz.

Openid tamamen bu ihtiyaca cevap vermek üzere uygulamaya konulmuş bir yaklaşım. Özetle siz bir Openid servis sağlayıcısından bir hesap yarattıktan sonra openid desteği olan herhangi bir siteye bu hesapla login olabilirsiniz. Teknik altyapısı ise; istenilen siteden openid servisine yönlendirilip login işlemi yapıldıktan sonra bu oturumun tekrar ilgili siteye geri dönülerek açılması. Kendi sitenize bu desteği eklemek için .net proje örneğine buradan ulaşabilirsiniz.

Yahoo,Amazon,AOL,Wordpress gibi çok sayıda bilinen servis sağlayıcı ücretsiz olarak kullanılabilir. İlgili hesaplardan hangi site ile hangi bilgilerin paylaşılacağı ayarlarını yapmak mümkün. Openid desteği veren yerli örneklere şu an için rastlamasam da yakın zamanda belli başlı sitelerin bu desteği vereceğini öngörüyorum.

Openid nin yaratıcısı Brad Fitzpatrick' e göre;
"Hiçkimse bu bilgilerin sahibi olmamalıdır ve hiç kimse bu bilgileri kullanarak para kazanmayı planlamamalıdır."

Bu cümlelerden de openid nin getirdiği kullanım kolaylığının yanısıra kullanıcı veritabanı ile ilgili pazarlama anlamında bir davranış değişikliğinden söz etmek mümkün. Biraz da site sahibinin avantajlarını azaltıcı olarak düşünülebilir.

2007 ortasında kurulan Openid Foundation ın kurumsal üyelerinin Google, IBM, Microsoft, VeriSign, Yahoo olması Openid nin önemi konusunda bir fikir vermekte.

Yeni Medya : Yazılım

Microsoft'un Yahoo'ya önerdiği teklif üzerine yapılan yorumlar arasında Forbes'ten Nicholas Carr'in "yazılım yeni bir medya oluyor" şeklinde bir değerlendirmesine rastladım. Özetle web uygulamalarının geçirdiği süreçten , içerik ve kullanıcı yönetimindeki yeniliklerden bahsetmiş. Artık ölçümlemenin her şey olduğuna da vurgu yapmış.

Önceki yazılarımda web yaklaşımlarının değişmesiyle yazılımın ve yazılımcının rollerinin değiştiğinden bahsetmiştim.

Bu konuya farklı bir açıdan bakarak, Web e yön veren 3 örneği incelersek;

Google : Şu an bulunduğu konuma geliştirdikleri arama algoritmaları sayesinde gelmişlerdir.
Amazon : Kitap satışıyla başlayan serüvenleri yaptıkları başarılı veri madenciliği yöntemleri sayesinde satışlara yansımış ve bir örnek teşkil etmiştir
Facebook : Daha önce onlarca büyük sosyal ağ platformu olmasına rağmen, facebook üzerine uygulama geliştirme ve kullanıcı için yaptıkları veri madenciliği yöntemleriyle aradan sıyrılmıştır.

Web girişimlerinin başarılarını değerlendirdiğimizde uzun ve detaylı bir süreçten bahsedebiliriz. Fakat yukarıdaki örneklerden yola çıkarak rekabet ortamında farkın yazılım odaklı yaklaşımlarla yapıldığını söylemek çok da yanlış olmaz. Bu 3 örnek için de yazılım dışındaki yöntemlerle başarıyı yakalamak pek de mümkün görünmüyor. Burada bir yanlış anlaşılmayı önlemek adına bir parantez açmak istiyorum. Bu 3 örnek için de yazılım ilk kurşun niteliğinde önemli bir unsur olmuştur ama başarı diğer etkenlerin katkısıyla gelmiştir.

Yazılımın yeni bir medya olmaktan öteye medyayı yönlendirici bir etken olduğunu söylemek sanırım daha doğru olur. Amerika'da şu an 40 milyar dolar olan online reklam pazarının 2008'de 80 milyar dolar olacağı öngörülüyor. Ülkemizde de 2008 içerisinde bu oranda bir artış olmasını öngörürsek ve bir online mecranın da uygulanan yazılım yöntemleri etkisiyle başarıya ulaştığı örneklerinden yola çıkarsak yazılımın bu pazar payında etkileyici unsur olduğunu söylemek çok da yanlış olmaz.

Yazılım Geliştirme Motivasyonu

İşletmelerde başarıya giden yoldaki parametreler büyük ölçüde yaptığınız işle alakalıdır. Kimi için tek müşteri hayati önem taşır, kimisi için bir makina, kimisi için sıcak para, kimisi için güvenlik. Bunların yanında çalışan verimliliği de yine yapılan işe göre gerekli oranlarda önem arzetmekte.

Yazılım üretme gibi insan odaklı işlerde ise eğer belli standartlara sahipseniz başarı, başarısızlık, çok para kazanma veya batma gibi olayların en büyük nedeninin insan kaynağı olduğunu söyleyebiliriz. Bununla beraber verimlilik konusunda tüm çalışanlara uygulanan yöntemlerden bağımsız yazılıma özel (hatta kişiye özel) çeşitli teknikler geliştirmek gerekir.

Sadece kendi deneyimlerim ve gözlemlerime dayanarak bazı farkları listeledim;

• Sihirli zamanların yakalandığı bir 5 dakika 2 günlük çalışmadan daha etkili olabilir.
• 5 günlük iş planını 4 güne sığdırıp bitirmek 7 güne yaymaktan daha doğru olur.
• Çalışma isteği olmadan yazılan kodun faydadan çok zararı olacaktır
• Yazılımcının eğitimi için ayrılan zaman ve para herhangi bir projede zaman veya para olarak kat kat geri dönebilir.
• Proje maliyeti yazılımcı seviyesine göre (hatta aynı seviyedeki 2 yazılımcı arasında bile) çok farkedebilir.
• Yazılımcının çalışıp çalışmadığını kontrol etmek çok zordur.
• Yazılımcı aynı motivasyona sahip olsa bile projenin ilerleyen dönemlerinde verim proje başına oranla düşer
• Klasik verim alma veya baskı yöntemleri ters tepebilir
• Birikimli bir yazılmcının en büyük silahı o işi yapmak istemesidir.

Note : This picture has been taken from http://www.funtoosh.com/ web site.

Web 1.0'ı Tekrar Hatırlamak

Web 3.0'ın konuşulduğu web 2.0'ın olgunlaştığı bir dönemde yerel hedefli uygulamalar arasında bence en dikkat çekici olanı bir web 1.0 uygulaması. Uzman Tv 'nin çok yeni olmasına rağmen ciddi bir boşluğu doldurduğunu söyleyebilirim.

Bu projeyi 2 açıdan değerlendirmek gerekiyor. Birincisi interneti günün büyük bir kısmında kullananlar için artık faydalı bir şeyler yapma zorunluluğunun doğması. Özellikle facebook la birlikte insanlar saatlerce benzeri sitelerde zaman geçirmekte ve bir süre sonra bu sadece vakit kaybıyla sonuçlanmakta.

İkincisi web 2.0 konseptinin en önemli özelliği olan içeriğin kullanıcı tarafından oluşması.Bu kategorideki sitelerin yaygınlaşmasıyla birlikte internet içeriği ciddi bir biçimde arttı. Veri doğruluk oranının değişmediğini varsaysak bile içeriğin artmasıyla yanlış bilgi sayısı hızla arttı. Viki tarzı uygulamalarda yanlış içerik diğer kişiler tarafından düzeltilse bile yine de kuşkuyla yaklaşmak olası. Popüler bir örnekten yola çıkmak gerekirse; Avrupa Yakası'yla gündeme daha çok gelen Engin Günaydın'ı bazı içeriklerde Erol Günaydın'ın oğlu olarak bulabiliriz. Ülkemizde sıkça raslayabileceğimiz amatörce yönetilen ve içeriğin uzmanlık alanları sınırlı ve düşük profilli kişiler tarafından oluşmasıyla aslında bir bilgi çöplüğü oluşmaya başladı. İçeriğin kullanıcı tarafından yaratıldığı sistemlerde içeriğin kısmen subjektif yorumlarla oluşma riskini de arttırdı.



Geçtiğimiz günlerde Google tarafından betaya sunulan ve wikipedia ya rakip olarak lanse edilen KNOL projesi de aslında benzer bir amaca hizmet ediyor. Yani içeriğin konunun uzmanları tarafından girilmesi.

Aslında bu süreci teknik anlamda web 2.0'ın bol içerik konseptiyle birlikte büyük dataların yönetimi ve kullanılmasıyla ilgili tekniklerin denendiği geçiş süreci olarak değerlendirebiliriz. Zamanla çoğu doğru çok sayıda içeriğin yerini, tamamen objektif çok sayıda içeriğin alacağı bir döneme giriyoruz.

İnternetin iletişim ve bilgi bulma anlamındaki en büyük eksiği olan bilgi doğruluğu problemi de zamanla aşılaşacağa benziyor.

Sonuç olarak daha önceki yazılarımda da değindiğim şekilde; web veya benzeri standartları, bazı ihtiyaçlardan yola çıkılarak düzenlenen ve kullanım doğruluğu kullanıldığı zamana göre değişen disiplinler olarak düşünebiliriz. Yani projeleri modayı takip etmek adına belli standartlara uydurmak "millet alışverişte görsün" davranışından öteye geçemeyecektir.

Bir Delinin Hatıra Defteri

Gogol'un "Bir Delinin Hatıra Defteri" oyununu tekrar okurken Gogol'ın Google a kelime olarak çok benzediğini farkettim. O anda kafamda 20 yıl sonra yazılacak bir başarı (veya sonradan başarısızlık) öyküsünün ismi belirdi. "Google,İki delinin hatıra defteri". Şu an bile aslında Google için yazılmış başarı öyküsü veya firma hikayesi şeklinde çok sayıda kitap var. Belki de şu ana kadar yazılanlar o kitap için bir önsöz niteliğinde kalacak. Zaten adı üstünde anı kitabı, tahmin yürütmeye gerek yok.

Google'ın iş yaşamında bir devrimin öncüsü olduğunu kabul edersek, aslında iki deli tanımlaması çok da uzak olmaz. Peki delilik nedir veya iş yaşamında fark yaratmak için illaki deli mi olmak gerekir? Aslında ikisinin de deli kalıbına pek uymayacağını söyleyebiliriz fakat bu süreçteki bazı tercihler biraz delilik gerektirmiştir.

Ben fark yaratmanın normalin üstü ve dahilik arasında bir yerde olduğunu düşünüyorum. Yani kesinlikle ezber bozacaksınız ama bu ezberi yani şu anki genel yaşanan hayatı uzaktan da olsa göreceksiniz. Bu tanım aslında kendi konumumla da çok alakalı olan internet girişimlerinde başarılı olmak konusuna uygun düşmekte. Aslında Google kesinlikle donanım ve yazılım anlamında bazı disiplinleri bir araya getirmiştir. Fakat daha farklı olarak Facebook benzeri girişimlere baktığımızda bunu tam anlamıyla söylemek zor. Kesinlikle farklı kurgular ama sosyolojik ve psikolojik boyutlarıyla de düşünülmüş yapılar. Aslında deli veya dahi olarak tanımlayabileceğimiz kişilerin de genel olarak az alanda kendini aşmış ama diğer alanlardan tamamen kopmuş olduğunu söyleyebiliriz. Farklı olmak ikisinin ortasında bir noktada kesişiyor: Hayatı çok iyi bilen ama ezber bozan.

Anı kitabı yazmak herkesin yaptığı bişey. 40 yıllık bir yönetmenden tutun meşhur olmak için memleketini terkeden şöhret adayına kadar. Aslında herkesin yazılacak bir hikayesi var. Kendileri veya başkaları tarafından.

Belki de günün birinde Sergey ve Larry'nin yolları ayrılır ve bu kitap birisi tarafından "Bir Delinin Hatıra Defteri" olarak yazılır. Kalan mı daha deli olur yoksa giden mi bunu kestirmek zor :)

2007'nin Bıraktıkları

Blog okuyanlar mutlaka yaşamıştır. Tesadüfen bir kaç ay önce yazılmış gündemle alakalı bir yazıya rastlarsınız. Yazı derinlemesine yazılmış ve onlarca yorum yapılmıştır. Konunun sıcaklığı geçip bir de aradaki geçen zamanın olgunluğu eklendiğinde yorumlar biraz daha duru bir şekilde olur. Ama blogların dinamikleri itibariyle o kadar eski bir yazıya yorum yapamazsınız. Ama insan kendi yazdığı yazıya yorumlar ve eklemeler yapabilir galiba :) Ben de bu kategoriye giren bir kaç yazı seçtim bir kaç küçük ekleme yapmak istedim.

Veritabanı ve Pazarlama
İnternetin pazarlama faaliyetlerinde kullanılmaya başlanmasının ülkemiz için yeni olduğunu söyleyebiliriz. Bilgi toplama konusunda zamanla daha doğru düzgün yöntemler kullanılmaya başlanıyor. Ama hala buradaki en ciddi problem bu tarz işlerin teknik olmayan veya yeterli düzeyde donanıma sahip olmayan kişiler tarafından üstlenilip yönlendirilmesi.

Web 3.0 ve Servis Odaklı Mimari
Burada tekrarlamak istediğim şey, bu standartların bir moda gibi düşünülüp kendi başında değerlendirilmemeleri. Kullanım alanına uygun olarak bu parçalardan doğru olanları uygulamalara yerleştirmemiz.

Web 3.0 yazılımcısı olmak
Artık kaliteli uygulamalar için web platformunda web yazılımcılarının değil daha nitelikli yazılımcıların çalışması gerektiğinden bahsetmiştim. Aslında o günlerde piyasada nitelikli yazılımcı bulmanın zorlaştığı bir döneme girdik. Böyle bir ortamda bu ne kadar mümkün olacak tartışılır.

Programlanabilir Web
Google'ın Open Social ile Facebook un karşısındaki gövde gösterisi Türkiye için kayda değer bir sonuç vermedi aslında. Facebook için geliştirilen uygulamalar hızla artıyor. Zamanla artık ayakta kalabilen saman alevi gibi olmayan uygulamarın daha revaçta olacağını düşünüyorum. Ama bunun da ne kadar süreceğini yine bekleyip göreceğiz.

Herkese mutlu yıllar :)

Veritabanı İsimlendirme Kuralları

Kod yazma standartlarında bazı isimlendirme notasyonları kullanılmaktadır. Database nesneleri için de bazı standartlar önerilmekte. Aşağıda bu standartları derleyip kendi yorumlarıma göre değiştirerek bir kaç madde listelemeye çalıştım. İsimlendirmede genel olarak Pascal Case kullanılmaktadır.

Tablo isimlendirmesi:

• Tablo isimleri çoğul olmalıdır şeklinde bir kural var. Fakat çift kelimeli tablolar kullandığımızda bir sıralama problemi yaşamamız mümkün. Yani Users ve UserAnswers şeklinde bir sıralamada UserAnswers daha önde olur. Bu yüzden şahsi görüşüm temel tabloları tekil olarak isimlendirmenin daha doğru olduğu yönünde.

• Birden fazla kelimeli tablo isimlerinde sadece son kelime çoğul olmalıdır. Örneğin UserAnswers.

• tbl gibi bir prefix hiç bir anlam ifade etmediği için kullanılmamalıdır. Prefix olarak projenin kısaltılması kullanılabilir. Örneğin Google Analytics projesi için GaUser şeklinde bir isimlendirme olabilir.
  

• Tablo isimlerinde _ kullanılmamalıdır
  

• SQL cümlelerinde SQL terimlerinin tamamı büyük harfle kullanılmalıdır
  

• Developer dışında kişilerin de database i kullanma ihtiyacı olacağı için hiç bir kısaltma kullanılmamalıdır
  

• Çoka çok ilişkilerde iki tablo ismi de çoğul kullanılması önerilir. Ama son kelimenin çoğul kullanılma kuralı ile karmaşa yaratacağı için bu durumda da son kelimeyi çoğul olarak kullanmak daha tutarlı olacaktır. Örneğin EmployeeCustomers

Kolon isimlendirmesi

• User tablosu için UserId alanı key alan için kullanılabilir. Fakat SQL Server'da I küçük harfle i nin karşılığı olmadığı için dilimize özgü olarak tüm Id ifadelerinin id olarak yazılmasını öneriyorum. Örneğin Userid,Cityid.
  

• Yabancı anahtarların isimleri ana tablodaki alan isimleriyle aynı olmalı. Örneğin City tablosunda alan Cityid olarak kullanıldıysa id değerin tutulduğu User tablosunda da Cityid olarak kullanılmalıdır.
  

• Birden fazla alanın PK olduğu tablolarda id isiminde bir alan kullanılmamalıdır.
  

• Kolon isminde kln, fld gibi prefixler kullanmak gereksizdir. Sadece alan IntUserid şeklinde alan tipi prefix olabilir ama bu da pek önerilen bir şey değildir.

View isimlendirmesi

• Vw prefix iyle başlamalıdır.

• İki tablo join edilerek bir view oluşturuluyorsa isimde iki tablo da kullanılmalıdır.

SP isimlendirmesi

• Create,Get,Update,Delete,Set gibi fiil ifadeler isimde prefix olarak kullanılabilir. Örneğin GetUserInformation.

• "sp_", "xp_" veya "dt_" gibi prefixler kullanıldığında önce master tabloya bakılıp aranacağı için bir performans kaybı yaratır. Kesinlikle kullanılmamalıdır.

Full Text Index

Yoğun sorgulamalarda indeksler bize performans artışı sağlar. Fakat klasik indeksleri her alan tipi için kullanamayız. Text ağırlıklı alanların indekslenmesi için Sql Server üzerinde Full Text Search isimli ekstra bir servis bulunmakta. CHAR, NCHAR, VARCHAR, NVARCHAR, TEXT, ve NTEXT alanları indekslenmesini sağlamakta. Tek şart bu indeksin yapılacağı tabloda bir tane tekil alan bulunması.

Full Text Search servisinin algoritmasına ulaşamadım ama tahminimce bu tekil alanla birlikte varolan text ifadenin kelimeler olarak farklı satırlara bölünmesi şeklinde.
Yani

1, "bugün hava güzel"

şeklinde bir kayıt varsa bu kayıt

1, "bugün"

1, "hava"

1, "güzel"

şeklinde 3 kayıt olarak eklenir ve diğer satırlarla birlikte text alan üzerinde tekrar bir indeksleme yapılır. Eğer "bugün" kelimesini sorgularsak direk indekslenmiş datadan sonuç gelir ve içinde "bugün" geçen kayıtlar kolayca bulunabilir. Biz de aslında bu mantıkla kendimize özel servisleri yazabiliriz. Bu şekilde algoritma sadece kendi isteğimize cevap vereceği için daha fazla performans yakalayabiliriz. Tabii ki database sistemleri kendi algoritmalarında sistem üzerindeki kendi nimetlerinden faydalanmakta.

Bir Full Text Index tanımlamak için öncelikle Database-Storage altında yeni bir Full Text Catalog oluşturulur.Database özelliklerinden Files sekmesinde "Use full-text indexing" seçeneği aktif hale getirilir.İstediğimiz kolon üzerinde sağ tuş ile FullText Index ekleyebiliriz.

FREETEXT

FREETEXTTABLE

CONTAINS

CONTAINSTABLE
şeklinde 4 kullanımı var.

SELECT testtable

FROM textcolumn

WHERE FREETEXT (textcolumn, 'bugün' )

textcolumn kolonu üzerinde "bugün" geçen tüm kayıtları listeleyebiliriz. Diğer komutlarla daha farklı seçenekler mevcut.

Programlanabilir Web

Facebook'un bu kadar hızla hayatımıza girip kullanıcı ve altyapı bazında bazı devrimler yaratmasıyla birlikte aslında web 3.0 ın programlanabilir web standartı yavaş yavaş yaygınlaşmya başladı. Web 3.0 yazılımcısı profilinde olabilecek değişikliklerden bahsetmiştim. Google'ın facebook a karşı oluşturduğu OpenSocial'da facebook tan daha rahat bir geliştirme ortamı sunacakları vaad ediliyor. FBML gibi ekstra kuralları öğrenmenin gerek olmayacağı gibi. Tabii ki diğer sosyal ağ ve benzeri platformların rekabet ortamı için bunu yapması kaçınılmaz gibi görünüyor.

Çok geriye gitmeden herhangi bir web tabanlı uygulamasında döviz bilgilerini göstermek için harcadığımız çabayı ele alalım. Bir bankadan bu bilgiyi almamız arada bir iş ortaklığı yoksa hala zor gibi görünüyor. Burada aslında kritik nokta verinin değerli olmasıydı. İçerik sağlayıcı bu içerik için bir maliyet harcıyor ve doğal olarak bunu ücretsiz vermiyordu. Web 2.0 ın içeriği kullanıcının yaratması özeliğiyle aslında maliyeti çok da fazla olmayan bir veri topluluğuna sahip olunabiliyor.

Bir facebook uygulamasından örnek verelim. Siz benim yazdığım bir facebook uygulamasını kullanmaya başlarsanız ben geliştirici olarak sizin ve arkadaşlarınızın profil bilgilerini alabiliyorum. Burada insanların facebook kullanırken açık olma özelliğini varsayarsak bu ayrıntı çok da önemli değil. Yani CRM kapsamında insanların çok büyük maliyetlerle elde ettiği profil bilgilerine ulaşmak mümkün oluyor. Bunu sadece sosyal ağ ile sınırlandırmazsak business anlamında çok daha fazla açılım yapması muhtemel görünüyor.

İdris Cin'in belirttiği şekilde sadece programlanabilir web uygulamaları için uygulama geliştiren yazılımcılar oluşmaya başlayacak. Diğer taraftan veriyi elde etme maliyetlerinin düştüğünü varsayarsak bu verilerin bilgiye dönüşme ve bunların gerçek uygulamalarda bir aksiyon olarak kullanılma konusu daha da önem kazanacak. Aslında şu aralar her şeyin daha hızlandığı ve belirsizliğin arttığı, stratejilerin anlık olarak değişebileceği bir döneme giriyoruz. Daha fazlasını bekleyip göreceğiz.

Assocıatıve (Çağrısımsal) Model Database

Web 3.0 'ın mimari anlamındaki yaklaşım değişikliğinden ve semantic web kavramının merkezine yerleşmesinden bahsetmiştim. Bir database mimarı veya tasarımcısının web 3.0 ile birlikte bir takım değişikliklere maruz kalması muhtemel. Veritabanı sistemlerinde köklü bir değişliklik olan ilişkisel veritabanı tasarımının yerini web 3.0 da associative (çağrışımsal) model tasarıma kısmen bırakabileceğini söyleyebiliriz.

Aslında ilişkisel veritabanı modelinin daha katı kuralları olan ve net veriler söyleyen bir model olduğunu söyleyebiliriz. Semantic web in doğası da aslında metadataya (veri hakkında veri) dayanmakta. Yani herşeyin siyah ve beyaz olmayıp gri tonların değerlendirilmesi; bir nevi bulantık mantık yaklaşımı.

Bir giriş niteliğinde fikir oluşması açısından Mike Griffiths 'in 2001 yılında yazdığı makaledeki örnekler üzerinde duracağım.

Verilerimiz aşağıdaki cümleler olsun.

"Red is a Colour"
"Mary is a Vegetarian"
"Vegetarians eat Plants"
"Cardiff is located in Wales"
"Wales is part of the UK"

Bu verileri ilişkisel bir veritabanında tutmak isteseydik çeşitli unsur tablolarına ve özelliklerinin tutulacağı ilişkisel tablolara ihtiyaç duyacaktık. Ama 5 cümlenin de birbirinden alakasız fiil ve özellikler içermesi sebebiyle ilişkisel model bir hayli zahmetli olacaktı.

Associative model kullanarak bu cümleleri saklamak istediğimizde 2 tabloya ihtiyacımız olacak. İlki nesne, fiil ve özelliklerin saklandığı Items tablosu, İkincisi ise bu item ların ilişkilerinin tutulduğu Links tablosu

Items

Items (1. tablo)

Identifier Name (Tablo alanları)
12 Red
41 Is a
76 Colour
14 Mary
81 Vegetarian
43 Eats
82 Plants
15 Ski Lessons
39 Start at
83 08:00
42 On
85 Sunday


Links (2. tablo)

Identifier Source Verb Target (Tablo alanları)
101 12 41 76
103 14 41 81
124 81 43 82
105 15 39 83
107 105 42 85

Burada göze çarpan en önemli nokta link tablosundaki bir elemanın farklı bir elaman içerinde bir kaynak olarak kullanılabilmesi. Verileri dikkatli bir şekilde incelediğinizde sanırım bu model hakkında bir miktar fikir sahibi olacaksınız.

Note:This picture has been taken from flickr.