Visar inlägg med etikett Information Retrievel. Visa alla inlägg
Visar inlägg med etikett Information Retrievel. Visa alla inlägg

Google Search Suggestions: Defekt demonstrerar bredare taktik

2015-03-19

Sista åren har jag upplevt att Google experimenterat med diverse små och i litteratur välkända metoder utanför de mer avancerande runt kärn-algoritm - manipulerande indata från sökningar såväl dokument - som ofta indikeras som tänkbara vägar till förbättringar. Jag har vad jag minns egentligen aldrig tyckt de förbättrat något men självklart är det inte alls lika troligt att jag lägger märke till sådana förbättringar när de fungerar bra lika lite som jag troligt lägger märke till sådana problem när de försvinner.


Problematiken i kvalitet från mitt perspektiv och hur jag söker är att dessa förändringar smetar ut mening och reducerar möjlighet att söka ytterst exakt. Det gör det svårare att gå från ganska breda begrepp man börjat med i en sökning och kontinuerligt addera på för området ganska smala men exakt krävande begrepp.


Ett exempel från nyligen var att Google gav en försvarlig mängd sökträffar innehållande complex när sökterm var complexity. Och complexity var som adderad term till en sökning bl.a. (övergripande topp och satt först) grammatical. Därmed fick jag en mängd träffar relaterade "complex phrases" av olika sorter. Men det var ju verkligen inte vad jag sökte på:


  • Jag sökte på complexity.
  • Det är i betydelse ett radikalt annorlunda från complex inom området av att tolka och förstå mänskligt språk.
  • Meningen är nära associerad till bl.a. information och entropi.

Att hitta ett annat begrepp som bra ersätter complexity går ej men däremot hade jag kunnat prövat att addera -"complex (jag har fått för mig att man ska bäst skriva det just så här inkl. citationstecken för att det ska fungera utan risk för liknande problem).


Ovan en ny sökning jag gjorde nu för att demonstrera problemet. Vi ser träffar både från antagande complex såväl som complexity: Praktiskt fylls sökresultaten ut med en ordentlig andel säkert irrelevanta dokument.

Varför adderar man dom här förändringarna? En orsak och varför sådant här ofta indikeras som vägar till bättre sökningar är att det kan minska problemen som kan skapas hur man exakt uttrycker en term trots att betydelsen är den samma som termen uttryckt ex. i dåtid istället för nutid.


Men jag tror inte som Google kanske gjort det - som jag vill tolka det mindre formellt - att det är orsaken. Jag tror att orsaken är att dom försöker reducera sin complexity som funktion av här särskilt mängden söktermer och mängden dokument. Många dokument med många söktermer hanterade gör saker arbetsamma. Denna komplexitet följer ju antar jag efter att snarare vektormodeller tagit ut mängder - tänkbart förberäknande för söktermer med utnyttjande av antagligen ganska komplexa algoritmer för att kombinera sökterm givet sådana resultat - och därefter reducerande dessa från mer exakt tolkning av söktermer. Därför bl.a. att man förr en lång period kunde få onormalt få söktermer när man gjorde sökningar från ett fåtal ganska breda begrepp och därefter försökt få ökad exakthet genom att addera några mer exakt termer.


Och vi har som framgår nedan från en ledighetssökning (eller säg att jag orolig för nöjesbranschen frivilligt gjorde lite grannsamverkan snarare än att söka något tänkbart otillåtet delat att titta på) samma typ-grupp av lösningar men ordentligt översträckande Google's förmåga att tolka och förstå mening i begrepp:



Google föreslår ett annat avsnitt av South Park än det avsnitt jag redan givit fullständig titel på.


Notera hur Google givit sig på att se mening av faith från christian. Faith är både vad vi kan se som ett bredare begrepp "ovanför" christian såväl som en tänkbar "ord-komplettering" följande christian till ett två-gram d.v.s. från christian till christian faith. Vidare är det tänkbar att faith i vektormodeller av dokument relaterat christian ofta har samförekomst eller rent av är ett av de ord som i vektormodell utnyttjas för att beskriva dokumenten "komprimerat" i antal dimensioner.


Det roliga (eller om man bättre upprört skriver att verksamhetskritisk nöjes-tid förbrukades) var att jag också gjorde fel. Jag klickade på resultatet och kom konkret så långt att jag började titta på fel avsnitt av South Park.


Jag har lätt road av detta. Ty mening när man tolkar går ej att generalisera för språk utan att det blir fel. Mening måste alltid tolkas som funktion av typ av dokument vi har:


  • Ligger dokument inom område medicin behöver vi för att minska risk för problematiska fel veta det.
  • Och p.s.s. för andra specialistområden. Annars kommer mening som varierar mellan områden leda till feltolkningar.
  • För godtyckliga meningar utanför specialistområden och innanför vad vi kan kalla allmänt språk där vanligaste meningen kan förutsättas går det fortfarande inte att tillämpa det utan förståelse av typ av dokument.

Problemet här är argumenterat (om ej en ren defekt) inte otroligt orsakat av den sista punkten. Typ av dokument avsedd är här ej riktigt filmklipp utan titel på filmklipp inom området nöje. Titlar är ett särskilt område som just här rörande mening har behov av en uttryckt exakthet. Titlarna för dokument, filmer m.m. är ju i kontext av search suggestions en av de mest optimerade för ökad enkelhet algoritmen kan ge.


Normalt är Google riktigt skicklig just på att ge hela titlar som förslag på några ord från dem. Det är rent av en av de få starka argumenten jag har för att använda Google för en större grupp typsökningar jag ofta gör snarare än specialiserade sökmotorer eller för den delen numera också Bing som jag nyligen kunde konstaterat gått upp ordentligt i kvalitet när artiklar publicerande forskning inom åtminstone språk söks (kvalitetsökningen här behöver ej innebära att den är generell ty utmaningar relaterat bl.a. spam är här få om alls förekommande).


Jag är inte en stor vän av vektor-modeller allmänt inom information retrieval eller nätverk över vetande och koncept. Särskilt inte när de tas vidare till associerad mening: Jag menar att de utnyttjar alldeles för få dimensioner och att man istället snarare ska expandera antalet dimensioner i och runt associerad mening samtidigt som alla dimensioner bibehålls. Emellertid inser jag också att om indexerar med en historisk målsättning av att ha allt indexerat blir min princip här minst sagt krävande i åtminstone men kanske inte nödvändigtvis mer än lagring.


Ännu fler år tillbaka fick jag för mig att Google kanske utnyttjat Google NGRAM för att bygga search suggestions. Det är en sak som kan fungera ganska bra för allt innehåll som är som titlar (inkl. enklast att ge exempel på undertitlar men mer liknande typer av "under-dokument" finns säkert även om jag ej har bra karta över sådant ännu normalt optimerande i analys på stora mängder data begränsat till titel, abstract, nyckelord, och något mer sällan referenser även om jag bl.a. för Plos journaler gått längre är det relativt väldigt få) även om självklart NGRAM-modeller bara skapat av titlar säkert fungerar stabilare över mer för titlar udda kombinationer. NGRAM-modellerna om man gör det senare behöver ju inte fortsätta skatta utan kan när en full träff på en titel hittas föreslå hela den om den är väldigt otrolig som funktion av hur otrolig av användaren givna ord i sin ordning var (eller hur man rätt uttrycker det i dagligt språk).


Datakällan ovan är dock i sig inte viktig eller vilken man egentligen kan avgöra (trivalt) använts. Men det ger en indikation om större metoder tillsammans med vetande om ex. titlar som kan ligga under och som man nu eventuellt försökt sig på att komplettera med meningstolkning. Gör man det sista snarare än att det är en annan defekt tror jag föga på det. Jag upplever Google allmänt som mindre uttryckt relaterad mening och när det tycks ske som att det snarast reducerar förmåga än att öka den. Möjligt därför att man använder få-dimensionella statistiska relationer av typen P(mening eller kompletterande / alternativ term | vad jag sökt på och hur dokument för prototypiska sökningar för dessa normalt). Exakta sökningar inom specialistområden tror jag det aldrig kan ge bra resultat för utan att algoritmer som kan prestera här konkret som sökande dessa områden som behärskande ska uppleva när man ser dem direkt kompletterar ens eget vetande alternativt hanterar ens vetande med samtidighet över så många dimensioner att man ej klarar det själv. Utan det tror jag alltid att man tappar möjlighet så fort man söker med många termer för att få fram något exakt.

Utvalda lite äldre inlägg (Inkl. kompletterande diskussion om Israel)

2015-03-13

Ibland när jag ej med hjälp av site-sökning med Google ej hittar vad jag söker är det att det hör till två buntar med inlägg jag avpublicerade (relaterat etablering värde modell där jag upplevde det någon gång trevligare att avpublicera om än säkert irrationellt: Något fungerade bra och så kändes det mer avundsamt övertolkande folks intresse såväl som möjlig teoretisk investering över ändå föga koncentrerad och sammanfattad information). Men ofta nog är det relaterad dålig indexering delvis därför att bloggen är gjord så att den indexeras dålig (användande Googles för det i gränssnitt till blogg rekommenderade färdiga saker för arkiv m.m.).


Det är klart att jag skulle kunna spara ner allt och låta den lilla mini-sökmotor jag använder mestadels för forskningsartiklar relaterat hjärna, språk, parsning m.m. relaterat göra det här också. Men jag tycker egentligen inte för ett så sök-trivialt om område att jag ska behöva slösa tid på det. Särskilt som det smutsar ner den utvecklingsdatorn med områden som jag just nu aldrig använder den för: Jag vill ha den för uteslutande dataanalys i test- och utvecklings-perspektiv resp. programmering. Så vet jag vet jag arbetar med när jag använder den och för annat resp. nöjes-datoranvändning får min gamla dator användas.


Här skulle jag dock önska hitta ett inlägg bakåt utan att behöva titta över allt troligast 2011. Vi prövar att länka in diverse något så när relaterat till det och ser om det kanske medverkar till indexering bättre i och runt vad jag söker via diverse mellansteg. Vi har en bra bild med någon liggande på ett tak och en tillhörande trevligt undervisande diskussion om språkligt perspektiv. Som jag vill minnas det. Mest för egen del misstänker jag. Dom få individer och personer ev. mer intresserade lär hitta det lättare till mig oberoende av resurser: Om goda ett enkelt problem och också om få - kanske en intresserad individ - är det som alltid enklare när man söker värde hos någon annan att motivera sig att söka rätt på det än när det är eget data.


Stabilitet utan negativa bias med "blodbad" krävs (2011-02-11). Inkl. citat från inlägg som tycks av-publicerat. Möjligen det inlägg jag sökte.

Reward discounting: Weapon effect vs Kawaii (2014-06-17)

Syrierna kan slåss - Men segern väntar på slug kyligt organiserande ondska (2013-09-09). Borondino när Napoleons soldater mötte tsarens soldater för att illustrera något.

Kriget seger i energieffektivitet: Vapeninnovationens hastighet relativt fiende och vårt försvars- och politiska-systems förmåga att tillämpa vapnen vi skapar (2013-05-02). Och det är ju en dimension av djup associerande analys: Hitta lösningen men själv inte självklart ser kanske etablerad i ett annat kunskapsområde man kan ta över till där problemet bor.

Dags att lösa problemet al-Gaddafi (2011-03-10)

http://senaste-nyheter.blogspot.se/2011_05_05_archive.html

Oväntad emergence i aktions-relaterade händelser (2013-05-28)

Toy Soldiers & Ondskans Axelmakter (2011-04-27)


Och antagligen relaterat Var har Israel hamnat sedan The Profession of Arms (1983)?:


Artighet och Gulligt som strategi för fred (2011-04-25)

De irrationella fortsätter göda Israel - Palestina konflikten (2011-04-26)

Statistisk analys av PDF-dokument: Omvandling till text och extraktion metadata från fil resp. databaser

2013-12-09

Tidigare exempel extraktion metadata resp. diskussion möjligheter analys kompletteras här med en första version av ett enkelt liten program (själva basfunktionerna var för sig tog cirka fyra timmar att skriva men mer samlat till praktiskt funktionellt kontinuerligt nedladdande och analyserande) för analys pdf-dokument, omvandling till text, och sammanförande med meta-data i separerade databaser (ex. OID).


Tidigare i ämnet:



Exempel: WWW

Referenser till webb-sidor är säkert ett mer naturligt hemvant exempel på "anslutningar" från dokumentet till aktörer, personer, information m.m. som betraktat över många fler kan säga något mer allmänt om organisationen. Nedan från ADA554030 några st. identifierade:


__FUNCTION_WORKING PDF_TO_TEXT_LOGIC
__PDF_FILE_NAME ADA554030.pdf
__IN_DIR_GIVEN C:\PTOOLS\SAMPLER\DTIC\PDF\
__PAGES 156
__WWW_CONNECTIONS www.china.org.cn/english/features/dengxiaoping/103389.htm GlobalSecurity.org mearsheimer.uchicago.edu/pdfs/A0034b.pdf www www.cfr.org www.stanleyfoundation.org
__EASY_JOURNAL_CONNECTIONS_EX_DOI 

I kontext av Google och ranking är egentligen prioritering och utnyttjande av länkar ganska annorlunda (som man oftare ser på deras algoritmer externt även om jag är tämligen säker på att association nära denna mening också är en av många möjligheter kring länkar som utnyttjas förutom koncept-beskrivning ankartext, prioritering spindling, page ranking, implicit association mellan koncept på resp. sida om länken såväl som kanske statistisk-modeller med något av flera alternativ liknande Bayesian yin yang för ett implicit samspel effektivt skattat och förr ev. en del nu övergivet för annat som förståelse av association mellan felskrivningar, begrepp för samma sak inom olika expertområden o.s.v. och vad de avser resp. relevans-kontroll om Google någonsin haft det senare tydligt tidigare än sista åren där jag tror feedback från hur själva sökresultaten fungerar med användaren används idag resp. för expertområden via riktade datakällor - datat i Google Scholar lär väl vara vad som ger många möjligheter med endast lite metadata om journalernas inriktning och författarnas association över tiden till mer övergripande områden).


Vad vi är huvudsaklingen är intresserade av här är ju mindre att säga något om indikerade dokument så mycket som prfererenser och association mellan entiteter och deras delar. Mer Google-liknande-analys är nog mindre vad man kanske valt för denna form av pdf-dokument varande relativt intet-sägande om vi vill analysera mycket snabbt (få, sällan ankartext, ofta presenterade i ex. fotnoter längst ner på sidan medan både den presentationen och fotnoterna är vådligt felområde via omvandling till text - åtminstone för mig även om jag sett att bättre teknik används av en hel del nu bl.a. Google och möjligen vad som bl.a. utvecklades av NSA och tillgängligt enligt Classification of Machine-Printed and Handwritten Text for Document Images såväl gissar jag teknik ganska väsentligt för stora delar av dokumenten DTIC publicerat vilka ofta är dåliga fotostat-kopier av ex. gamla datautskrifter eller maskinskriven text: själva problemet vi ser tydligare i omvandlingen till text är ju att det visuella lätt feltolkas med ord av avbrytna av och till i särskilt visuellt intensiva delar som huvudrubrik, författare m.m. positionerat kreativt fritt över en sida).


Exempel: Versionshistorik

Samtliga pdf-moduler jag prövade är ofullständiga i förmåga att identifiera åtminstone här konkret intressant information. Även om jag inte prövats Adobe's stöd misstänker jag lätt att det är väsentligt mer fullständigt men också riktigt dyrare i beräkningskostad (XML vara upplevt vackert graf-rätt men är samtidigt vad som tenderar att kosta brutalt i minne och cpu antingen på begränsad hårdvara eller när vi trådar upp flera processer och där kollisioner mellan processer som oväntat samtidigt åker på något överdrivet stort och komplext XML-träd kan bli svårt problematiskt om man försökt utnyttja hårdvaran närmare dess övre gräns).


Ett bra exempel är att historiken över hur pdf-dokument ADA554030 (att referera dokument med ID känns mycket rätt här) utvecklats steg för steg inte alls kommer med:


<xmpMM:History>

    <rdf:Seq>

     <rdf:li

      stEvt:action="saved"

      stEvt:instanceID="xmp.iid:62851626731AE011A09ECC9ACC76B452"

      stEvt:when="2011-01-07T15:00:21-06:00"

      stEvt:softwareAgent="Adobe Photoshop CS4 Windows"

      stEvt:changed="/"/>

     <rdf:li

      stEvt:action="saved"

      stEvt:instanceID="xmp.iid:EED3050E561EE0119927C84E9CB8197E"

      stEvt:when="2011-01-12T08:12:57-06:00"

      stEvt:softwareAgent="Adobe Photoshop CS4 Windows"

      stEvt:changed="/"/>

     <rdf:li

      stEvt:action="saved"

      stEvt:instanceID="xmp.iid:11BA444CC627E0119987A6F9DFDA4467"

      stEvt:when="2011-01-24T15:54:48-06:00"

      stEvt:softwareAgent="Adobe Photoshop CS4 Windows"

      stEvt:changed="/"/>

     <rdf:li

      stEvt:action="saved"

      stEvt:instanceID="xmp.iid:09357E023B64E011895EA90A7558D10D"

      stEvt:when="2011-04-11T12:57:22-05:00"

      stEvt:softwareAgent="Adobe Photoshop CS4 Windows"

      stEvt:changed="/"/>

     <rdf:li

      stEvt:action="saved"

      stEvt:instanceID="xmp.iid:0A357E023B64E011895EA90A7558D10D"

      stEvt:when="2011-04-11T12:57:22-05:00"

      stEvt:softwareAgent="Adobe Photoshop CS4 Windows"

      stEvt:changed="/"/>

     <rdf:li

      stEvt:action="saved"

      stEvt:instanceID="xmp.iid:0EB62AC83565E011990DE0CB345F06A5"

      stEvt:when="2011-04-12T14:34:21-05:00"

      stEvt:softwareAgent="Adobe Photoshop CS4 Windows"

      stEvt:changed="/"/>

     <rdf:li

      stEvt:action="saved"

      stEvt:instanceID="xmp.iid:FF5769E5CE65E011B575D54F7DC87B53"

      stEvt:when="2011-04-13T08:06:50-05:00"

      stEvt:softwareAgent="Adobe Photoshop CS4 Windows"

      stEvt:changed="/"/>

     <rdf:li

      stEvt:action="saved"

      stEvt:instanceID="xmp.iid:005869E5CE65E011B575D54F7DC87B53"

      stEvt:when="2011-04-13T08:08:32-05:00"

      stEvt:softwareAgent="Adobe Photoshop CS4 Windows"

      stEvt:changed="/"/>

    </rdf:Seq>

   </xmpMM:History>

Ett till exempel där närmiljö i integration andra format framgår (och som vi ska se därefter ganska brett samarbetande olika former av media-komponenter):


<xmpMM:History>
    <rdf:Seq>
     <rdf:li
      stEvt:action="saved"
      stEvt:instanceID="xmp.iid:F77F117407206811871FB2ED4E37AE08"
      stEvt:when="2011-01-14T12:11:33-05:00"
      stEvt:softwareAgent="Adobe Illustrator CS5"
      stEvt:changed="/"/>
     <rdf:li
      stEvt:action="saved"
      stEvt:instanceID="xmp.iid:01801174072068118C14E72FBDC50C68"
      stEvt:when="2011-06-28T14:07:30-04:00"
      stEvt:softwareAgent="Adobe Illustrator CS5"
      stEvt:changed="/"/>
     <rdf:li
      stEvt:action="converted"
      stEvt:parameters="from application/postscript to application/vnd.adobe.illustrator"/>
     <rdf:li
      stEvt:action="saved"
      stEvt:instanceID="xmp.iid:F77F1174072068118083E0155A4A0A32"
      stEvt:when="2011-06-28T14:13-04:00"
      stEvt:softwareAgent="Adobe Illustrator CS5"
      stEvt:changed="/"/>
     <rdf:li
      stEvt:action="saved"
      stEvt:instanceID="xmp.iid:351C424C262068118F62BE1AEC87ECB3"
      stEvt:when="2011-08-24T15:36:22-05:00"
      stEvt:softwareAgent="Adobe Photoshop CS5 Macintosh"
      stEvt:changed="/"/>
     <rdf:li
      stEvt:action="converted"
      stEvt:parameters="from image/tiff to application/vnd.adobe.photoshop"/>
     <rdf:li
      stEvt:action="derived"
      stEvt:parameters="converted from image/tiff to application/vnd.adobe.photoshop"/>
     <rdf:li
      stEvt:action="saved"
      stEvt:instanceID="xmp.iid:361C424C262068118F62BE1AEC87ECB3"
      stEvt:when="2011-08-24T15:36:22-05:00"
      stEvt:softwareAgent="Adobe Photoshop CS5 Macintosh"
      stEvt:changed="/"/>
     <rdf:li
      stEvt:action="saved"
      stEvt:instanceID="xmp.iid:371C424C262068118F62BE1AEC87ECB3"
      stEvt:when="2011-08-24T15:36:35-05:00"
      stEvt:softwareAgent="Adobe Photoshop CS5 Macintosh"
      stEvt:changed="/"/>
     <rdf:li
      stEvt:action="converted"
      stEvt:parameters="from application/vnd.adobe.photoshop to image/tiff"/>
     <rdf:li
      stEvt:action="derived"
      stEvt:parameters="converted from application/vnd.adobe.photoshop to image/tiff"/>
     <rdf:li
      stEvt:action="saved"
      stEvt:instanceID="xmp.iid:381C424C262068118F62BE1AEC87ECB3"
      stEvt:when="2011-08-24T15:36:35-05:00"
      stEvt:softwareAgent="Adobe Photoshop CS5 Macintosh"
      stEvt:changed="/"/>
    </rdf:Seq>
   </xmpMM:History>

Exempel: Integration mjukvara - Kultur och säkerhet

En mer uppenbar fråga kring risk och värde att stämpla dokument med de programvaror som används är att det kan indikera trovärdigt vad som används fortfarande vid en tidpunkt längre fram också om så långt indikerat tidigare säkra. D.v.s. berätta hur organisationen tänkbart kan angripas.


Navigating complex buildings: cognition, neuroscience and architectural design (University College of London, bok-kapitel, Dalton) - vilket dessutom är en till Riktad information - Navigation: Förstärkt i spatiell organisation excellent komplettering både ganska praktiskt men med visst djup och referenser vidare - ger ett lättsamt exempel på båda om vi nu väljer att tro Microsoft Word som mer säkerhetsdefekt trolig resp. att Macintosh nog ibland är ett kulturellt val oavsett om preferens inom tekniksegment (en del applikationer inom moving pictures för att skapa om jag minns rätt) eller att något uttrycks fullt mindre av conformity ej onödigt komplext i konfiguration känns bättre om man arbetar kreativt ganska ointressad av annan bredare vanliga kontorsapplikationer.


__FUNCTION_WORKING METADATA_LOGIC
__PDF_FILE_NAME navigating_complex_buildings.pdf
__IN_DIR_GIVEN c:\PTOOLS\PDF\pmid\
__METADATA_FIELD ModDate D:20100602114653-04'00'
__METADATA_FIELD CreationDate D:20100529222217+01'00'
__METADATA_FIELD Producer Mac OS X 10.4.11 Quartz PDFContext
__METADATA_FIELD Creator Word
__METADATA_FIELD Author Ruth
__METADATA_FIELD Title Microsoft Word - Dalton_Spiers_Hoelscher.rtf
__DOCUMENT_ID_UID_CONNECTIONS

Och så en till kulturella preferenser (även om jag inte alls betvivlar att tex, post-script m.m. har en försvarlig mängd ej dokumenterande säkerhetsdefekter bara i befintlig kod: komplicerade standarder med komplex parsning). Latex är fortfarande idag stort i delar av forskningsvärlden (mer så i de mer tillämpade delarna inom data och fysik snarare än ex. forskning inom medicinsk eller kemi).


__FUNCTION_WORKING METADATA_LOGIC
__PDF_FILE_NAME hanford.pdf
__IN_DIR_GIVEN c:\PTOOLS\PDF\pmid\
__METADATA_FIELD ModDate D:20111121131055-05'00'
__METADATA_FIELD CreationDate D:20111121131055-05'00'
__METADATA_FIELD Producer MiKTeX pdfTeX-1.40.11
__METADATA_FIELD Creator TeX
__DOCUMENT_ID_UID_CONNECTIONS
__XMP_META_DATA_HH_EXTRACTION __START
__XMP_META_DATA_HH_EXTRACTION __END

Vidare besläktat meda båda föregående exempel på vad vi kan se kan det ge indikationer om preferens open source (mjukvara snarare än metadata promiskiöst delat för andras analys) liksom benägenhet eller möjlighet att budgetera inköp mer front-end nya koncept (längre fram indikeras nog mindre inressant här när något är vanligt: vad vi syftar är mer webb-baserade lösningar i dokumenthantering, sökning m.m.).


Exempel: ID för media-komponenter och dokument

Förutom WWW-kopplingar valde jag att ta ut PMID (National institutes of healths ID för journal-artiklar i deras för forskningsområdet helt dominerande databas med applikationer sökning m.m.) resp. DOI (brett använd namngivning av journalartiklar för betalande aktörer: dx.doi.org kan från DOI namnet föra dig vidare till sidan där artikeln finns. Och slutligen referenser till unika objekt XML-dokumentet i sig gör (d.v.s. potentiellt ett helt för applikationen lokalt kontext om ej hanterat i ett övergripande system för organisationen). Fler finns man kan ta ut med PMID och DOI är mycket stora och inte ointressanta om man för en större samling av dokument ex. vill komma ifrån att i övrigt riktat parsa och analysera referenser och istället behanda det som vilken sida som helst (vilket man nog ofta vill för dokument-samlingar likt DTIC jag tar ner just nu mer totalt där dokumenten kommer från många generationer resp. där referenser filtrerat av och till kan dyka upp i separata dokument):


Nedan några typiska ID för delar av PDF-filen (eller avseende hela den i någon instans):


__FUNCTION_WORKING METADATA_LOGIC
__PDF_FILE_NAME a569695.pdf
__IN_DIR_GIVEN c:\PTOOLS\PDF\
__METADATA_FIELD ModDate D:20130321040825-04'00'
__METADATA_FIELD CreationDate D:20120530205500-04'00'
__METADATA_FIELD Producer iText 5.0.4 (c) 1T3XT BVBA
__DOCUMENT_ID_UID_CONNECTIONS uuid:b3d384ac-d60e-4945-82e9-8b6e47f48eba uuid:3e6c776a-3058-4aee-856b-2ff7247c779f

Uppenbart ovan är att jag valt att inte ta med något sammanhang alls för dem. Möjlig användning för att söka samband tenderar ju att reducera probelmatik med ovsäentligt och vidare oavsett om vi refererar externt eller om någon refererar oss är det ett samband. Dock om vi vill se djupare i dem när hittade (för association jag bedömer intressantare tror jag övergripande att man når så långt man kan utan annan kunskap alls om dem: jämför med vad likheter i termonologi kan indikea om likhet i kultur eller expertområde mellan entiteter) bör åtminstone själv-refererande för dokumentet särskiljas varför jag också tar med delar av själva XML-koden (när vi vill förstå kopplingar specifikt mellan två entiteter). Känslan jag har att med minde än att man överdrivet tittar på standarden och ändå riskerar att komma fel är praktisk användning för träffar nog utmärkta för att vettigt begipa vad som är helt eller delvis självrefererande (eller praktiskt så avgränsat ex. dator med pgoramvaror) resp. vad som via indikerat XML resp. uttrycket kan vara mer generellt dokument-id format i något sammanhang.


Emellertid för ev. behov finns resp. dokument id eftersom mer basal xml-kod sparas (praktiskt som extraktionen tycks fungera - jag är nu ingen expert på PDF så finns praktiskt prövande kändes tidseffektivt - tas all XML läsbar med medan jag valde bort delvis parsad struktur för att spara håddisk vilket jag från början också hade med temporärt via DATA::DUMPER på objektet för pdf-filen):


<x:xmpmeta x:xmptk="Adobe XMP Core 5.2-c001 63.139439, 2010/09/27-13:37:26        " xmlns:x="adobe:ns:meta/">
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:Description rdf:about="" xmlns:xmp="http://ns.adobe.com/xap/1.0/">
         <xmp:ModifyDate>2013-03-21T04:08:25-04:00</xmp:ModifyDate>
         <xmp:CreateDate>2012-05-30T20:55:00-04:00</xmp:CreateDate>
         <xmp:MetadataDate>2013-03-21T04:08:25-04:00</xmp:MetadataDate>
      </rdf:Description>
      <rdf:Description rdf:about="" xmlns:dc="http://purl.org/dc/elements/1.1/">
         <dc:format>application/pdf</dc:format>
      </rdf:Description>
      <rdf:Description rdf:about="" xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/">
         <xmpMM:DocumentID>uuid:b3d384ac-d60e-4945-82e9-8b6e47f48eba</xmpMM:DocumentID>
         <xmpMM:InstanceID>uuid:3e6c776a-3058-4aee-856b-2ff7247c779f</xmpMM:InstanceID>
      </rdf:Description>
   </rdf:RDF>
</x:xmpmeta>

En försvarlig mängd av det för moderna kameror, dokumentsystem m.m. typiska formatet för att ge media producerat en unik identifierare. Exemplet nedan från samma som nummer två med versionshistorik tidigare:


__DOCUMENT_ID_UID_CONNECTIONS uuid:5B20892493BFDB11914A8590D31508C8 xmp.did:714C3D9B56AAE011B1AA9CA76A9EC25B xmp.did:724C3D9B56AAE011B1AA9CA76A9EC25B xmp.did:734C3D9B56AAE011B1AA9CA76A9EC25B xmp.did:F77F1174072068118083E0155A4A0A32 xmp.did:FB7F1174072068118083E0155A4A0A32 xmp.iid:006035250D2068118F628C890978B148 xmp.iid:008011740720681197A5820352CD19F2 xmp.iid:016035250D2068118F628C890978B148 xmp.iid:01801174072068118083C809E165E027 xmp.iid:01801174072068118C14E6A624D85812 xmp.iid:01801174072068118C14E72FBDC50C68 xmp.iid:026035250D2068118F628C890978B148 xmp.iid:02801174072068118C14D5EDF20B39EA xmp.iid:03801174072068118C14D5EDF20B39EA xmp.iid:04801174072068118C14D5EDF20B39EA xmp.iid:05801174072068118C14E72FBDC50C68 xmp.iid:321C424C262068118F62BE1AEC87ECB3 xmp.iid:331C424C262068118F62BE1AEC87ECB3 xmp.iid:341C424C262068118F62BE1AEC87ECB3 xmp.iid:351C424C262068118F62BE1AEC87ECB3 xmp.iid:361C424C262068118F62BE1AEC87ECB3 xmp.iid:371C424C262068118F62BE1AEC87ECB3 xmp.iid:381C424C262068118F62BE1AEC87ECB3 xmp.iid:624FA1CF212068118F62BE1AEC87ECB3 xmp.iid:634FA1CF212068118F62BE1AEC87ECB3 xmp.iid:644FA1CF212068118F62BE1AEC87ECB3 xmp.iid:654FA1CF212068118F62BE1AEC87ECB3 xmp.iid:664FA1CF212068118F62BE1AEC87ECB3 xmp.iid:674FA1CF212068118F62BE1AEC87ECB3 xmp.iid:684FA1CF212068118F62BE1AEC87ECB3 xmp.iid:694FA1CF212068118F62BE1AEC87ECB3 xmp.iid:6A4FA1CF212068118F62BE1AEC87ECB3 xmp.iid:6B4FA1CF212068118F62BE1AEC87ECB3 xmp.iid:6C4FA1CF212068118F62BE1AEC87ECB3 xmp.iid:714C3D9B56AAE011B1AA9CA76A9EC25B xmp.iid:724C3D9B56AAE011B1AA9CA76A9EC25B xmp.iid:734C3D9B56AAE011B1AA9CA76A9EC25B xmp.iid:B1D0A6060F2068118F62BE1AEC87ECB3 xmp.iid:B2D0A6060F2068118F62BE1AEC87ECB3 xmp.iid:F77F1174072068118083E0155A4A0A32 xmp.iid:F77F1174072068118083E5C6D079A5EF xmp.iid:F77F117407206811871FB2ED4E37AE08 xmp.iid:F77F117407206811B84094BC3C7FBB8B xmp.iid:F77F117407206811BA4A8DBC7C9B7B1F xmp.iid:F87F117407206811B84094BC3C7FBB8B xmp.iid:F87F117407206811BA4A8DBC7C9B7B1F xmp.iid:F97F117407206811BA4A8DBC7C9B7B1F xmp.iid:FB7F1174072068118083E0155A4A0A32

Vad som gör dessa intressanta rent allmänt (ej analyserat för ex. alls) kan tyckas svårbegripligt men jämför vi med vad vi menade att www-länkarna kunde berätta blir det kanske tydligare. Vi kan se propagering, samarbete, copyright-problematik eller oftare bara odefinierat lånat m.m. när enskilda indikationer dyker upp i flera dokument. Min erfarenhet av PDF är här ännu minst sagt begränsad men min allmänna känsla är att det utanför kontext där viss standardiserad användning fövantas eller är normalt är det kanske inte den mest intressanta källan innan man börjar laborera på riktigt stora mängder av dokument (vilket ju inte sällan redan kan vara motierat av andra tyngre orsaker där detta kommer gratis på köpet: statistiskanalys, indexering m.m.). Likväl är träffar åtminstone inte vad som inte inträffar för större organisationer på inte allt för många besläktade dokument (där en del om jag tolkar konceptet och PDF rätt i alla fall hittades för NATO relaterat mer prospekterande resonerande om forskning och teknik långt ifrån något alls känsligt och helt publikt men i alla fall vad jag ej förväntat på relativt få dokument).


Detta är en motsatt sida av det värde (utanför det kanske ofta mer primära att kunna organisera information man äger som stor organisation) i informationssäkerhet och kontroll av flöde in och ut eller mellan personer i företaget. I koncept av intrusion detection kan vi jämföra med "Snowden-detektor / sensor" diskuterad där vi enkelt kan se det som att själva förekomsten av vissa media-dokument via deras identifierade kan vara binärt förbjudet för en viss person, ligga längre från dennes normala användning, eller bygga upp mot något troligt problematiskt (ex. om många tusen dokument ej relaterade systemadministration identifieras på en medarbetares PDA när han vid den dagliga utpasseringen lämnar den till säkerhetspersonalen för kontroll som konsekvens av att ha en arbetsuppgift med odefinierat höga rättigheter i datanätverket).


Men likartat kan andra ibland beroende på lösning dra slutsatser (vi kan tänkas oss att varje instans adderar in något slumpmässigt för unikt värde via en ID-fabrik någonstans men heller inte det behöver utesluta analys här helt: hur snabbt förändras entropi över tiden? hur mycket nytt resp. gammalt i kontext av en person är aktuellt?). Förutom att skapa ett fascinerande problemområde med felaktiga format eftersom det tror jag kan behöva hanteras med reaktion för att systemet ska kännas betryggande i denna form av hantering (ett dokument existerande uttryckande säkerhetsfunktion men felaktigt d.v.s. potentiellt förfalskad är ju en ganska tung indikation om angrepp men förstås dyr att hantera om någon sitter och för in defekta saker av och till för att ockupera resurser i organisationen: dock finns ju det problemet besläktat i alla fall också utan identifiera via falska mail m.m.).


Exempel: OID och innehåll

I exakthet i domän av sammanfattad information om innehållet och dess organisation i ett kunskapssystem är många andra system utanfö själva pdf-dokumentet oftare mer talande. Nedan har vi data uttryckt, sparat och gjorts tillgängligt i en standard nu ganska vanlig för fakta-dokument, journal-artiklar m.m.



Också använd för att publicera och distribuera det kanske mer välkända id för bl.a. journal-artiklar: DOI. En tysk databas var där praktiskt enkel och välfungerande för mig medan jag ännu har att få helt klart för mig hur jag effektivsas kan få ner DOI för alla vetenskapliga journalers artiklar beskrivna samt gärna fångar ny publicering utan att behöva besöka dem alla regelbundet (i den mån det alls går: en del mediehus är ganska introverta också när det gäller titel, abstract, doi m.m. och tycks göra en hel del svår-tillgängligt):



Men jag undviker gärna att i onödan lära mig sådant i detalj innan det är nödvändigt (jag spindlar och analyserar annat just nu): det finns så mycket lika viktigt och stort men inom annat. Förutom kompletthet är det tilltalande att försöka få huvuddelen publicerat i segment vi analyserar som en domän eftersom det underlättar hur vi resonerar med statistiska modeller (eller också teoretiskt förenklat sampla dem gärna nära när det går slumpmässigt - risk bias och preferens finns ju dessutom med andra metoder om än kanske lättare att resonera om när befintligt data för detektion finns).


Just för metadata neda är det från Department of Defence, US del för att hantera kunskap, forskning m.m. information man etablerat på olika nivåer genom åren för att göra det lättare att ta fram nya värden från dem (kanske se samband mellan dokument om indirekta behov, var en lösning finns att anpassa i ennan försvarsgren, upptäcka nya innnovationer m.m.), ej dubbel-arbeta saker och ting o.s.v.



Rörande mängd och exakthet finns inget unikt jämfört med normalt för journal-artiklar publicerade idag på nätet: jämförbart metadata, ofta möjligt att spindla eller ta ner på annat sätt o.s.v. Dock finns också en mängd äldre studier, utredningar m.m. med början tidigt under 1900-talet och där känner jag ej till metadata tillsammans med dokument ens i närheten i möjlighet om vi ex. vill följa utveckling av koncept eller fånga upp koncept-associationer lika viktiga idag men mindre diskuterade och uttalade i modern litteratur därför att vetskap tas som givet etablerad redan i grundutbildning. Längre bak och särskilt vissa tidsperioder kan emellertid oftare endast ha meta-informationen (möjligen gäller det oftare 1960-talet än 1950-talet även om jag inte säkert vet eftersom jag fortfarande tar ner deras pdf:er resp. databas med metadata).


Det ska också sägas att samlingen av dokument och vetandet representerat i dom publika tjänsterna är omfattande och för många områden en mycket välfungerande databas och funktion för att hitta forskning över längre tidsperioder. För flera segment tycker jag att den fungerar enklare för att hitta vad önskat snabbare. Det gäller dock en del områden (bildanalys finns ex. mycket publicerat för) medan andra områden kan vara mindre intressanta för en försvarsorganisation att direkt finansiera eller bevaka för återpublicering.


Nedan ett exempel från 1949 existerande både som dokument ADA297559 och beskrivet med metadata:


____________________________________________________________________
__FUNCTION_WORKING FUNCTION_MANAGER
__URL http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA297559
____________________________________________________________________
__FUNCTION_WORKING OID_HARVESTING_BY_ACCESS_NUMBER
<Citation type="tr">
<AccessionNumber>ADA297559</AccessionNumber>
<CitationStatus code="">ACTIVE</CitationStatus>
<CitationClassification code="">UNCLASSIFIED</CitationClassification>
<CorporateAuthor>TECHNICAL INFORMATION SERVICE (AEC) OAK RIDGE TN</CorporateAuthor>
<UnclassifiedTitle>Manual of Instruments and Controls for the Brookhaven Nuclear Reactor. Book 3. Volume 1.</UnclassifiedTitle>
<TitleClassification code="">UNCLASSIFIED</TitleClassification>
<ReportDate>MAY 1949</ReportDate>
<PaginationOrMediaCount>167</PaginationOrMediaCount>
<PaginationCode>0</PaginationCode>
<ItemCost>14.60</ItemCost>
<ReportNumber nonPunctuated="AECM4415">AEC-M-4415</ReportNumber>
<MonitorAcronym nonPunctuated="XF">XF</MonitorAcronym>
<MonitorSeries nonPunctuated="XD">XD</MonitorSeries>
<ReportClassification code="">UNCLASSIFIED</ReportClassification>
<DistributionCode code="01">APPROVED FOR PUBLIC RELEASE</DistributionCode>
<DescriptorClassification code="">UNCLASSIFIED</DescriptorClassification>
<AbstractClassification code="">UNCLASSIFIED</AbstractClassification>
<InitialInventory>0001</InitialInventory>
<SourceSeries>1</SourceSeries>
<SourceCode>342750</SourceCode>
<GeopoliticalCode>4702</GeopoliticalCode>
<OrganizationTypeCode code="Z">INDEPENDENT FEDERAL AGENCIES</OrganizationTypeCode>
<DocumentLocation code="1">DTIC AND NTIS</DocumentLocation>
<Abstract>The instruments and controls for the Brookhaven Nuclear Reactor have evolved from a development program whose objective was, among others, to create a research facility. Throughout this program it has been clear that the ultimate arrangement of instruments and controls can not be fixed in advance of actual operation. The ultimate arrangement will depend in large measure on the research activity to take place in the future. It has been necessary, therefore, to provide a wide range of instrument capabilities and a large number of control functions.            Underlying this primary objective of creating a versatile research facility is the associated requirement that the reactor be safe. The requirements for safety are in some ways as varied and complex as those of research. In some instances they are dominant.            Exemplifying the flexibility and versatility of the reactor  instrumentation are electronic instruments of advanced design for measuring power at extremely low levels, indicating and recording the rate of rise of power level over a wide range of power, and regulating power at  preset levels. Exemplifying the variety of safety devices are instruments for monitoring power level detected by ionization chambers, by neutron  thermopiles, and by graphite and metal-cartridge thermocouples. Devices  which monitor the operability of equipment also contribute to the safety  of the reactor.   (KAR)  p.7</Abstract>
<Descriptor>*USER MANUALS</Descriptor>
<Descriptor>*POWER LEVELS</Descriptor>
<Descriptor>*NUCLEAR REACTORS</Descriptor>
<Descriptor>*POWER MEASUREMENT</Descriptor>
<Descriptor>CONTROL</Descriptor>
<Descriptor>MEASUREMENT</Descriptor>
<Descriptor>MONITORING</Descriptor>
<Descriptor>ELECTRONIC EQUIPMENT</Descriptor>
<Descriptor>GRAPHITE</Descriptor>
<Descriptor>IONIZATION CHAMBERS</Descriptor>
<Descriptor>LOW LEVEL</Descriptor>
<Descriptor>INSTRUMENTATION</Descriptor>
<Descriptor>RECORDING SYSTEMS</Descriptor>
<Descriptor>RANGE(EXTREMES)</Descriptor>
<Descriptor>INDICATORS</Descriptor>
<Descriptor>NEUTRONS</Descriptor>
<Descriptor>SAFETY EQUIPMENT</Descriptor>
<Descriptor>THERMOPILES.</Descriptor>
<FieldsAndGroups code="180501">Nuclear Fission Reactors(power)</FieldsAndGroups>
<SBIHoldingSymbol>NPS</SBIHoldingSymbol>
<handle>http://handle.dtic.mil/100.2/ADA297559</handle>
<PdfFileSize>12 MB</PdfFileSize>
</Citation>

Exempel: Text är bättre

Analyserar vi språk i text snarare än bilderna, visuell presentation m.m. vill vi just helst bara ha texten. Det sparar minne vid analystillfällen, beräkningskostnad för att ta fram den och utrymme på hårddisken (PDF dokument kan av och till mer än stora vara gigantiska om de inkluderar en mängd föga komprimerade bilder).


Med de lösninga jag använder nu (och tror jag mycket vanliga även om system säkert kan vara bättre och sämre här varierat med kostnad i utveckling och processande av vad visuell-information betyder) med av och till feltolkningar på visuellt mer komplexa sidor (önskar man ta kostnad för det och det tror jag ej är aktuellt här med något värde för mig kan det mesta om inte nära nog alla dessa fel fås bort i efterhand via bl.a. ngram-detektion, förståelse av hur url:er, standard information som doi, pmid m.m. skrivs och åtminstone enklare parsning med Natural language processing av meningar för att förstå om en radbrytning kombinerat punkt är en förkortning avhuggen eller meningsslut på rad ovanför: dyrt i beräkningstid när det handlar om miljoner dokument - en god skattning är att cirka 10 - 15 miljoner täcker upp en god andel av viktig publicerad forskning tillgänglig i pdf-format på nätet och cirka två miljoner en god andel av väsentligt från dom senaste åren när det handlar om journal-artiklar - där jag initialt ser cirka två till 25 miljoner som en lagom nivå för titel, abstrakt m.m. och bredare analys hela dokumenten för särskilda områden scarce i inlärda relationer eller särskilt viktiga vid någon tidpunkt).


__FUNCTION_WORKING PDF_TO_TEXT_LOGIC
__PDF_FILE_NAME ADA297559.pdf
__IN_DIR_GIVEN C:\PTOOLS\SAMPLER\DTIC\PDF\
__PAGES 167
__WWW_CONNECTIONS 
__EASY_JOURNAL_CONNECTIONS_EX_DOI 
__PAGE 1
UNCLASSIFIED
OJ
UNCLASSIFIED
M-4415
Subject Category: INSTRUMENTATION
UNITED STATES ATOMIC ENERGY COMMISSION
MANUAL OF INSTRUMENTS AND CONTROLS FOR THE BROOKHAVEN NUCLEAR REACTOR. BOOK 3, VOLUME I
r
KJ31SEm;a!BBanBI!! ^lM|
vUG.U6Jl9.9_a
biM& W''
?s^^M^^ ^Bm^asi^^^s^sf t^i^sz^,
May 1949
Servomechanisms Laboratory Massachusetts Institute of Technology Cambridge, Massachusetts
Jackson and Moreland Engineers New York, New York
Technical Information Extension, Oak Ridge, Tennessee
' %  ' ~ '1--"-" %  """ *
DTIS Q UALTrYlNSFEClED3
______________END_PAGE______________
__PAGE 2
Date Declassified: January 13, 1956.
LEGAL NOTICE
This report was prepared as an account of Government sponsored work. Neither the United States, nor the Commission, nor any person acting on behalf of the Commission:
A. Makes any warranty or representation, express or implied, with respect to the ac- curacy, completeness, or usefulness of the information contained in this report, or that the use of any information, apparatus, method, or process disclosed in this report may not in- fringe privately owned rights; or
B. Assumes any liabilities with respect to the use of, or for damages resulting from the use of any information, apparatus, method, or process disclosed in this report.
As used in the above, "person acting on behalf of the Commission" includes any em- ployee or contractor of the Commission to the extent that such employee or contractor prepares, handles or distributes, or provides access to, any information pursuant to his em- ployment or contract with the Commission.
This report has available copy.
been reproduced directly from the best
Issuance of this document does not constitute authority for declassification of classified material of the same or similar content and title by the same authors.
Printed in USA, Charge $1.00. Available from the Office of Technical Services, Department of Commerce, Wash- ington 25, D. C.
AEC, Oak Eidge, Tenn.
______________END_PAGE______________

Ytterst tilltalande gäller normalt att innehållsförteckning, tabeller över figurer m.m. liknande översätts till text utmärkt för journal-artiklar. Ex. från samma dokument:


__PAGE 6
CONTENTS VOLUME I
Page
9. Coarse Rod-Position Indicators - Component Description 3.35
10. Hod-Position Recorders 3.44
11. Parts List - Instrument Pinion Support Assembly
6546DN048 (For Regulating Hods) 3.47
12. Parts List - Instrument Pinion Support Assembly
6546DN047 (for Emergency Rods) 3.47
13. Parts List - Regulating-Rod Position Transmitter
Assembly 6546M030 3.49
14. Parts List - Regulating-Rod Position Indicating Unit
6546LN006 3 . 5 2
15. Parts List - ilmergency-Rod Position Transmitter
Assembly 6546EN029 3.56
16. Parts List - Kmergency-Rod Position Indicating Unit
6546BH001 3 . 5 9
17. Parts List - Coarse Rod-Position Indien tor
654&SN018 and 6546i.NQ19 3 . 6 2
18. Reference Drawings 3.65
19. Engineering Report References, D.l.C 6546, td.l.T, . . 3.65
______________END_PAGE______________
__PAGE 7

Ett till exempel från ADA297788 med tekniska data såväl som några referenser. Resultatet är varken bra eller dålig men knappast problematiskt för normal textanalys.


__PAGE 20
 fill
XJaxium Temperature Observed
2120  C to 2510 C
^-12"
30 lbs to 89 lbs
cci 4
20 lbs to 98 lbs
*2
10 cu it to 450 cu fir.
"Boron Analysis
 00 ppm to  10 (spec)
Total Ash
1 ppm to 17 ppm
gOMMAR T OF OPERATIONAL DATA
Adc kbjj  TO AEVI  AL "RIMS 11 " 1
Maximum Tariatian, Average* Range
2250 - 2400 C 60  =  65 lbs 40 = 50 lbs 100 - 300 cu ft  03 -  06 ppm 1  to 8  ppm
As the runs were made for production purposes no attempt to control the variables ms made  So correlation between the variables and the purity obtained can be drawn from the operational data 
&f Majority of the runs fall within these ranges
ABHSKBEC *C" BIBLIOGRAPHY
1. Neumark, H  R , Trans. Electrochem. Soc. 9jL, 367, (19*1-7)
2. Sermon, G. T. United Carbon Products Co. Report Ho  3 (19^7)
3. Sermon, G. T., "16OO MA Powsr Installation on 22 M Line", United Carbon Products Co. Report Ho. 13, (19*&)
4* Bodden, C. J. Richmond, M. S., National Bureau of Standards unpublished report, "Determination of Small Amounts of Boron in Project Materials".
5. Sermon, G. T., "Heating Tests in Granular Resistance Furnaces for preparing High Purity Graphite", united Carbon Products Company Report Ho. 6, (19*1-7)
19
______________END_PAGE______________

Söka alla politiker och alla regeringar och myndigheter

2013-11-13

Utdrag nedan är från en bredare postning jag gjorde Fler underliga Microsoft missar | Hans Husman om Information Warfare. Tipset på möjligheten är särskilt tänkt Microsoft medan det passar Google mycket sämre eftersom deras api:er och andra möjligheter att göra förfrågningar är tämligen begränsade alt. orimligt dyra. Men ser andra samhälssvärde av att inte ta transaktionskostnad här kan konceptet säkert passa dom minst lika bra.


Därmed inte sagt att jag tycker allt de gjort fungerat dåligt. Windows 2000 server tyckte jag fungerade bra.


Fortsätter man att utveckla Microsoft Scholar adderande vettiga vertikaler och data-dimensioner med kvalitet kan det nog bli en bra sak också.


Dessutom finns det ju liknande områden där konceptet kan återanvändas ex. för regerings- och myndighetsfunktioner med politiker för att enkelt hitta vad de skrivit, givit förslag på m.m. genom åren (och varför inte våga lite extra där för att vinna stort: promenera över till NSA och låna 20 - 30 användarnamn och lösenord och titta efter vad de ev. har om amerikanska och utländska politiker: att visa att man prioriterar EU och särskilt EU-giganten Tyskland tror jag uppskattas och kan göra allt möjligt kring monopol om nu något kvarstår m.m. enklare - Säger Merkel att Microsoft är en sund vän av EU är det så eftersom hon betalar för det hela). Vertikala kopplingar till utveckling över tiden rörande frågor, statistik m.m. ger enklare quality assurance än man annars normalt ids engagera sig sökande uppföljning från en mängd källor.


Jag har en hel del relaterad praktisk erfarenhet av att samla publicerad information från såväl dom amerikanska myndigheterna och funktionerna, EU, OECD, Världsbanken, diverse länder runt om i världen m.m. Och också om en del föredömligt välorganiserade informationssajter finns hör det till undantagen. Skillnader i presentation, funktioner o.s.v. kan dessuto storligen variera mellan delar av större entiteter likt EU såväl som att översikt över allt EU på webben saknas (i antal nästan helt givet ett större antal projektrelaterade sajter utspridda på refererat av större eu, ej refererade på eu-topp-domän resp. på olika topp-domäner för länder).


Något nyligen relaterat att ha samplat svenska regerings-relaterade sajter på engelska för första gången:


Uganda problemet resp. Svenska regeringens "odolda" kopplingar till management rapport producenten Rand corp.



Ett urval av andra små egenheter i Microsoft OS:


Microsoft Azure: SSL-problem (igen)
Microsoft tips: Kopiera istället för att skriva av eller skriva ut skärmdump

Säkerhetsproblem i Microsoft Windows troligt svårhanterat via konfiguration

Microsoft ropar på hjälp (igen) med nytt försök att slippa ansvaret för säkerhets-debacklet

Introduction to Information Retrievel

2013-09-13

Jag upplevde ett behov av en referensbok som sammanfattade dom vanliga mer grundläggande algoritmerna i segmentet och inhandlade Introduction to Information Retrievel. Just för det syftet var den utmärkt.


För andra syften finns ett par tre grupper av problem värda att peka på.


Precis som när jag diskuterade Microsoft i kontext av Bing! med dess stillstående serp-kvalitet gäller att man både i aktuell bok och där gör saker by the book men helt så vitt man kan konstatera saknar en samlad teori för vad som egentligen händer när folk skriver, när folk söker o.s.v.


Ett ex. är att man i förbegående konstaterar att första raden kanske är något som kan valideras högre relaterat "nyheter" med åtminstone en referens till det. Tradition gör att pressmeddelanden skrivs utan underrubriker och att pressmeddelandets första huvudrubrik när pressmeddelandet säljs vidare är inte självklart bibehållet. Det gör att underrubriker ej indikeras via html-taggar eller dyligt. De studier som konstaterat värden rörande sådant här alltid såvitt jag vet hamnat i dom underförstådda rubrikerna som läggs utan att indikeras rubriker inledande stycken. D.v.s. mest säkert med införstådd ingress inledande första och andra stycket.


Förståelse av sådant rör dock inte huvudfrågan vilket i indikerad förståelse ligger närmare hur vi optimerar processande utan full NLP med överföring till mening utnyttjande indikationer som i exemplet.


Att det går att göra någon av antagligen hundratals varianter av back-of-words med mer eller mindre ad-hoc viktning av rubriker, strong m.m. är givet. Inga av de grundläggande algoritmerna i eller utanför Introduction to Information Retrievel berör sådan validering.


Det var ett av de mer signifikanta värdena jag fick av att själv börja denna del av resan från den kognitivia psykologin i möjlighet att etablera modell för hur vi kan se på och hantera sådant som mest enkelt rubriker (d.v.s. mina koncept med do resp. describe och cues indikerande bredare pre-aktivering än vad konvergens därefter ger).


Större problem två (av totalt två) är mindre i sitt teoretiska omfång men är liksom i Mannings bok Foundations of Statistical Natural Language Processing väldigt över-uttryckt i Introduction to Information Retrievel: LSA.


Vi har en mängd andra möjligheter i eller utanför ICA-familjen där särskilt de utanför ICA är minst sagt viktigare givet det subkulturella överuttryck LSA tenderar att få genom att vara oftare uttryckt och gissar jag inte sällan hör till det mer algebraiskt avancerade datastudenten möter under sin utbildning före eller efter ev. doktorandutbildning. Det gör att viss bredd i lösningar utanför det är viktigt.


Den betydelsen ökar så klart av att så vitt jag vet finns inget sammanhang där LSA inte är sämre än alternativ. För några grupper av sådana situationer - och dom i särklass största - samtidigt som LSA är mycket mer långsamt med övriga inkl. hela ICA-familjen resp. Hotelling-familjen (PSA) är ungefär lika långsamma.


I sammanfattning: En acceptabel referensbok men delade upplever jag dom (väldigt nära) orsaker som ger en acceptabel Bing! lösning (m.m. liknande) men också i hela koncept-områden som boken ej berör varför Bing! år efter år efter år adderar föga eller inget värdebyggande mer än lite anti-spam förbättring. Men som i undervisning är mindre lämplig utan kompletterande översikt över många fler alternativ än den idag föråldrade och sämre LSA.