Come costruire un grafico della conoscenza del prodotto senza perdita di prova di origine

Inizia con una domanda che il business deve rispondere

Un grafico della conoscenza è utile quando migliora una decisione ripetibile. Iniziare con domande quali la parte sostitutiva è approvata per questa macchina, che i registri dei fornitori si riferiscono allo stesso prodotto, che i reclami dei prodotti sono sostenuti da un documento corrente, o che l'organizzazione possiede un marchio particolare. Evitare di iniziare con un obiettivo di collegare tutto.

Scrivere la risposta prevista e le prove che un recensore avrebbe bisogno di fidarsi. Una risposta di adattamento, ad esempio, può richiedere l'identità del prodotto, la macchina e il modello, la gamma di produzione, la posizione, il documento sorgente, la data di origine e lo stato di revisione. Quella lista diventa la prima fetta del modello.

M.I.A.I Knowledge Graph è progettato per collegare entità, prove e relazioni in una conoscenza commerciale riutilizzabile. Le sue capacità approvate riguardano le entità canoniche, la modellazione delle relazioni, la provenienza delle prove e l'accesso alla conoscenza riutilizzabile, inclusi i link di prodotto-applicazioni, la risoluzione duplicata e le risposte di prova-consapevole.

Entità separate, attributi e relazioni

Un'entità è una cosa con la propria identità: un prodotto, variante del prodotto, modello di macchina, produttore, organizzazione, documento o posizione. Un attributo è un valore che descrive un'entità, come un nome del modello, un peso o una data di pubblicazione. Una relazione collega due entità, come fabbricate, compatibili con, sostituzioni o provettenute.

La distinzione impedisce un problema di catalogo comune. Se un'applicazione della macchina viene memorizzata solo come testo gratuito all'interno di una descrizione del prodotto, non può essere revisionata, interrogata o aggiornata in modo affidabile. Quando il modello di macchina è un'entità e la compatibilità è una relazione esplicita, l'azienda può ispezionare tutti i reclami di supporto, trovare conflitti e riutilizzare le stesse conoscenze in ricerca, pagine di prodotto e strumenti di supporto.

Il modello W3C RDF descrive le dichiarazioni dei grafici come triple oggetto-predicate-oggetto. Questo è un modello mentale utile anche quando la prima implementazione utilizza tabelle relazionali o documenti. Il punto importante è che il rapporto ha una direzione e un significato espliciti piuttosto che essere deferiti da un campo di testo condiviso.

• Entità: prodotto P-1042
• Rapporto: è compatibile con
• Entità: macchina modello M-208
• Qualificazione: posizione anteriore e gamma di produzione applicabile
• Prove: bollettino del fornitore B-77, pagina 4
• Stato: rivisto e approvato in una data registrata

Creare identità canoniche senza cancellare i record sorgente

Un'entità canonica rappresenta l'attuale visione dell'azienda di una cosa reale. Dovrebbe avere un identificatore interno stabile che non dipende da un titolo, URL o descrizione del fornitore. I record di origine rimangono collegati ad esso con i propri identificatori, valori e timestamp.

Non unire record solo perché i loro nomi assomigliano a vicenda. I titoli dei prodotti, i nomi delle aziende e le descrizioni dei modelli contengono abbreviazioni, differenze di punteggiatura e parole riutilizzate. Le prove forti possono includere un codice regolamentato, GTIN, il numero di parte del produttore, l'ID della piattaforma, il numero di registrazione dell'azienda o una chiave composito approvata. Le prove accettabili differiscono per tipo di entità.

La risoluzione di ammissione deve restituire una decisione e la sua base: stessa entità confermata, possibile corrispondenza che richiede revisione, o entità separata. Conservare le decisioni di corrispondenza respinte e superate in modo che la prossima importazione non riscatta la stessa ambiguità. Se due fonti registrano conflitti, il grafico può connettersi sia all'entità canonica, mantenendo separate le rivendicazioni contrastanti.

Definire un piccolo vocabolario di relazione

I nomi delle relazioni fanno parte del contratto d'affari. Definire ogni termine, la sua direzione, i tipi di entità consentiti e se è simmetrico, transitivo o time-bound. Correlato è raramente abbastanza preciso per una decisione operativa.

Per i prodotti, le distinzioni utili possono includere is-variante-of, sostituisce, è-sostituito-by, è-compatibile-con, è-consumabile-per, fabbricato-by e distribuito-by. Il vocabolario del prodotto di Schema.org illustra diverse connessioni di prodotto distinte, tra cui isVariantOf, isRelatedTo, isSimilarTo ed isConsumableFor. Queste etichette non devono essere trattate come intercambiabili.

Preferire una relazione approvata su più vicino-duplicati. Se un team utilizza la misura, un altro vale a dire e un altro compatibile, decidono se hanno lo stesso significato aziendale. Se il significato differisce veramente, mantenere i termini separati e documentare la differenza. Il vocabolario coerente rende le domande, la convalida e le spiegazioni degli utenti affidabili.

Trattare la compatibilità come reclamo qualificato

Molte relazioni commerciali hanno bisogno di più contesto di una linea semplice tra due nodi. La compatibilità del prodotto può dipendere dalla gamma seriale della macchina, anno, motore, configurazione, posizione o variante regionale. I rapporti del fornitore possono avere date di contratto e territori. La proprietà organizzativa cambia nel tempo.

Rappresentare quel contesto su un rapporto record o entità di affermazione. Conservare l'oggetto, il tipo di relazione, l'oggetto, le qualifiche, le date efficaci, le prove, la fiducia o lo stato di revisione, e il proprietario responsabile. Non nascondere le qualifiche in una nota che le applicazioni non possono interpretare.

La specifica W3C RDF nota che le relazioni possono cambiare nel tempo e che le fonti possono fornire diversi stati di grafico in tempi diversi. In termini pratici, non sovrascrivere il rapporto approvato di ieri senza storia. Chiudere il suo periodo valido, creare l'affermazione riveduta e mantenere la ragione del cambiamento.

Attacca la provenienza ai reclami, non solo i file

Salvare un PDF sorgente in una cartella non è sufficiente. Collegare il reclamo preciso al record di origine, versione del documento, pagina o riga, metodo di estrazione, tempo di cattura e recensore. Un utente dovrebbe essere in grado di passare da una risposta all'affermazione e poi alle prove che lo supporta.

Il modello W3C PROV-O fornisce concetti per descrivere entità, attività e agenti, tra cui derivazione, generazione e attribuzione. Un'implementazione di business non ha bisogno di esporre quel vocabolario ad ogni utente, ma deve preservare le stesse domande: da che cosa derivava questa rivendicazione, da quale processo lo ha creato, e da chi o cosa era responsabile?

Tenere le prove di origine immutabile dove pratico. Se una pagina web del fornitore cambia, conservare la versione acquisita o il checksum consentito dal contratto di origine. Se un foglio di calcolo viene corretto, creare una nuova versione sorgente piuttosto che cambiare silenziosamente le prove dietro un'approvazione esistente.

• Sistema sorgente e identificatore record sorgente
• Versione del documento, URL, pagina, riga o sezione
• Valore catturato e timestamp di cattura
• Metodo di trasformazione o di estrazione
• Revisione, decisione e data di decisione
• Periodo di validità, revisione e collegamenti di supersessione

Gestire rivendicazioni contrastanti visibilmente

Un grafico diventa pericoloso quando diventa disaccordo in falsa certezza. Due fornitori possono fornire dimensioni diverse, un documento del produttore può sostituire un vecchio bollettino, o una descrizione dell'ERP può non essere d'accordo con un foglio di dati del prodotto. Conservare ogni affermazione con le sue prove prima di selezionare un valore preferito.

Le regole di prevalenza dovrebbero essere esplicite e limitate a un dominio. L'ERP può possedere lo stato di SKU vendibile, il produttore può possedere la compatibilità tecnica, il PIM può possedere copia di marketing approvata e una piattaforma di commercio può possedere il suo ID di destinazione. Un record recentemente modificato non è automaticamente il record più autorevole.

Quando le regole non possono risolvere un conflitto, posizionarlo in una coda di revisione con le entità interessate, i valori, le fonti e gli usi a valle. Continua a servire l'ultima affermazione approvata dove sicuro, etichetta l'incertezza dove necessario e bloccare la pubblicazione ad alto rischio quando non c'è una risposta affidabile.

Un esempio concreto: una parte, tre sistemi e due modelli di macchine

Considerare un distributore con un idler registrato in un ERP come articolo 1042, in un file fornitore sotto un numero di parte del produttore e in un negozio online con un prodotto separato e ID variante. Il foglio di calcolo del fornitore dice che si adatta a due modelli di caricatore binario compatto, mentre un PDF più vecchio elenca solo uno.

Il grafico crea una parte canonica e collega ogni record sorgente ad essa senza cancellare gli ID originali. Crea un produttore separato, un prodotto, un modello di macchina e un'entità documentale. Due asserzioni di compatibilità collegano la parte ai modelli della macchina. Ogni affermazione registra la sua posizione, l'intervallo applicabile, la fonte e lo stato di revisione.

Il primo modello è supportato sia dal foglio di calcolo corrente che dal bollettino precedente, così lo specialista del prodotto lo approva. Il secondo appare solo nel nuovo foglio di calcolo e rimane in sospeso fino a quando la prova del produttore viene controllata. Ricerca Storefront e un'applicazione di risposta possono utilizzare il rapporto approvato, ma non deve presentare quello in sospeso come fatto.

Quando un bollettino rivisto conferma il secondo modello, il recensore collega le nuove prove e approva l'affermazione. La risposta può ora spiegare la vestibilità e citare il bollettino di supporto. Se la parte viene successivamente sostituita, una nuova relazione registra la sostituzione senza cambiare l'identità o la storia dell'oggetto originale.

Convalidare il grafico prima che le applicazioni lo riusino

La convalida deve coprire l'identità, la struttura e il significato di business. Controllare che gli identificatori canonici sono unici, i tipi di entità richieste sono presenti, i endpoint di relazione utilizzano tipi consentiti e le qualificazioni obbligatorie esistono. Un reclamo di compatibilità senza uno stato di origine o di revisione non deve raggiungere un'applicazione orientata al cliente.

Aggiungi regole di dominio per strutture impossibili o sospette. Un prodotto non dovrebbe sostituirsi. Una variante non dovrebbe appartenere a diversi prodotti genitori non correlati a meno che il modello lo consenta esplicitamente. Catene di ricambio circolari, intervalli di validità sovrapposti e affermazioni attive duplicate meritano la revisione.

Prova domande rappresentative e risposte attesi. Includere casi positivi, conflitti deliberati, prove incomplete e reclami revocati. Il grafico è pronto per il riutilizzo solo quando le applicazioni possono distinguere le conoscenze approvate, in attesa, sostituite e rifiutate.

Dare applicazioni solo la conoscenza che sono autorizzati a utilizzare

L'accesso riutilizzabile non significa accesso illimitato. Definire visualizzazioni o API per ogni applicazione. Un cercatore di prodotto pubblico può ricevere relazioni di prodotto approvate e etichette di prova sicure dal cliente. Uno strumento di supporto interno può vedere i reclami in sospeso e le note del recensore. Un'interfaccia di audit potrebbe aver bisogno della catena di prova completa.

Restituisce l'identificatore dell'entità canonica, risposta, tipo di relazione, qualificanti rilevanti, status e riferimento di prova insieme. Non dare un assistente AI un'esportazione di testo appiattita e si aspettano che ricostruisca l'autorità. Le risposte alle prove-consapevoli richiedono un recupero strutturato che porta la base della risposta nel processo di risposta.

Log quale versione del grafico e affermazioni supportate una risposta importante. Quando la conoscenza cambia, l'azienda può identificare le pagine interessate, raccomandazioni o risposte di supporto e decidere se hanno bisogno di aggiornamento.

Misurare la fiducia e il riutilizzo, non la dimensione del grafico

Nodo e rapporto conta mostrare attività, non valore aziendale. Misurare le entità duplicate risolte, percentuale di affermazioni critiche con prove, tempo per rivedere i conflitti, affermazioni stanti rilevate, applicazioni che riutilizzano le conoscenze approvate e le domande risposto senza ricerca manuale.

Traccia la qualità per tipo di relazione. I link di prodotto-applicazione possono richiedere prove complete e approvazione specialistica, mentre un link relativo-content a basso rischio può utilizzare un processo più leggero. Un singolo punteggio di completezza può nascondere gravi lacune nelle relazioni che contano di più.

Verificare se il grafico riduce le risposte contraddittorie tra i canali. Se la ricerca dei prodotti, l'assistenza clienti e le pagine dei prodotti sono ancora in disaccordo, ispezionare le loro opinioni approvate, la cache e la proprietà della fonte piuttosto che aggiungere più dati.

Elenco di controllo della disponibilità del grafico della conoscenza

• Iniziare con una domanda aziendale definita e la decisione prevista.
• Dare ad ogni entità canonica un identificatore interno stabile.
• Conservare i record di origine e i loro identificatori originali.
• Definire nomi di relazione, indicazioni e tipi di entità consentiti.
• Rappresentare le qualifiche e le date efficaci esplicitamente.
• Attaccare le prove e la provenienza ad ogni affermazione importante.
• Tenere i conflitti visibili fino a quando una regola approvata o il recensore li risolve.
• Convalida identità, struttura, regole aziendali e risposte attesi.
• Esporre opinioni approvate appropriate per ogni applicazione di consumo.
• Registrare quali affermazioni supportarono risposte conseguenti.
• Misurare la copertura delle prove, la risoluzione dei conflitti e la coerenza tra i canali.