top of page

APP BOT A.I. ASSISTEN CHIRP CREATION

AR-DesignCornerIcon.png
800Chirp-botIcon.png

DA SVILUPPARE un nuovo APP corner APP COGNITIVE SEARCH

Vedi link
https://learn.microsoft.com/en-us/azure/search/search-howto-indexing-azure-blob-storage
il container deve contenre dei tipi di files dai quali è ricavabile testo.
Forse nello sviluppo Ai si potrà operare sulle immagine in qualche modo.
Questo Search cognitive sono per i testi.
I formati ammessi sono:
CSV (see Indexing CSV blobs)
EML
EPUB
GZ
HTML
JSON (see Indexing JSON blobs)
KML (XML for geographic representations)
Microsoft Office formats: DOCX/DOC/DOCM, XLSX/XLS/XLSM, PPTX/PPT/PPTM, MSG (Outlook emails), XML (both 2003 and 2006 WORD XML)
Open Document formats: ODT, ODS, ODP
PDF
Plain text files (see also Indexing plain text)
RTF
XML
ZIP
Pertanto come servizio a pagamento da parte di un cl o user con conto base possiamo gestire i containerr
-testuali (blobs del cl o user)
- i pdf generati dall PDFRasterizer APP
- i text generati dal Cognitive langua task APP
Bisogna vedere come si può mediante rest API crere i nuovi indexer.
La parte svolta in APP102 (ed inserita ad esempio in Advanced Email APP per la ricerca di CL/US) è invece basata su indexer sulla tabel CLorUs di default già creato dal portale con update ogni ora.

Il cliente o utente con base acnt può usfruire di questi sevizi con ACNT-COGNITIVE-SEARCH.

Itanto riguarda creare indexes su testi o pdf  (anche altri formati ma non gestiamo).

E' possibile che il container dei texti sia indicato anche per lingua:

<cluscode><languagecode>--textual-blobs attualmente è solo per <cluscode>

e <cluscode>-vocal-audio-clips-blobs

e

<clcode>-pic-blobs-normal

e

<clcode>-app500-gltf-blobs (non previsto come attachemnt ad email però)

e

<clcode>-pic-blobs-standard (FORSE DA ELIMINARE quest distinzione standard e norma)

​

Pe le movies vedremo la nuova versione che sostituisce i media sevrices ?????????

MOVIE ??

Per ip pdf e prodotti audio &  testuali da APPMYLANGSERVICE ls acselta dell'attachemt ha un algoritmo a parte (ved advanced email page)

​

Penso sia meglio che utti i blob wac, picture textual movies siano ben decritti ma vandano nei container senza ripartire in containers per lingua.

Nella gestione del ADVANCED EMAil quando si sceglie un attachemt è compito del logged wif specificargli una lista di lingue per la quale è adatto sapendo dalla sua descrizione (del blob) cosa è meglio afre senza tropèpe rigidità.

Se va bene per tutti i recipeint allora lasci per l'attachemnt la lista vuota.

Diversoè quando l'atatcment 

Le risorse pdf vanno nei container tipo nel nostro demo

cl000077pdftremitiislandsv2  il base e quelli tradotti l000077pdftremitiislandsv2eses|frfr| ...

Qui non è stata fatta distinzione fra pubblico e privato.

Penso la soluzione migliore sia: un cl or us con conto base decide di usfruire del cognitive search.

Entra nell'ambito di APPCognitiveSearch nella UI di abilitazione e refresh

Chiede di attivare l'indexer. 

Attualmente abbiamo

arqnaservice-asme3kqlychxf2a

ma il numero di serch servce è comunque limitato.

Nell'attuale free è solo 1

Se passiamo al S1 (capinete) al max sarebbero 16.

Service limits for tiers and skus - Azure Cognitive Search | Microsoft Learn

Pertanto è impossibile dedicarne uno a ciascun cl o us.

Definito quindi al momento un solo search service (e ne manterrei uno solo) all'interno vengono aggiunti (vedere come se fa da API, al momento l'ho fatto dal portale per aggiungere come SYS la T:CLorUS)

La richiesta di attivare il servio da parte di un cl/us e la form attivo /refresh fa si che nell'indexer siano aggiunti il container blob text del richiedente e poi tutti i suou container che opsitano le pdf resource che ha creato fino al momento

e i container creati per ospirate la parte textuale delk Gognitive Language Task  che sono del tipo

<cluscode>/<rowkeydel task> <languagecode lower> come da tabella

T:LangCognitiveTasksResults

essendo PK l'owner .

Allora bisogna valutare direi caso pe caso:

- se il cl entra nella ui di attivazione del servizio collocata in APPCognitivSeearh il suo <cluscode><languagecode>-textual-blobs  è aggiunto all'indexer (vede se API può evitare se esiste già)

- deve poi richiedere la lista delle sue risorse pdf e decidere quali container relativi desidera aggiungere e evita di fare se esiste già oppure rimuovere

- deve poi chiedere lista dei suoi <cluscode>/<rowkeydel task> <languagecode lower> e decidere quali container relativi desidera aggiungere e evita di fare se esiste già oppure rimuovere

Eì chiaro che così facendo la ricerca effettuata nell'APP associata (come contenuto) APpCognitivesearchView consente a chiunque una ricerca 

Qui dobbiamo rivedere come funziona la ricerca quando ci sono anche dei container oltre che table.. come funziona la API. Ho già fatto prove sui container indicizzati nella APP102??

Ma intanto questo approccio fa si che ciò che va nell'indexer di un cl/us ad semoio i suoi bobs text divengono pubblici per l'algoritmo di cognitive serach.

Ma la parte di filtro

Filter on search results - Azure Cognitive Search | Microsoft Learn

dice che:

A filter provides value-based criteria for including or excluding content before query execution. For example, including or excluding documents based on dates, locations, or language. Filters are specified on individual fields. A field definition must be attributed as "filterable" if you want to use it in filter expressions.

Dato che l'indexer mi sembra un full text globale che ha trattato tutto quello che è stato messo dentro(Tables e containers testuali) l'uunio modo di  limitare è quallo di:

- per i blobs testauli create due linee di textual blobs <cluscode><languagecode>-<private!public>textual-blobs e solo il public viene aggiunto all'indexer. Allora nella APP corner che crea un textul blob (da fare) da file locale o altra sorgent, il logged deve decidere se vuol fare un blob privato o pubblico e va nell''appropiato container

- per le risorse pdf e tash cognitive è lui che segnie quali meterre e quli no ma in questo caso perderebbper propio uso la potenzialità del full text search per uso personale di sviluppo.

Allora: se li mette tutti -> divengono pubblici x il full text

- se li lascia fuori -> perde la potenzalità del full text sui suoi privati

Come rimediare?

Penso con l'uso dei filters

Security filters for trimming results - Azure Cognitive Search | Microsoft Learn

in particolare Security filter

Se funziona qusto approccio (sulle T mi sembra più chairo, sui container meno) allora non é necessario <private!public>t perchè  mdiante un security deciso dal owner potrbbe limitare atutti (meno lui che lo conosce) di inserire nella full text result quei dati che no lo conoscono.

LA SOLUZIONE

Search over Azure Blob Storage content - Azure Cognitive Search | Microsoft Learn

​

Add "skip" metadata the blob

The indexer configuration parameters apply to all blobs in the container or folder. Sometimes, you want to control how individual blobs are indexed.

Add the following metadata properties and values to blobs in Blob Storage. When the indexer encounters this property, it will skip the blob or its content in the indexing run.

Property nameProperty valueExplanation

"AzureSearch_Skip""true"Instructs the blob indexer to completely skip the blob. Neither metadata nor content extraction is attempted. This is useful when a particular blob fails repeatedly and interrupts the indexing process.

"AzureSearch_SkipContent""true"This is equivalent to the "dataToExtract" : "allMetadata" setting described above scoped to a particular blob.

​

Il problema è allora come modificare/settare metadata di un blob:

Per settare il metadata

Manage properties and metadata for a blob with .NET - Azure Storage | Microsoft Learn

che è un key value 

Ma se usiamo questo metadata allora efefttua skip e perdiamo il full text sarch per qulli privati: non li fa vedere ma per tutti anche se chi fa il cognitive serach è l'owner.

Penso che lk'approccio possa essre in base a ciò che è insicato in

Content metadata properties - Azure Cognitive Search | Microsoft Learn

"The following table summarizes processing done for each document format, and describes the metadata properties extracted by a blob indexer ​"

a noi interessa il pdf ed il text/plain.

​

​

bottom of page