Några bias från en enkel web spindel

2014-05-04

Låt mig här ta "erfarenheten" från Resultat spindling efter RSS- och ATOM-strömmar och vända på det enligt:


  • "Egenheter" p.g.a. att det är enklare som ger bias hur sajt (i mening sammanhållen entitet oavsett subdomäner, "ambassader" på twitter) m.m. spindlas.
  • Hur jag gärna vill se ambassader uttryckta i mening av stöd från Youtube, Twitter o.s.v. utan att ännu tittat hur de gjort det.

Rörande det först gäller givetvis att desto centralare och mer långsiktig kod för en spindel är desto bättre hanterar den analys av sida utan att förfalla till många av de bias jag tog med här. Aktuell spindel här är tämlingen ung (ev. "fortfarande") även om den blev lätt mer begåvad än från början tänkt p.g.a. en del utmaningar jag inte räknat med. Syftet här var endast:


  • Identifiera ev. RSS-ström indikerad på sida som laddats ner. Om identifierad sparas den alltid ner tillsammans med sida där den hittades.
  • Ev. länkar till andra sidor vilka som helst. Dessa för att ge nya sidor att senare titta på för att hitta RSS-strömmar. Ingen skillnad görs mellan samma sajt eller andra.

Bias I: Ordning på länkar

Just nu ligger cirka 500 - 600 miljoner länkar totalt identifierade. Samtidigt är det av och till mycket önskvärt att prioritera spindling mot något särskilt område eller sajt jag bedömer som viktig (eller p.g.a. tidigare fallstudier eller beräkningar som gjors av och till på dem för att följa förändringar i logik) att spindlas fritt direkt oavsett vilka länkar som nu finns identifierade.


Dels kan det göras med samma system som i övrigt men beskriva preferenser för sajt utifrån url. Praktiskt har jag dock vanligen gjort det genom att ge spindel riktad seed för ett antal sidor och sedan låtit samma tråd spindla dessa och fortsätta själv på samtliga identifierade länkar utan kontroll av om de spindlats tidigare. Medan spindel i övrigt vanligen ej spindlar samma domän mer än en eller ett fåtal gånger oavsett antal länkar sätter jag ofta här gränsvärdet för när en given sajt ej accepteras högt. Ex. lät jag precis spindla igenom stora delar av The Guardian därför att de har RSS-strömmar ämnes-uttryckande utspridda över hela sajten.


Siffrorna under resp. länk anger för siffra höger om domänen antal gånger domänen besöks, samt direkt under antal tecken i hämtat data för aktuell sida (antalet sju är dock oftast en felkod bestående av sju stycken underscore) resp. för den rad med två siffror separerade med tab: antal länkar identifierade resp. antal strömmar identifierade.

Arbetande per epok inkluderande alla identifierade länkar som ej överstiger tröskelvärde för domänen. Här i epok tre med totalt cirka 40 000 länkar att gå igenom. Minns jag rätt hade epok två cirka 400 och epok ett inkluderande de sidor jag gav manuellt som utgångspunkt (cirka 10 st och samt på det adderande exakt 27 st.). Tillväxt som funktion av epok (när y-axeln ger summan sidor upp till och inkluderande epok) - och allmänt för större sajter (men ej 100% säkert så stora att jag ej spindlat större delarna men upp till sajter av Orble.com storlek) - ger inlärningskurvan: trögare tillväxt första epokerna, därefter explosiv, och lugnare ökning längre fram.



Komplettering Epok fyra en stund senare. Expansion till cirka 400 000 länkar.


Sajter ej The Guardian kan har antingen vara länkade från dem under tidigare epoker eller länkade från ej sajt de initialt länkade under en tidigare epok.



Av detta ges flera bias. Först och främst gäller att den länk som först spindlas kommer donera där identifierade länkar först till tabell. Ordningen dessa spindlas är ej i exakt samma ordning (utan har mer att göra med Perls hash-funktion) men samma bias existerar fortfarande indirekt mellan och över epoker. Hinner gränsvärde nås ges dispergens mot övriga. Tänkbart generellt bland enklare robotar tidiga länkar på sida resp. länkar vi sannolikt snabbare möter via sidor vi kan tänkas nå den via.


Bias II: Enkel regel-logik

Att sätta gränsvärde per domän är ganska enkelt att göra. Klokare är självklart att hantera själva den gemensamma domänen hellre än som jag gjorde separerande resp. subdomän (eller för den delen betraktande självklara "alias" som ofta ex. www.något-exempel.se resp. något-exepel.se som samma).


Jag tycker mig från längre tillbaka - flera år bakåt - minnas ett för en branschledande sökmotor ev. något besläktat ex. som fick viss uppmärksamhet relaterat sushi restauranger i Sverige placerade på sajt (jag tror det var www.sushikartan.se). Sedan några år tycks för mig att Google försöker se entitet gemensam eller uttryckande ett stycke innehåll (det senare återvänder vi möjligen till i avsnitt önskat från sociala media sajter) d.v.s. ej självklart behandlande subdomäner annorlunda i mening av inverkan med andra subdomäner (men ej heller självklart så utan också möjligt behandlande dem som separerade representerande olika entieter - spekulativt ex. för de flesta men kanske inte riktigt alla subdomänertumblr.com och wordpress.com).


Vidare för att separera "sidor" ämnesuttryckande resp. nyheter just på The Guardian filtrerade jag kastande på sidor vars url innehöll följande eller jämförbart /2013/, /2013/, /2012/ o.s.v. Det fungerade ganska bra just där.


Bias III: Enkel tillförlitlig leverans av fler datakällor

Av de sorters sajter jag enkelt kan beskriva att söka RSS-strömmar för från mängden identifierade länkar är bloggar på Google Blogger och Wordpress.com i särklass levererande i antal relativt tid spindlande dem (särskilt Blogger är brutal: möjligen finns någon orsak till det att söka hur Blogger visar upp sajterna - kanske deras gemensamma grunka överst men jag har inte kontrollerat det) medan Typepad.com levererar mycket mindre och inte just lönt att göra som egen tråd.



Just handräknande väldigt inexakt ett stycke bakåt verkar cirka en stycken typepad.com ges per tio wordpress.org.

Detta medför ett bias i vad jag väljer att prioritera mer av. Särskilt som både Blogger (Google's tjänster för att leverera RSS ut mer generellt) är mycket snabbt och det samma gäller tycks det också Wordpress jämfört med många andra sajter med egna domäner (men antagligen verkar det för mig utan exakt mätning inte lika snabb som Googles hämtningspunkter).


Bias IV: Spindlings-levererande intern-länkning

En del universitet harjag märkt är brutala på att ständigt expandera under DRILL-spindling mot egna associerade subdomäner, andra domäner, och ut från det sajter relaterade staden och liknande runt om kring. Konkurrerande andra kan de ta större delen av utrymmet. Minns jag rätt var ett exempel utanför USA University of Toronto medan ett omvänt exempel på sajt jag fick hjälpa upp med fler initiala seed-sidor Uppsala Universitet. Med cirka fem till tio extra sidor var UU egentligen inte så dålig i hur man tänkt relaterat innehåll resp. uppdelning eget innehåll (ex. bibliotek, botaniska trädgården, informationssidor m.m. intressant för att förstärka sitt eget värde genom att visa upp stadens värde).


Liknande för ett antal större amerikanska universitet är det mycket lättare när fritt spindlande dem från ett fåtal utgångspunkter (även forsknings-nära) att få en hög andel sidor relaterat att anmäla sig m.m. relevant prospekterande studenter snarare än som optimalt för mig hellre mer undan gömda bloggar eller sidor med pressmeddelanden för avgränsade forskningsområden. Möjligt har det sin orsak i att för affären studenter relativt affären forskning är internet mycket viktigare för den första.


En mer begåvad spindel bör hantera en hel del här enklare. Samtidigt ska man vara klar över att en kostnad att direkt under spindling bibehålla och göra tillgängligt fullständigt tillstånd och upparbetad information för resp. existerar. Det är ej ett olösligt problem men det är enklare mer effektivt när resurser oavsett utveckling, hårdvara eller hur tillgång till vad som körs på hårdvara i form av kataloger, databaser m.m. är begränsade att separera spindling och ta in data där uppsamlat till varaktiga tillstånd i batch-import. D.v.s. det är kanske klokt att inte överskatta hur dum ett robot kan vara. Jämför gärna besläktat runt lösningen diskuterad i:



Desto mer av tillstånd nere i spindel ju bättre i mening effektiv behöver den vara i en till domän. Kostnad reducerad hastighet spindlande ska vägas mot vad man vinner genom att spindla effektivare och där ligger förutom mer direkt relaterat lösningarna i best-practise också utvecklingstid.


Önskvärda egenskaper sociala media

I domän av sociala media har jag mycket positiv erfarenhet av att spindla på från länkat via andra sajter in i facebook.com resp. flickr.com.


Även Youtube är snabb, fungerande och levererar ofta förvånande mängd riktigt data (d.v.s. skriven text snarare än filmklipp vilket inte just nu primärt intresserar mig för strömmarna). Eftersom Youtube är ganska tung att komma fel inpå och målsättning närmast är att undvika spindla den för att istället använda RSS-strömmarna (via data.youtube.com) införde jag följande enkla krav på de länkar att spindal som accepteras:


if (

( index(lc($url),"youtube.com") != -1 ) &&

( index(lc($url),"/user/") == -1 )

)

{

return 0;

}

Regeln är inte utvärderad med den noggranhet önskvärd där eller för motsvarande andra sociala media (något för veckorna framöver beroende på prioritering mellan sociala media och bloggar rörande en del data önskvärt från strömmarna) men syftet är att:


  • Primärt söka en enskild entitet - d.v.s. ej entitet Youtube utan entitet användares - centrala punkt på sajten.
  • Denna punkt önskar vi helst kunna se lika tydligt som för en egen domän.

Först och främst är det därför önskvärt att sociala media uttrycker dessa så att de går att särskilja. Utan att nu tittat egentligen på någon relaterat detta bedömer jag att det normalt är möjligt för åtminstone nästan alla. Viss information är trevligt om den finns:


  • Möjlighet för entitet att uttrycka viss personlig information i form av associerade punkter på nätet. D.v.s. om man önskar kasta entiteter som det ej är uttryckt för.
  • De viktigaste RSS-strömmarna (om alls aktuellt) personliga för entitet. Ex. motsvarande tweets eller blogg-inlägg och likes (och varför inte globalt alla kommentarer gjorda, kommenterarer levererade av andra på inlägg, likes m.m.) o.s.v.

För forum var det vanligt att ge sammanfattande uppgifter om ålder på sajt, antal inlägg m.m. Jag vet inte hur vanligt det är på sociala media enkelt att ta ut direkt. Det är för mig mindre viktigt än punkterna ovan och spekulativt tror jag att åtminstone många av de stora sociala media har mycket av vad jag önskade. Det underlättar ju både för dem själva såväl som viktiga stora externa aktörer att tidseffektivt hantera meta-tjänster ovanför kärn-funktionalitet (ex. sökning och vägar för användarna att ansluta till sajten via RSS).