Microsoft Bing! Quality assurance problem och helt avstannad utveckling framåt förutom hantering spam

Följande upp det nya Bo-konceptet Sunny Vitahuset publicerat på Twitter, Youtube, blogg m.m. tittade jag hur det märktes på Bing!.

Nyfiken på om de anti-spam-lösningar och indexeringslösningar vågar och/eller orkar ta upp så snabba volym och rekommendations-indikationer visade sig inte Obamas nyköpta hundvalp alls. Däremot i video-sökningen fanns en försvarlig andel pornografi (jag tror inte det är relevant sökresultat för Sunny oavsett filtreringsnivå: porgrafi-konsumenten har ofta gissar jag inget problem med att addera tydliga cue words t.ex. kvinna gör något i informations-domän pornografi.

www.bing.com/videos/search?q=sunny&qpvt=sunny&FORM=VDRE

Fortfarande vad jag från tumbnails gissar är pornografi också med strikt-filter.

Exakt vad problemet så återkommande lite varstans egentligen ligger har jag funderat över genom åren. Ett möjligt svar jag reflekterade över nyligen efter att ha träffat på deras EntityCube och läst vad de publicerat om den är:

• Vi betraktar idéerna runt kuben man diskuterar i artiklarna.
• Varje algoritm eller kocnept är by the book.
• Väölända stabila algoritmer.
• Ett tämligen pedantiskt noggrant helhetstänk.

När jag tänker på det tycker jag mig minnas något publicerat av Microsoft relaterat något NIST projekt där de om jag minns rätt använt Concept net <(MIT) till något. Samma sak by the book.

Menoavsett hur stabila och goda algoritmer det är - kanske rent av som cosinus similarity - med i de flesta referensböcker räcker det inte i sådana här sammanhang. De kan vara funktionella detaljer också om de normalt även i sådana avgränsningar behöver ses som utgångspunkt att ta upp oavsett om det är något teoretiskt nyare, mer avancerat, mer kostnadskrävande i CPU o.s.v. adderande innovation eller om det snarare handlar om föga avancera, kanske inte alls eleganta, rent av tämligen smutsiga extra filter lösningar för att skjuta ner "underligt" innehåll vi kanske trivialt kan ta det mesta av med bara ord-mönster indexering men som vår statistiska nät förvirras av.

Det är lite som de sär koncepten som komponenter och försöker bygga med lite som Visual Basic men givetvis ändå praktiskt helt annorlunda. Och visst det är klart det går bra med egentligen vilken referensbok som helst i domänen statistisk language processing och hyggligt indata men då får ju inte top-end.

Samma sak med ata. Oerhört vackert och elegant tänk att se kompletterande värden Twitter, webb m.m. Men lite samma sak där verkar man tänka först och hela vägen parallella datakällor man ser lite p.s.s. Det rekommenderas och förklarar indirekt eller direkt vad man avsåg. Men lämnar man standardalgoritmer och standard-datakällor som primära utgångspunkten måste man ju i verkligen om man ska nå längre än vad du får med ett par referensböcker, stora resurser och väldigt nogranna och potenta systemutvecklare (för det är fortfarande ett förbannat svårt område): med en idé vad folk egentligen gör, tänker och agerar när de "rekommenderar" i resp. kanal.

Det skiljer sig radikalt mellan olika publiceringskanaler. Och radikalt beroende av vilken roll också grovt pbulicist har. En marketing inriktad pornograf gör ju en helt annan sak än en gammal tänkt som gör retweets på sina barn-barns- låg-kvalitativa teckningar de fotograferat och ingen människa egentligen vill se hgre i sina sökresultat därför.

Refererar vi en just en referensresurs i ett Tweet som ej är en summering av något mer genomarbetat gäller ju givetvis att mindre tid i genomsnitt investerats i att välja den d.v.s. har mindre quality assurance och större bias Wikipedia m.m.

Utan det tror jag inte för ett ögonblick att någon stabilt får ut rankningsvärde av Facebook eller Twitter adderande kvalitetsdimensioner till andra rankningsfaktorer. Det kan verka fungera men regelmässigt falerar det no doubt utan mer och skämmer ut en stor brand värde-påverkande billboard produkt som Bing!.

Man börjar med människan: Vad vi gör när vi publicerar eller rekommenderar. Vad vi gör när vi letar information. Och tar eller skapar de algoritmer och modeller vi behöver närmare sökmotorn från det.

Rörande just spam på webbsökningen gäller att de numera har mindre problem upplever jag med uppenbart inte vad jag söker efter alls (jämför problemet ovan för video-sökningen). Men i övrigt upplever jag inte att sökresultaten någonsin på år nu blivit kvalitativt bättre i övrigt. Relativt upplevelse av domänen i övrigt står de still.

Om förklaringen stämmer med verkligheten bakom det kan jag ine säkert veta. Och även om så är det ganska underligt. Ev. någon management strategi med områdes-smal rekrytering. Deras visuella ide med bilder på startsidan gillar jag dock liksom en del andra sådana komponenter. Men oavsett elegans tror jag inte att det är dom långsiktiga barriärer Microsoft borde ha byggt redan här för att vara något värdeskapande för ägarna över åren som kommer (om det någonsin varit det).

Microsoft köp av Yahoos! sökmotor var kanske sunt i någon revenue-dimension men jag tror inte att det just adderade något av vad Microsoft kanske behöver nära själva algoritmerna och modellerna. Det är kanske oftare mindre företag mer teknik-inriktade på något nytt. Men även där behöver man ju bäst tror jag en övergripande modell för att kunna resonera om var man kan få värde av sådana köp.

Omvänt kan man ju fundera vad egentligen en fet computer-grid med mycket av rå-statistik är värt för dig när din tid är knapp. Ganska mycket av och till. Från det perspektivet är Bing! mycket attraktiv och fanns möjlighet hade jag gärna köpt det för att få det klart i en stabil-struktur och rullat över annat via bit för bit mellan-lager framför det förvandlande det till en grovare datakälla. Själv i den domänen är jag i deen svårlösligt lite jobbiga riktningarna mellan hash-tabeller i Perl för visst data tagande för lång tid i den dagliga uppdateringen relativt minsta antal nyheter - tappar kontinuerligt ungefär relativt världes tid 2 - 3 timmar dagligen för att boota upp och Perl är riktigt snabb runt dom här operationerna så jag har inte ens prövat en c-portningen - jag initialt för versionen vill indexera dagligen eller välja databaslösningar vilka för Mysql och postgres på min utveclingdata inte hinner med i närheten av ens samma dag att ta in samma mängd nyheter.

Jag vill ha hela Bing! grid:en med allt data.

Men det börjar väl bli dags att surfa in på DELL och se vad prisvärt men snabbt kring sådant här man kan hitta. Helst vill jag ha något med fullständigt brutalt med hyggligt snabbt ram läggande sig som mellan-lager eller nästan helt istället för hårddiskar. Men förra gången jag handlade verkade indexering av minnet vara brutalt begränsat under vad jag ungefär ville ha. D.v.s. cluster krävs ganska tidigt.

Semantic MediaWiki: Abstrahera properties till en konkret och unik entitet ||

Kompletterande Semantic MediaWiki: Abstrahera properties till en konkret och unik entitet bör understrykas att det praktiskt är ett mycket begränsat antal konkreta typer möjligt eller ens vettigt att representera som här motsvarande instansierade med en övergripande "datatyp" likt GEOID.

För ett mindre antal mycket entydiga såväl som potentiellt betydelsefulla beroende på exakt vilket i vilket kontext tyckte jag att det var vettigt. Förutom GEOID inte minst GEO POLITICAL, GLOBAL POLITICAL, PERSON och ett antal till liknande. Motsvarande med mindre i domän av potentiellt agentativ också för egenskaper relaterade närmare språket ex. substantiv, adjektiv o.s.v.

Utanför det kan vi ju se hur vi kan uttrycka dem flexibla properties som uttrycker värden eller kategorier för vad dom är. Att jämföra med HAS_GEO_FEATURE i bilden till Semantic MediaWiki: Abstrahera properties till en konkret och unik entitet.

En relevant - tid mycket substansiell skillnad - är att för typer som GEOID ligger riktad quality assurance inte p.s.s. enkelt möjligt när man skapar upp tusentals typer från kategorisystem.

Utanför dessa mycket riktade typer - ex. GEOID eller PERSON - ska vi ju heller inte utgå att vi på samma "nivå av komplexitet" i kategorisystemet (osäker vad det refereras som allmänt men säg typens upplösning eller i termer jag använt tidigare dess Blue light intensity när vi istället är i abstrakta koncept istället för som här konkreta entiteter) att en instansierad entit alltid nödvändigtvis är unikt tillhörande en typ. Skapar vi nu personer unikt kan vi ju föra ner ökad exakthet bl.a. i HAS_ROLE, HAS_CITIZENSHIP m.m. men flexibelt över övriga inkluderande många tusen gör man det svårligen.

Det är korrekt att tolka core-typerna till vad vi i nyheter har som de vanligaste entiteterna definierande utanför abstrakta koncept vad vi konvergerar meningen till rörande domän, agentativa, potentiellt agentativa (ex. påverkade av vad beskrivet och kan komma att reagera på det) o.s.v. Liksom dom typiska verktygen vilka modifierar potentiellt eller konkrent agentativ entitets förmåga att agera rörande kostnad och energi-åtgång (jfr hur tillgång till kapital, yxa m.m. kan inverka på vår förmåga att hugga ner ett träd).

Semantic MediaWiki: Abstrahera properties till en konkret och unik entitet

Adderande ett presentationslager runt om algoritmer och statistiska lager riktat mot ett fåtal applikationer relaterade att få en "bild" av vad som sker nu, kan komma att ske och vad detekterat som motsvarar "komponenter" i ett perspektiv beskrivet tyckte jag WikiMedia var ett visst vågat alternativ som affärssystem men ändå beprövat i mass-data.

Data i lagret består därmed av representationer mer konstanta som länder, personer, företag, varumärken, kemiska föreningar m.m. vi kan givet en enkelt beskriven parameter kan säga har en unik representation. För att underlätta särskilt detta avgränsat (men förhoppningsvis utan att göra händelser och statistiska över tiden föränderliga uttryck som åtminstone initialt går in i samma databas när det gäller presentation onödigt slöa vid presentation) utan att kräva att jag behöver utveckla något lade jag på Semantic-mediawiki.org. Det tycktes bra då jag inte direkt är en expert på SQL-databaser även om jag svårligen sedan detta påbörjas kan påstå att jag inte kan det. Mitt intryck av Semantic Mediawiki är att så länge vi riktat står vilken view användare kan ta ut är den funktionell. Ger vi användare möjlighet att vandra runt fritt är den som förvantat riskabel därför att får cpu och minneskrävande förfrågningar blir möjliga överskridande det mindre antal sekunder som är rimlig svarstid (under förstått att faktisk funktion nödvändig klarar när riktat beskrivet underskrida orimlig komplexitet i ögonblicket eller sett till att det är förberett vilket vissa möjligheter finns i systemet men troligen för ej föränderliga data vad man lämpligen tittar på möjligheter att populera som direkt förberedda värden för).

Jag kan emellertid uppleva viss osäkerhet när det kommer till att populera in några hundra tusen till miljoner entiteter. För entiteter som i någon mening går att beskriva som unika geografiska sådana valde jag att populera dem helt utan någon presentation i sig:

Och hellre när presentation sker se det som att vi ex. från en av maximalt två PREF_LABEL uttrycka datatyperna som satta från en GEOID-sida.

Tänket övergripande betraktat från perspektiv av en kund till plattform snarare än ev. gränssnitt mot endast användare av yttre funktioner är att det abstrakta koncetet sätts centralt där möjliga instansieringar i konkret mening presenteras underliggande (i Wiki-syntax efter slash) kategoriserat efter de mer väsentliga grupperna:

• Grupperat efter de händelse-analyserande mer väsentliga som personer, geografiska entiteter, geo political, global political, vapen, items o.s.v.
• Och kompletterand mot semantisk och det språkliga mycket närmare - direkt i - natural language processing av enskilda meningar dv.s.s. bland annat nouns, verbs o.s.v.

I det söker jag eferlikna primacy effect vad känt hjärna för att inte onödigt i presentationslagret addera komplexitet i utveckling för mig genom att avdrifta från konkret modell.

Så från ex. ett abstrakt-koncept i benämner china kan vi ha en eller flera geo-representation där de relevanta för geoid enligt bilden tar ut värden från "geoid-sidan" med rätt motsvarande geoid. Kanske vad man upplever som lite av en omväg - jag vill gärna tycka så - men poängen med det införda systemet med Semantic Mediawiki är att underlätta och jag tror att det här är ett vettigt sätt att abstrahera konceptet för properties som kan bindas till något konkret: att låta det bli en konkret sida.

Enligt det koncetet är ex. nästan alla med ett fåtal named relations relaterade Kina som geopolitisk-aktör ej representerat för GEOID utan hamnar i instansieringen för denna unika form som får referera det GEOID som det motsvarar.

Yago: Wikipedia-kategorier är inte subclass till Wordnet-koncept

Åtminstone inte i någon enkel mening med mindre än att man inför givna definitioner av resp. kategori och från dessa avlägsnar delar i form av kategori-kopplingar och artiklar som ej passar in. Idag gäller ju att variationen och också det relativa avståndet från särskilt för artiklar sådana som ligger långt ifrån vad vi oftare tar som mer "naturlig" tolkning kan vara stort.

Det är därför lite vådligt att addera flera Wikipedia kategorier man anser mer exakta eller avgränsade under ett Wordnet-koncept man antar omfattar dessa i mening. Kategorierna kan ju ligga tämligen långt utanför.

Väljer vi hellre en statistisk tolkning med viktmatriser och sannolikheter o.s.v. givet vilket kontext aktuellt för vad vi bedömer något från blir det en helt annan sak. I den mån outliers vi spontant inte ser hur de passar in (och av och till är fel-placeringar eller riktad marketing i irrelevanta segment av Wikipedia) har värde detekterar vi det om våra statistiska källor är tillräckliga för vår användning med dess krav på korrekthet.

Wordnet mycket mer inriktad på ett fåtal koncept i form av 1-gram - och som sådana vanliga ord - kommer den enklare avgränsningen mycket mer naturligt. Det är jämförbart magnituder enklare att göra en bruksordlista funktionell för att slå upp alla vanliga ord vi kan träffa på och behöver kunna tolka riktat för tolkning i meningen eller ännu smalare i den medan det i en uppslagsbok som ej utesluter någon kunskap är fråga om ett gigantiskt arbete.

Därmed inte att jag säger att det är fel att göra som i projektet Yago vid Max-Planck-Institut Informatik i den mån användningen i sig är mycket lokal och man inte förväntar sig en exakthet i kategorierna som inte finns där. Och vidare minst lika viktigt:

Att man organisatoriskt och i management generaliserat av Wikipedia inser att det inte går att generellt ha färdiga definitioner av kategorierna.

Jag betvivlar dock att det problematiken är trolig även om många aktörer som söker smalare värden av Wikipedia som datakälla för att lösa konkreta problem man ser nu i användning av semantiska relationer gärna vill att Wikipedia försöker i så mycket som möjligt uttrycka sig i färdiga kunskapsdimensioner.

Också om de semantiskt i skisser semantiskt mer definierade idéerna gärna för de flesta spontant känns oerhört rätt (strukturellt kanske likartade med hur vi resonerar övergripande givet just den kunskap vi har aktualiserad för en situation aktuellt just nu om än kanske inte kunskapen samlad) tror jag en stor praktiskt realitet finns från att de flesta skribenter och läsare egentligen struntar fullständigt i Wikipedia som datakälla för annat utanför just väldigt kontextuellt smala och varande i artiklar givna sammanhang (typiskt infoboxar resp. delvis kategorier av enklare typer av instanser som olika typer av personer i list-former där ju meningskontext i dessa just ger kontext ex. Kvinnor födda i Berlin politiskt aktiva under 1930-talet (för ett påhittat ex. men mycket typiskt för dessa kategorier).

Återvändande till Yago ligger ju tolkningen här också relaterat hur vi definierar subclass. Varande själv mer intresserad av förutsättning statistiska funktioner vill jag gärna se det från mängdlära. Och visst är det funktionellt om vi hellre ser det som sannolikheten varande i mängden för givet kontext vi vill använda det i (ex. tolkande mening av ett ngram förekommande i en nyhetsartikel). Notera de tre viktigaste ganska löst definierade underrum i dimensionsmening kontextuellt vi har här i Wikipedia: Subclass may refer to. Datalogins perspektiv förutsätter definitioner tillräckliga för att klara resonemang utifrån mängdlära och besläktade matematiska kunskap men är inte i någon annat än kunskapsriktade specialiserade ontologier (ex. gener eller i bredare omfång Gene Ontology (GO) database inkluderande av cellbiologin) där ett givet etablerat kontext gemensamt etablerad med början grundutbildning vad jag någonsin sett.

Vidare relaterat hur Yago gjort kastar man bort odefinierade dimensioner för kategorierna. Man säger att ett kategori-koncept kan vara undermängd (om vi väljer mängdlärans perspektiv) ex. till person i viss mening där ju dimensionen hos det senare ger indirekt (och troligt praktiskt funktionellt oftast utan att engagera sig i det närmare) men också ligger ofta mening i kategorierna som avgränsar eller expanderar kategori-mängden utanför denna eller tar det till dimensionsrum där det senare kan vara praktiskt odefinierad. Vi kan ex. tycka ett en manlig figur i en fabel eller just av manligt kön men vill vi tillämpa principen inom det ekonomiskt största segmentet för dessa system d.v.s. medicinsk och biologisk forskning är det inte funktionellt.

Egentligen är detta inte ett problem hos Yago som det oftast tycks använt - eller för den delen DBPedia m.m. likartat - i lösningar vi kan se men för mindre webb-publicerade proof-of-concept eller just uttryckt av datat i sig snarare än som grund för logik, intelligence, statistik m.m. är medvetenheten viktig och det är i forskning ett allmänt föga berört område där man hellre ser system där man infört någon beteckning som indikerar entydighet för ett koncept (ex. Wordnets synset9 som att frågeställningen på något sätt är löst generellt.

Vi kan med ett mer unikt ex. också mer praktiskt funktionellt än de många publicera relationerna lösningarna förstå vad jag avser med webb-publicerade proof-of-concept. Betraktar vi Google's söktjänst har de börjat publicera sådana här enklare fakta bredvid sökresultatet. Där är ju dock ett kontext redan inverkande sökresultaten givet. Antingen bara det skattat typiskt önskade - mest troliga mening - för den som söker eller personen mer avgränsat givet kontext av tidigare sökningar (Google typbestämmer bara från det första i någon påverkande mening runt detta och undviker annat än som instansierade mer generella koncept passande detta ex. om du söker på ett personnamn och det finns en känd person många är intresserade av så kan du födelsedata m.m. liknande fakta om denna även om du egentligen letar efter en ort med samma namn sedan en timme med olika sökvarianter runt den - en antagligen ganska vettig lösning varande en färsk lösning och givet att Google generellt arbetar runt kontext-påverkan som bedömt sökresultatens förändring resp. en del bredare forskningsprojekt, engagemang från entiteter inkl. Google m.m. och etablerad kunskap i segmentet).

Egentligen gillar jag nog mest denna tradition. Jag har en del koncept och implementationer här och vet av erfarenhet att det kan vara sunt utvecklande att göra dem själv och därför vad jag inte tycker dom här projekten ska försöka göra någon lösning av som kanske ändå inte blir särskilt riktat bra. Men indikerade det ändå därför att jag gärna skulle se att någon av projekten som gör komprimerade extraktioner av Wikipedia skapade relationer från kategorier till andra inkluderande fler i dimensionsmening. Jag påbörjade det själv mer riktat för att ta in dimensioner relaterat personlighet, sociala koncept i grupp, medicinska och genetiska aspekter av människor, men givet mängden hand-filtrerande där bokstaven "a" till cirka hälften klart manuellt tog ett antal timmar för en ganska begränsad mängd koncept kände jag inte för att göra klart det.

Semantic Mediawiki: Enkelt och vettigt avgränsatd och troligt ett bra val för många trots långsam dataimport

Med begränsad erfarenhet av MediaWiki som plattform presentation mot affärslogik och artificiella intelligenser och analys-systems resultat "organiserat" och sökbart var det en tämligen självklar utgångspunkt att tänka basplattformen utan att blanda in Semantic MediaWiki. Hela det teknik-området är ju vanligt problematiskt långsamt när man börjar komma upp i ordentligt med samband och än mer när relationerna inte är binära utan varierade i "attraktion" som funktion av tid.

Men läsande egentligen väldigt lite publicerat - och förvånande lite jämfört med hur dåligt organiserat jag upplevde att informationen var centralt för MediaWiki i faktisk tid resulterande anmärkningsvärt enkelt - framgick att MediaWiki egentligen bara är en tämligen "dum-plattform" med en eller flera små insticksmoduler bl.a. uttryckt i PHP med lite filer runt omkring jag inte tittat just på men antagligen bär logik och kanske ev. eget modulerna behöver.

Ingen nackdel med att installera in subsystem motsvarande MediaWiki såg jag - åtminstone innan man ger dem ansvar och uppgifter genom att sitta och arbeta på sidor anropande dem eller vi egna diskreta små databas operationer det hela tycks göra men jag inte riktigt tittat i detalj på.

Semantic MediaWiki var dessutom förvånansvärt vettigt begränsad i vad de försökt att göra. Den kändes som en nästan kulturell-stereotyp för tyskarnas ontologi-intresse och visade sig också driven av dom vilket också gjorde att jag förväntade mig mer filosofiskt konceptuella relationsidéer av sådan natur att de praktiskt i maskin-analys blir oerhört långsamt. Men förenklad ner till nära nog bara det mest grundläggande i hur vi utnyttjar systemet skjutande in data (medan analys-kod för sökande diverse logik runt dom semantiska graferna troligt är vad man intresserat sig mer för att koda mycket in en hel del i: Det finns ett ganska stort intresse hos både universitet och företag i Tyskland med ett tycks det väldigt långsiktigt perspektiv ganska tydligt just uttryckt i analys-system av typen resonera "mer binärt" om vad relationer av olika slag betyder och bygga upp små antagande som växer sig stora över tiden men universiteten i USA oftare tycks mer inriktade på statistiska lösningsmetoder.

Att de avgränsat uppgiften gör att man lättare kan abstrahera vad den är till för och avgränsa ansvar med också mindre behov att verifiera om den gör saker kanske störande affärslogik ej trivialt att alltid reda ut när det handlar om väldigt komplexa grundplattformar (jämför ex. med de moderna databas-koncepten från IBM, Oracle m.m. som blandar alla möjliga former av datarepresentation, logik, underhåll, import och export fordrande mycket goda kunskaper om det innan man ens kan börja tänka på att bygga det värde man söker mer än delmål att få databasen att fungera utan att störa eller begränsa logik.

Logiken prioriterad för sökning och samband känns dessutom vettigt kompletterande i områden jag haft mindre intresse att göra lika generella lösningar i egen-kod. Det är ju dessutom samtidig logik som endast belastar när faktiskt använt av slutanvändare (åtminstone på nivåer av betydelse annat än vid dataimport där det kanske adderar en kostnad också åtminstone om man optimerat representationen för snabba analys-svar).

Dessutom var två excellenta introduktioner praktiskt funktionella utan att överdrivet uttrycka mer än funktionellt ny med systemen men ändå indikerande de viktigaste möjligheter ett tydligt ett värde ej trivialt:

Första länken är en längre guid och den man bäst utgår från vid installationen. Instruktioner tillsammans med Ubuntu-paketet gick ex. ej bra för mig innan jag gjorde en del saker indikerade här (ev. missade jag det i Ubuntu-informationen). Utmärkt som första introduktion.

Semantic MediaWiki 1.4.3 - User Manual | Semantic-mediawiki.org

Denny Vrandecic, Dominika Wloka, Markus Krötzsch, Yaron Koren, et al.,
Publicerad av: ontoprise GmbH | Ontoprise.de

Nedan sammanfattad information av åtminstone väldigt mycket av alla delar. Mycket praktisk för att snabbt se vilka möjligheter som egentligen finns för att lösa en del av vad som behöver göras.

Quick reference | Semantic-mediawiki.org .
Yaron Koren.

Precis som elegansen i grundkoncept överraskade klarade man här också av att förvåna med att man (åtminstone / redan) nådde upp till det nästan löjliga när systemet ska få data infört från andra system. Ingen verklighetsförankring från mitt användningsperspektiv verkar heller alls vara vad man i projektet noterat ännu.

Perspektivet i projektet är tänkt användning övergripande i Wiki-projekten där större importer sker mer sällan och istället många små "importer" från alla användare.
Att initialt ta in en kanske om sortering i namngivning lite generöst belastande databasens storlek på hårddisken är fungerande säg 50 000 000 koncept-sidor förutom själva relationerna är vad tänk och rekommenderade metoder ej är tidsmässigt förtroendeingivande för.

Det närmaste jag kom lösningar enkelt beskrivna (istället för inte alls) för att direkt skjuta in datat till databasen var istället för Pyton-skript läsande owl-filer och skickande det omvandlat till Wikimedia's intern-struktur till Wikimedia's webb-api (för parsning igen givetvis säkert på mer än en nivå) var detta underhållsskript:


"/var/lib/mediawiki/maintenance/" ."importTextFile.php".


Mycket troligt finns snabbare metoder men vad som hittades på den tid jag önskade lägga. Givet att vi här uttalat kan köra skriptet från kommando-prompt utanför själva Mediawiki-systemet blir det snabbare (när kö-hantering i Wikimedia inte just är problemet eller utmaningen för oss här utan heller någon negativ-sida).

Trots det mycket långsamt. Hårddisken låter på förvånande nivåer också för ganska små datamängder som kanske 100 till 1000 sidor uttryckande endast kategori- och property-relationer går in. På nivå med cirka 10 - 20 trådade Perl-processer som läser och skriver data i ganska hårda-loopar om än normalt för mig några sleep-inlagda av och till åtminstone på några milli-sekund av och till.

Men så har ju data't då gått en ordentlig väg trots kommando-prompts-körningen innan den slutligen hamnar i den databas jag ej varande någon expert eller ens särskilt kunnig alls om SQL m.m. nära nog kände att jag kanske hellre borde ha gett mig på att försöka oavsett ännu ganska dålig bild av hur enkelt det är att ta MediaWiki att korrekt följa upp sådant i ev. (och troliga) händelser den behöver göra när något nytt kommer (ex. optimeringar mot dess egen logik mer problematiskt för mig att uttrycka i kod mot databasen utan att ta ut den från deras plattform eller utsätta mig för traumatiskt krävande föga belönande utveckling av prospekterande stöd för det i Wikimedia's värld av massor av ofta lite ofullständig dokumentation).

>Importen till höger presterat till kanske 0.3% efter en försvarlig tid. Just nu säkert en eller två timmar senare på AJ. Med e och diverse andra otäcka bokstäver som första kvar. Till vänster om jag minns rätt några av de named relations som tas in i denna import. Faktiskt har vi ännu inte börjat kört in datat utan verifierar att inga dubletter finns i den MediaWiki-logik som skapas. Det tycks lite odefinierat för hur redundant-data alla gånger egentligen fungerar och också om det troligen ej är något egentligt problem med logik är det vettigt att varje system verifierar ner ökande som en funktion av dess vetskap och förståelse av datat nära dess kod (d.v.s. att jag helst inte vill behöva veta vad MediaWiki gör med datat i dess arbete vad vi hellre gör lite extra-filtrering innan skickande in det).

Nu tänkte jag börja köra in dom första miljonerna raderna koncept gjorda. Så får vi se om det kommer några skärmdumpar av det kanske tillsammans med en sammfattande publicering av dom skämtteckningar jag gjort bakåt i tiden relaterat Tyskland med kanske utlovade behov att helt prioritera ner Obama med flera fallstudier studerade i det komiska för att inrikta mig på att håna Tyskland i allt semantiskt för att avskräcka dem från att sprida något smärtsamt ut i världen. Humor är ju ett mycket potent vapen jag tror många fler än jag kan ha nytta för att standardiserat verktygsmässigt skapa värde från för att motivera diverse öppen-källkods-projekt m.m. att få rätt brukshöjd i vad skapar genom att addera en kul men samtidigt kompletterande motivations-area bredvid status- och makt-strider i grupperna om vem som kodar mest och bäst m.m. vi kan gissa tar mycket tid (åtminstone jag kan då inte se någon annan motivation förutom externt adderande komisk learning by shaming m.m. som kan spela in viket i sig på längre sikt kan bli ett problem om något av äppen-källkods-projekten konvergerar till en stark ledare med kraft i gruppen att försöka marschera ut för att utmana dagens betydelsefulla geo-politiska aktörer: den stora frågan är kanske om man kommer ta allians med NATO eller Kina och hur det påverkar utgången i det tredje-världskrig jag tror vi givet allat som skapas på nätet i kaotiska konflikter mellan teknik-plattformar m.m. helt säkert kommer bryta ut förr eller senare).

Men jag känner mig tämligen positiv i förväntan. Trots utmaningarna prestanda import har det överraskat i också fler små-indikationer än diskuterat att det kan vara ganska välgjort i inriktning en bra grund-plattform.