[RDF] [Fwd: Warum WRAF]

Tue, 01 Aug 2000 13:24:37 +0200

Stefan Andersson wrote:
> 
> Problemet med att beskriva vad WRAF är och varför det är bra, grundas i
> att WRAF har evolverat ur många sinsemellan olika ambitioner. WRAF skall
> vara allt och inget. Här är en översikt över några av de saker WRAF är
> tänkt att beröra och lösa:
> 
> Semantisk webb:
> Webben (Internetdistribuerade HTML-dokument) var ursprungligen tänkt som
> en rymd där inte bara människor skulle kunna bearbeta information, utan
> där också maskiner (agenter) skulle kunna verka. Webben är idag helt
> anpassad för människa-människa kommunikation. Detta då innehållet är
> helt orienterat mot form och naturligt språk. Webben är fattig på
> strukturerad metadata, d.v.s. data om hur innehållet skall tolkas.
> XML är en reaktion på detta. XML innebär ett steg tillbaka mot
> ursprunget, SGML.
> 'Problemen' med XML är dock flera:
> * Uppdelningen i DTD och XML gör att det blir onödigt komplicerat att
> bygga schemamedvetna applikationer, d.v.s. applikationer som kan
> 'förstå' vad som är vad i ett dokument.
> * DTD:er talar dessutom bara om vad som är ett välformat dokument, den
> ger ingen ledtråd om vad de olika fälten är för något eller hur man
> skall hantera dem.
> * XML är i sig inte en standard för hur data skall markeras upp. Det var
> tänkt att applikationsutvecklare skulle utveckla egna 'scheman' (DTD:er)
> och utväxla dessa sinsemellan. Brokers, som t.ex. BizTalk och andra
> repositories var tänkta att fungera som schema-resolvers. Detta verkar
> inte ha slagit igenom, och det finns nu en mängd proprietära, sins
> emellan inkomplatibla scheman och DTD:er. En del av problemet är att XML
> och DTD inte har mekanismer för partiell substituering och överlagring -
> 'arv'.
> * XML klarar inte av att beskriva nätverksstrukturer, utan är i botten
> orienterad åt hierarkiska strukturer. Detta är en allvarlig nackdel, då
> de flesta objektkluster till sin natur är nätverk.

Hittills låter det som XML eller RDF.

Många på RDF-listan (speciellt i början) uttalade sådana tankar, som
att XML räcker.  Men det är två olika saker. XML är ett sätt att lagra
data.  RDF beskriver kopplingen mellan data. RDF kan använda XML för
själva datalagringen. RDF är så snarare en påbyggnad på
RDF. Ytterligare ett lager för att standardisera tolkningen och
möjliggöra kommunikation mellan data skapade för olika områden.

RDF har utformats för att lösa en rad problem:
  1. Utvecklingsbarhet: Scheman kan utökas på ett sätt att tidigare
     applikationer fortfarande kan använda dem.

  2. Återanvändning: Nya Scheman kan bygga på flera gamla.  Generella
     applikationer kan hantera och förstå det som är gemensamt även om
     de inte anpassats speciellt för det nya schemat.

  3. Sammankoppling: Det finns ingen heiarki som avgöra vem som får
     säga vad.  Alla kan utfärda metadata om en viss resurs. Inte bara
     resursens ägare.

> Lösning:
> Tanken är alltså att maskiner skall kunna kommunicera med varandra och
> nå en lösning på en given uppgift utan att människor skall behöva
> övervaka processen.
> Man skall alltså kunna fråga en generisk sökmotor (inferensmaskin) om
> den billigaste flygbiljetten mellan Göteborg och Tokyo tidigast datum x,
> senast datum y, och den skall svara på ett för människor naturligt sätt.
> Likaså att kunna se vad en viss författare har skrivit, och vad andra
> har kommenterat om det författaren har skrivit. Eller en lista över alla
> fakturor en viss kund har utestående, komplett med produktinformation
> tagen ifrån leverantörernas webbsajter. Eller sitta i Sverige och
> konfigurera en bil enligt vad som finns tillgängligt i Belgien, och få
> priserna i dollar.
> 
> * RDF är en öppen standard för att beskriva distribuerade generella
> nätverksorganiserade resurser, med en standardiserad XML-serialisering
> som universiellt utbytesprotokoll. Detta betyder inte att man måste
> satsa på RDF. En liknande ansträngning är t.ex. XML-Schema.
> * RDF är INTE ett sätt att modellera eller göra inferensen. Detta måste
> skötas av en applikation som förser Internet med 'intelligens'. Detta är
> en av komponenterna i WRAF. Ett frågespråk (modellerat i RDF) och en
> inferensmaskin kapabel att söka svar på frågan, och om den misslyckas,
> förklara varför och be människan om kompletterande information.
> 
> Se
> http://www.w3.org/DesignIssues/Semantic
> 
> Knowledge management/Content Management
> * Dynamisk, flexibel renderering (serialisering) av objekt givet
> kontext.
> Ur arbetet med Lotus Notes, Skolverket och andra CM-uppdrag, har jag
> dragit slutsatsen att man kan se på content ur två synvinklar:
> 
> 1. Som en avsändares presentation av ett objekt.
> 2. Som ett objekts presentation av sig själv.
> 
> Den första approachen symboliseras av den klassiska brochyren.
> Avsändaren bestämmer helt och hållet formen, och när objektinformationen
> väl konstruerats, finns det inte utrymme för att lägga till eller dra
> ifrån - push. Däremot har avsändaren full kontroll över form och
> budskap, och väljer helt information och kontext.
> 
> Den andra approachen symboliseras av den klassiska databasen. Här är
> avsändaren ett relativt neutralt datalager, som förväntar sig en fråga
> innan ett svar kan konstrueras - pull. Fördelen är flexibilitet för
> mottagaren, men i gengäld en minskad kontroll hos avsändaren.
> Möjligheten att förpacka budskapet vad gäller läslighet och
> upplevelsemässigt och att styra kontexten är begränsad.
> 
> Vad man egentligen vill ha är en tredje metafor som fungerar som en
> syntes av dessa två - en metafor som låter avsändaren och mottagaren
> konstruera upplevelsen tillsammans. Detta låter sig inte göras genom
> simpla variabler och boolska villkorliga hopp. Vad man behöver är en
> standard för att modellera content och SERIALISERING (rendering) av
> content.
> 
> Vad detta skulle ge, är att alla tjänster, inte bara de som
> implementerat support för det, kunde förse kunden med den informationen
> kunden vill ha, på det sättet kunden vill ha den. En syntes av
> avsändarens och mottagarens behov.
> 
> Om detta gjordes i t.ex. RDF som är en distribuerad lösning, skulle man
> kunna tänka sig att användaren skickar med en URL till sin
> definitionsfil. (Denna kan i sin tur bestå av en dynamisk servertjänst,
> villig att lyssna på mottagaren - servertjänsten kan vara en del av
> användarens browser...) I definitionsfilen definieras användarens
> preferenser, men inte bara i termer av variabler, utan i semantiskt rika
> termer, där termerna i sin tur kan definieras av en tredje part.
> Termerna KAN handla om preferenser, integritet och förutsättningar
> (bandbredd, skärmstorlek, et.c.) men också om vilken information som
> efterfrågas, hur den skall prioriteras och presenteras. (Presentera
> alltid personer med fullständigt namn och bild om det finns någon
> tillgänglig. Placera alltid bilden till vänster om fullständigt namn.)
> Då RDF understödjer arv, skulle användare kunna ärva från en grundprofil
> och förändra den efter hand.
> 
> En tjänst som 'metacrawler', t.ex. skulle helt enkelt bli obsolet,
> därför att alla sökmaskiner skulle kunna söka i alla andra sökmaskiner
> och presentera resultatet på ett enhetligt, personifierat sätt. De
> skulle också kunna vara relativt simpla. Alltså skulle man kunna ha en
> lokal sökmaskin - agent - i klienten. Eller på den närmsta servern om vi
> pratar tunna klienter.
> 
> En annan aspekt är den rena administrationen av content. Där finns
> mycket att göra. Målet är ju att content skall vara lika enkelt att
> administrera som det är att använda en ordbehandlare. Detta kan
> realiseras antingen genom ett intelligent, klientbaserat, gränssnitt -
> en plugin till browsern - eller genom ett intelligent, serverbaserat
> gränssnitt. I vilket fall behövs strukturer för metadata och arv - och
> ett beskrivningsspråk. Detta för att på ett enhetligt sätt kunna
> beskriva vilka operationer som är tillåtna var (på vilka objekt) - och
> för vem. Nästa generations CM. När jag nämner 'rekursion' sist i
> dokumentet, menar jag t.ex. att definitionen av formulären skall ske
> genom användande av formulär. (som i sin tur definierats med formulär
> et.c.)
> 
> Dynamisk och snabb applikationsbyggnad:
> Det finns ett antal irritationsmoment man råkar ut för när man
> programmerar webbapplikationer:
> * Det är ofta mycket struligt att lägga till och ersätta objekt under
> drift. Referenser blir ogiltliga och operativsystemet eller språkmotorn
> blir konfys.
> * Man implementerar samma funktionalitet gång på gång för olika
> komponenter.
> * Det blir allt mer uppenbart att den rådande paradigmen med
> programmering före användande i allt snabbare takt blir obekväm. Vad man
> vill kunna göra är att låta slutanvändare bygga ut systemet. Även med
> komponenter som ingen systemutvecklare ens tittat på. Exempelvis vill
> man kunna låta ekonomiavdelningen lägga till ett fält för 'andra
> mobiltelefon' istället för att behöva skriva det i ett 'övrigt'-fält.
> Det skall också kunna ske utan att behöva vänta på en systemutvecklare.
> Det skall kunna ske genom att ärva från redan etablerade applikationer.
> Se Lotus Notes, men tänk längre, mer extremt.
> * När Operativsystem, plattform, applikation och data alla har olika
> API, råkar man dels ut för att det man vill göra ibland inte går eller
> åtminstone är löjligt komplicerat - detta för att utvecklarna av
> komponenterna valt att exponera olika funktionaliteter i olika nivåer
> och med olika filosofier.
> * Inom ASP och elektronisk distribution av applikationer, finns en hel

Active Server Pages eller Application Service Providers?

> mängd problem vad gäller licensiering. Om man såg objektrymden som
> bestående av URI:er och cachade kopior av dessa URI:er, får man en
> struktur som lämpar sig mycket väl för administration av denna typen av
> distribuerade tjänster.
> Ambitionen är att WRAF skall ha ett mycket moget cache-system där cache
> är del av definitionen, inte bara för uppsnabbning, utan också just för
> att spåra utnyttjande, förändringar och uppdateringar.

Skulle du kunna utveckla det här?

> * Inom e-business har begreppet 'Trust' kommit att spela en nyckelroll.
> Inte bara 'trust' mellan människor och tjänster, utan mellan tjänster.
> För att kunna göra det behövs också ett sätt att kunna modellera 'trust'
> - vem som litar på vad i vilka avseenden och varför.
> 
> Alla dessa svårigheter ser jag hur man skulle kunna lösa smidigt genom
> en distribuerad applikationsarkitektur där objekten definieras i RDF och
> accessas genom HTTP och serialiserad RDF. Det finns visserligen t.ex.
> SOAP, men SOAP är _en_ XML-baserad implementation, som man måste göra en
> implementation för. SOAPs data och metadata är inte utbyggbar, vilket är
> hela poängen med RDF. MS sitter på SOAP och dikterar riktningen. Med RDF
> är alla fria att expandera. I viss mån på bekostnad av
> interoperabilitet. Men genom RDF har man åtminstone MÖJLIGHETEN att
> avvika, och det är relativt enkelt att bygga bryggor, om båda parterna
> pratar RDF. Speciellt då RDF som sagt är rikt på metadata, och byggt för
> inferens...
> 
> Distribuerade objektanrop:
> Visionen är att en given webbapplikation skall kunna utnyttja hundratals
> andra webbapplikationer på olika servrar runt om i världen för att göra
> det den är satt att göra. Hämta data såväl som utföra uppgifter. Tänk
> t.ex. om en söktjänst kunde slå i yahoo och dmoz för att få fram andra
> människors ranking och kombinera den med en maskinell ranking... Det
> finns COM+, SOAP, CORBA och HTTP som protokoll, men inga av dessa
> protokoll är tänkta att kunna göra något annat än att vara bryggor, och
> är därför slutna. COM/Corba är också svåra att skriva för utan kostsamma
> utvecklingsmiljöer och utbildning. De har också begränsade möjligheter
> till metadata, därför är det svårt att göra lösningar av typen 'leta upp
> ett objekt som vet något om hundar och be den tala om allt om golden
> retrievers'. Att kunna beskriva hundar och vad hundar inbegriper är inte
> en del av Corba, och kommer aldrig att vara det. Det finns också en
> mängd katalogtjänster med uppslagsspråk, men de är för inflexibla, för
> domäncentrerade.
> En annan aspekt av distribuerade objektanrop är att man vill kunna
> antingen skicka objektets svar (serversidefunktionalitet) eller själva
> objektet (klientsidefunktionalitet) beroende på uppgiftens resurstyngd,
> resultatets storlek och tillgänglig bandbredd. Här kommer det jag skrev
> om ASP in... en ordbehandlare kan skickas objekt för objekt, anrop för
> anrop, beroende på om servern eller klienten utför det snabbast givet
> nätets kapacitet. Och samtidigt kan licensieringen följa användningen...
> 
> Uniformitet + Rekursion = Exponentiell synergi
> Och så slutklämmen då. Det mesta som står där ovanför låter sig göras
> med dagens plattformar och lite jobb. En del har gjorts många gånger, en
> del finns inbyggt, andra saker finns inte än. Oavsett vilket, så uppstår
> något spektakulärt när alla dessa saker samlas under ett paraply. Om
> detta paraplyet dessutom är rekursivt, d.v.s. kan beskrivas genom sig
> själv, händer ytterligare något extraordinärt. Då kan man använda
> systemet för att manipulera systemet. RDF är definierat i RDF. WRAF är
> skrivet i WRAF. Lite samma som om man skulle ha en C++ - kompilator
> kapabel att skriva om sig själv när ny funktionalitet behövs läggas till
> språket C++. I realtid.
> 
> Lång rambling. Kan du hjälpa mig extrahera huvudpunkterna, så jag kan
> förklara detta på ett kortare sätt nästa gång? ;-D

:-)

Vem är publiken?

Ta det på engelska?

Har du jämfört med hur jag presenterat mitt projekt?
    http://jonas.liljegren.org/myself/cv/paranormal_future.html

Jag brukar jämföra med dagens sökmotorer:  När du söker efter
information får du en stor samling dokument som svar.  Med RDF
sammaställs det väsentliga från alla dessa källor och ger dig ETT
dokument som svar. Speciellt utformat efter din fråga,
omständigheterna, dina preferenser, osv.

Huvudpunkter?

 * Maskinförståbar information
 * Kommunikation mellan services (distribuerad arkitektur)
 * RDF Standard
 * Anpassad presentation, baserad på betrodd data
 * Data, funktion och presentation i samma system
 * Systemet beskrivet i sig självt
 * Allt i systemet uppdateringsbart

-- 
/ Jonas  -  http://jonas.liljegren.org/myself/en/index.html