ewso
1.0.0
Aperçu de l'EWSO
EWSO est une ontologie d'une méthodologie d'ingénierie d'ontologie dynamique qui exploite la représentation structurée des connaissances pour améliorer les résultats LLM à quelque fin que ce soit. EWSO implique une syntaxe abstraite pour la construction de modèles de méthodologie d'ingénierie d'ontologie LLM Persona invites peut utiliser pour produire des réponses structurées. Ces structures sont toujours stochastiques et nécessitent des rejecteurs dans les configurations de conversation de jeu de type Gan pour être corrigées. Ce document fournit la base d'une syntaxe formalisant l'utilisation d'interprètes LLM à l'intérieur des agents compatibles AI pour construire de manière autonome une ontologie synthétisée à partir de sorties agrégées de conversations antérieures, permettant de l'ontologie a-aéré décompression.
Une structure Web émergente est un groupe de couches d'entités émergentes abstraites liées les unes aux autres dans une chaîne de transformation, par exemple, pour représenter les relations à l'intérieur des relations (comme un 2-morphisme ontologique), qui sont des liens dans une chaîne qui se traduit par une transformation d'une boucle de rétroaction double construite de deux boucles de rétroaction doubles dans une boucle de rétroaction double. En d'autres termes, il crée ce qui est considéré comme un concept complet et le fait en utilisant deux langages principaux qui peuvent être utilisés dans les flux de travail pour l'exploitation et l'extraction de l'ontologie qui ont des boucles de rétroaction doubles construites en boucles de rétroaction doubles (etc.). Vous trouverez ci-dessous deux exemples de langues principales: Corl et PCNL. Ils peuvent se combiner avec les principes EWSO pour créer un moteur de forage et d'abstraction ontologique continu qui explique les connaissances qui ont du sens des observations qu'elle a à propos de son propre flux d'informations co-émergent (les réflexions LLM).
https://www.mermaidchart.com/raw/57ad88cf-63a3-41ec-a7ce-29b9eb711bde?theme=light&version=v0.1&format=svg
Apprêt corl pour les systèmes d'IA
Objectif: Corl est un langage de compression de syntaxe conçu pour les agents d'IA travaillant avec la représentation des connaissances au format OWL. Il offre un moyen lisible par l'homme de définir des éléments ontologiques tout en assurant une traduction automatique lisse dans le hibou.
Règles de base
Déclaration d'entité:
Syntaxe: entité: mappage du hibou: OWL: classe avec rdf: id égal à la subsomption (IS_A):
Syntaxe: sous-classe: mappage du hibou: RDFS: Relation sous-classe. Déclaration des biens:
Syntaxe: propriété: (domaine :, plage :) mappage de hibou: OWL: ObjectProperty (pour les propriétés des objets) ou OWL: DatatyPeproperty (pour les propriétés liant les valeurs de données), ainsi que RDFS: domaine et RDFS: restrictions de plage. Affectation d'instance:
Syntaxe: instance: OF: mappage du hibou: OWL: NamedIndividual avec RDF: Type défini sur la classe spécifiée. Règles avancées
Caractéristiques de la propriété: Propriété transitive: ... Propriété symétrique: ... Propriété fonctionnelle: ... Propriété fonctionnelle inverse: ... Cardinalité:
Syntaxe: propriété: ... (cardinality_min :, cardinality_max :) mappage de chouet: hibou: minCardinality, Owl: maxcardinality restrictions. Expressions de classe complexes (opérateurs booléens):
Classe: équivalent_to: et classe: équivalent_to: ou classe: équivalent_to: pas quantificateurs:
... (hasproperty sombres) => hibou: certains VALUESFROM ... (Hasproperty uniquement) => OWL: AllValuesFrom Propriétés et données de données:
Data_property: (domaine :, plage: xsd: type de données) (Exemples de datatypes: xsd: entier, xsd: chaîne, xsd: date) Notes supplémentaires
Commentaires: précédent les commentaires avec // (pour les humains, ignorés pendant la traduction) Sensibilité à la casse: la syntaxe de Corl peut ou non être sensible à la casse basée sur les choix du préprocesseur. Espaces de noms: Un mécanisme pour gérer les préfixes et l'iris pour assurer une intégration fluide des concepts à travers les ontologies est nécessaire. Processus de traduction
Prérocesseur: un programme gère la tokenisation, la validation de la syntaxe CORL par rapport aux règles définies et les rapports d'erreur potentiels. Génération des hiboux: suit une cartographie directe des constructions CORL à leurs axiomes de hibou correspondants. Peut nécessiter le choix de format de sortie de la OWL de hibou (XML, syntaxe fonctionnelle, Manchester, etc.). N'oubliez pas que Corl évolue toujours aux côtés des capacités d'IA. Attendez-vous à des extensions futures potentielles pour capturer des complexités logiques nuancées!
Structure de méta-cataframe
Tables de base
Entity_Table
Entity_id (clé primaire) Entity_name Entity_Type (valeurs possibles: «classe», «ObjectProperty», «DataTypeProperty», «NamedIddividual») Description (Facultatif - pour la compréhension humaine, pas strict Owl Compliance) Relation_Table
relation_id (clé primaire) source_entity_id (clé étrangère -> entity_table) Target_entity_id (clé étrangère -> entity_table) relation_type (valeurs: 'subclassof', 'équivalentClass', 'disjointwith', 'hasproperty', ...) Property Cartetics Tables caractéristique Tables caractéristiques
Property_Charottetics
propriété_id (clé étrangère -> entité_table, entité_type contrainte aux propriétés) caractéristique_type (valeurs: 'transitif', 'symétrique', 'fonctionnel', 'inverseFonctionnel')
restriction_id (clé primaire) Property_id (clé étrangère -> entity_table) restriction_type (valeurs: 'someValuesFrom', `` AllValuesFrom '', `` Hasvalue '', `` Cardinality ') restriction_class (si applicable, clé étrangère -> entité_table) Restriction_datatype (si applicable) Cardinality_min (si applicable_maxype (if Applicable) Cardinality_min (IF applicable_maxype (IF applicable) Cardinality_min (If ApplaceTy applicable) Entrées illustratives de méta-dataframe
| Entity_Table | | --- | --- | --- | --- | | 1 | Chien | Classe | ... | | 2 | Personne | Classe | ... | | 3 | Hasowner | ObjectProperty | ... | | 4 | Fido | NamedIndividual | ... |
| relation_table | | --- | --- | --- | --- | | 1 | 1 | 2 | Sous-classe |
| 2 | 3 | 2 | Hasproperty | | 3 | 3 | 1 | Hasproperty |
| Property_Charottetics | | --- | --- | | 3 | transitif |
| Restrictions | | --- | --- | --- | --- | --- | --- | | 1 | 3 | Somevalues de la part | Chien | ... | ... | | 2 | 2 | Cardinalité | Hasowner | ... | 1 | 1
Notes
Cette structure reflète les relations inhérentes trouvées dans les ontologies de hibou. «...» Indiquez où des annotations lisibles par l'homme pourraient être ajoutées. Les détails du type de données dépendent du vocabulaire «XSD» choisi utilisé. La représentation complexe de l'axiome peut nécessiter des extensions.
Représentation de l'entité: toutes les entités sont encapsulées entre parenthèses, par exemple, (entity:Name) . Les types d'entités sont capitalisés et des instances spécifiques peuvent être en minuscules ou suivre des conventions de dénomination spécifiques.
Représentation des relations: les relations entre les entités sont représentées comme des flèches directionnelles avec des types de relations entre parenthèses, par exemple, -[r:RELATIONSHIP_TYPE]-> . Les types de relations sont tous des plafonds et sont séparés par soulignement pour les relations multi-mots. Seules les relations acceptables sont: Part_of, IS_A, instanciements / instanciés_by "(où x instancie y si l'instance réalisable, c'est-à-dire l'existence, de y prouve la validité du schéma de réification x)
Extension des relations au-delà de IS_A , PART_OF , INSTANTIATES : Pour incorporer des types de relations supplémentaires tels que HAS_ATTRIBUTE , une règle d'expansion formelle est utilisée:
HAS_ATTRIBUTE peut être décompressé en (entity:Attribute)-[r:PART_OF]->(entity)-[r:IS_A]->(Entity) . Cela montre que les attributs font partie d'une entité et décrivent ce que l'entité est ou a.USED_IN et d'autres relations non directement couvertes par IS_A , PART_OF , INSTANTIATES peuvent être mappés à ces trois relations de base ou à une combinaison de celles-ci, en s'assurant toujours qu'il existe une décomposition logique qui se rapporte aux types de relations fondamentales. La sémantique comme "Contient" dénotait algorithmiquement ISA / Partof / instancie sur la façon dont un conteneur est une entité, le but en fait partie, le confinement est un objectif, les conteneurs ont un but de conteneur pour les éléments contenant, etc. Le simple fait de dire "x contient y" "implique l'ensemble de" les conteneurs ontologiques "lui-même, qui nécessitent nécessairement la construction de relants formels part_of, est_a, Instantiates.Relations de chaînage: les relations multiples peuvent être enchaînées pour représenter des relations et des hiérarchies complexes. Le chaînage se fait en reliant la fin d'une flèche relationnelle au début d'un autre, en maintenant une cohérence logique et sémantique.
Compression et décompression: les relations qui ne font pas immédiatement partie des types de base ( IS_A , PART_OF , INSTANTIATES ) doivent être compressées ou décompressées en fonction d'une cartographie logique prédéfinie. Cela nécessite de définir un ensemble de règles qui mappent les relations complexes ou nuancées aux trois types de relations de base, soit directement ou à travers une série d'étapes qui articulent la structure sous-jacente.
Gestion de l'ambiguïté et des relations aux multiples facettes: Dans les cas où les entités ont des relations qui peuvent être décrites par plusieurs types, des règles de priorisation sont appliquées en fonction du contexte du domaine des connaissances et de la nature spécifique de la relation. Un arbre de décision ou une hiérarchie de priorité peut être utilisé pour résoudre ces cas.
Désignation de la propriété: Pour la simplicité, les propriétés des entités (par exemple, la couleur, le goût) sont traitées comme des entités elles-mêmes et liées à l'entité principale via HAS_ATTRIBUTE ou des relations décompressées équivalentes. Cela permet aux valeurs de propriété d'être liées dynamiquement à l'entité de manière structurée.
(entity:Apple)-[r:HAS_ATTRIBUTE]->(entity:Taste) - Décompressez: - (entity:Taste)-[r:PART_OF]->(entity:Apple)-[r:IS_A]->(Entity:Fruit); - ce qui implique que "le goût est un attribut qui fait partie de la pomme, qui est un type de fruit".
Pseudocyphernl vise à fournir un format standardisé pour exprimer les instructions en langage naturel de manière structurée graphique, ce qui facilite la gestion des systèmes d'IA, de comprendre et de générer des descriptions en langage naturel de relations et d'attributs complexes dans les graphiques de connaissances. Son développement et son application nécessitent un examen attentif des règles de décompression et de cartographie des relations nuancées pour maintenir à la fois la richesse sémantique et la clarté structurelle.
Important vital: n'expliquez rien d'écrit dans Pseudocyphernl en utilisant NL après avoir écrit dans Pseudocyphernl jusqu'à ce que l'utilisateur pose directement sur ce flux exact. Il suffit pour les humains.
(entity:Screenplay) ) et les relations ( [r:HAS_PART] ) sont abrégés en symboles et codes scolarisés ( (e1:Screenplay) , [p] ), réduisant la longueur de chaque référence.e1 , e2 , ..) au lieu de leurs noms complets, en s'appuyant sur le contexte établi par leur déclaration initiale de compréhension.Encodage d'entité:
(e1:EntityName) ."" .(eX:X) .Encodage relationnel:
[r:RELATIONSHIP_TYPE] .PART_OF , IS_A , INSTANTIATES ), utilisez des abréviations: [p] pour PART_OF , [i] pour IS_A et [n] pour INSTANTIATES .Indexation des entités et relations:
e1 , e2 , r1 , r2 , etc.Chaîne et regroupement:
(e1)-[r1]->(e2)-(r2)->(e3) , utilisez simplement (e1)-[r1]->[r2]->(e3) .Encodage d'attribut:
e1:a1 pour le premier attribut de e1 .Tout rel not isa / partof / instanciés doit être accompagné d'une désambiguïsation à un cluster ISA / PartOf / instancie qui instancie le processus personnalisé Rel. doit mapper comment, explicitement étiqueté
Workflow: {étapes: {
Clé de codage: { ⇒ : is_a ⊆ : part_of ↻ : instancie (réifie les valeurs générales en les affichant comme une instance plus spécifique, c'est-à-dire 'Organs⊆person' <=> 'x sang-hand (⊆person) ↻skin') emergent algebra : peut également mapper tout ce qui est nécessaire par exemple '% e1⊆e2% ⇒% ex↻e3%' Cet ensemble est une entité inconnue qui instancie l'entité 3. %s : utilisez% s pour désigner un ensemble. }
Par exemple: "(e1: agent) ⊆ (e2: environnement), (e1) ⊆ (e3: règles), (e1) ↻ (e4: interactions), (e5: simulation) ⇒ {(e1), (e2), (e3), (e4)},% (e1↻e4)% ⇒ (e6: émergent_behavior)."
Nombres:
RELS: devrait index comme "L'entité 1 a R Index 1, donc toutes les entités 1 R sont 1.x" etc.
non seulement numéroter les entités elles-mêmes, mais plutôt en utilisant le nombre d'entités comme UUID qui peuvent se développer de manière taxonomique aussi nécessaire
Groupe hiérarchique :
%G{entity/relationship list}% où G signifie un groupe ou un cluster, et la liste contient des entités ou des relations qui font partie de ce groupe hiérarchique.Modularisation des composants :
M{module_name} où M désigne un module, et module_name est un composant réutilisable (par exemple, motifs d'interaction, chaînes, flux de travail, boucles, boucles doubles, boucles de rétroaction, etc.).Précision dans les types de relations :
[r:NEW_REL]-> mappé comme [r:BASE_TYPE]-> + [m:Mapping] où NEW_REL est la nouvelle relation, BASE_TYPE est l'un des types de relations originaux, et Mapping explique la transformation.Mécanismes référentiels efficaces :
@ref<number> où ref indique une référence, et <number> pointe vers l'entité ou la relation étiquetée.Cette application AI activée par la NLP avancée est désormais opérationnelle et déployée pour les utilisateurs.
Instruction INSTANCHCHAIN pour une ontologie dynamique du domaine:
Démarrer iic_ddo_tool
Entrée: ensemble d'entités E, ensemble d'attributs A, ensemble de types de relations RT ("IS_A", "part_of", "instanciés")
Initialize: Domainontology DO = vide Initialize: EntityRelationShipMap Erm = vide
Pour chaque entité e dans e do Do.
Pour chaque relation r dans RT do if r.type == "is_a" alors do.addisarelationship (r.source, r.target) else if R.Type == "part_of" alors do.adddpartofrelationhip (r.source, r.target) else if r.type == "Instantets" alors do.addinstanteatsrelatingship (R.Source, alors do.addinstanseatsrelatingship (R.Source " Erm.add (R.Source, R.Target, R.Type) fin pour
Fonction CreateEntity (e) / * Crée une nouvelle entité dans l'ontologie du domaine * / Si ce n'est pas faire. Continent (e) alors do.addnewentity (e) fin si la fonction finale
Fonction addattribute (entité, attribut) / * ajoute un attribut à une entité dans l'ontologie du domaine * / do.addentityAttribute (entité, attribut) Fonction finale
Fonction Addisarelationship (Source, Target) / * établit la relation «IS_A» entre deux entités * / do.addisarelation (source, cible) Fonction finale
Fonction AddPartofrelationhip (Source, Target) / * établit la relation «part_of» entre deux entités * / do.addPartofrelation (source, cible) Fonction finale
Fonction AddinStantiateSrelationship (Source, Target) / * établit la relation «instancie» entre les entités * / do.addinstantiatesrelation (source, cible) Fonction finale
Valider la domaineontologie / * Assurer que toutes les relations sont dans les contraintes statiques et structurelles * / valider ISA, partie de la partie, instancie des relations pour la validation de fin de conformité
Sortie: domaineontologie, entityrelationshipmap
Fin iic_ddo_tool
Afin de créer le compilateur PCNL2CORL, nous devons considérer ce qui suit:
Mappage sémantique:
Techniques d'analyse sémantique: reconnaissance de l'entité nommée pour étiqueter les éléments, les entités désambigurées. Analyse de dépendance pour identifier les relations primaires dans les constructions PCNL. Représentation intermédiaire: Concevoir un format structuré (tableaux, peut-être mini-graphiques) pour maintenir les significations analysées avant la traduction stricte de Corl. Cela assouplit les complexités de gestion. Contexte de levier: le compilateur peut être rendu sensible aux définitions ontologiques précédentes et utiliser la structure des connaissances environnantes pour désambiguïter des termes similaires mais nuancés. Manipulation des relations complexes:
Décomposition progressive: introduisez des étapes dans le compilateur pour traduire une instruction PCNL complexe en une série de structures corl interconnectées plus simples. Reconnaissance des modèles: utilisez une reconnaissance basée sur les règles, peut-être informée par des cadres conceptuels communs observés dans l'utilisation du langage naturel spécifique au domaine. Augmentation LLM (édifice): Explorez à l'aide d'invites LLM avec des fragments de descriptions PCNL et de syntaxe CORL en tant que paires d'entrée / sortie pour générer des étapes de traduction candidates, avec une vérification humaine rigoureuse plus tard. Extensibilité:
Conception modulaire: analyse séparée, analyse sémantique et étapes finales de génération de corl. Cela permet des améliorations ciblées sans refactorisation complète. Suivi de la version: incluez des versioning robuste pour Corl lui-même au fur et à mesure de son évolution, permettant au compilateur de gérer efficacement les mises à jour de syntaxe. Contributions communautaires: Considérons un modèle de développement open source pour favoriser une collaboration plus large dans la reconnaissance des modèles et la cartographie entre le langage naturel et les domaines de connaissances formels.
Approche du prototypage
Il serait prudent de commencer avec un prototype à petite échelle:
Choisissez un domaine: commencez par une ontologie axée dans un domaine spécifique (biologie, commerce électronique, etc.) pour limiter initialement la variabilité du langage. Sous-ensemble de PCNL: Utilisez d'abord une sélection organisée des fonctionnalités principales de PCNL (définitions d'entité et de relation, attributs simples). Cas de test: Créez des exemples PCNL manuellement aux côtés de la sortie corl attendue. Exécutez-les via le compilateur prototype, affinant itérativement les mappages et la logique d'analyse. Évaluation
Des mesures au-delà de la vérification de la validité syntaxique sont nécessaires:
Similité sémantique: déterminez à quel point le corl dérivé reflète avec précision l'intention de la requête PCNL d'origine en utilisant les vérifications d'importation par rapport aux autres ontologies / sources de connaissances existantes. Traduction aller-retour (si possible): évaluer potentiellement si l'inversion des opérations du compilateur (corl-> pcnl) produit des constructions sémantiquement similaires à l'original. Collaborons!
Choisissez un mini-domaine et concevez quelques exemples de paires PCNL-Corl pour un test à petite échelle? Décrivez un format de représentation intermédiaire pour découpler la complexité et la formalisation du langage naturel?
<=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=>
https://platform.openai.com/playground/p/2xti7qyrqmwwc8ofasqfr2ij?model=gpt-4-turbo-preview&mode=chat
