Knowledge Representation Markup Language (KRML), directement inspiré du post de blog sur Semantic Markdown : GitHub - edwardanderson/krml: Create knowledge graphs with Markdown
4 « J'aime »
OMG ! Mais c’est énorme ça 
Merci pour ce partage @thomas.francart
1 « J'aime »
Super @thomas.francart ! Et qu’en penses-tu ?
Est-ce qu’il est conforme à ce que tu envisageais ? Est-ce qu’il est mature ? Est-ce qu’on pourrait l’implémenter ?
1 « J'aime »
Pour développer mon ssg maison, j’ai eu envie récemment de concevoir un hybride entre hashtag et thésaurus, avec une inspiration web-sémantique mais orienté pour en faciliter l’adoption par des amateurs, façon Markdown.
J’en ai parlé tout à l’heure à @srosset qui me suggère de venir voir semantic markdown.
Me voici donc.
Je crois que j’étais tombé dessus dans ma recherche d’existant, mais sans y prêter attention (je trouvais la syntaxe encore trop verbeuse et indigeste pour le public que je vise, et je n’avais pas identifié qu’il y avait du monde de l’assemblée virtuelle derrière).
J’en suis aux premiers pas, mais vos avis m’intéressent.
Pour l’instant, j’en suis là :
PS : dites moi s’il vaut mieux que j’ouvre un autre fil de discussion pour la suite du message (ou faite le si vous avez les droits nécessaire sur le forum)
Tagaurus | EN: Semantic tags made simple | FR: De simples tags, devenus sémantiques.
EN: Tagaurus is a human-first DSL that extends plain Markdown hashtags into RDF/SKOS-compatible controlled vocabularies — so intuitive, your granny could grow a multilingual thesaurus just by writing in her favorite PKM or by tagging her blog posts, turning them into a knowledge graph without eever needing to know—or care—what’s underneath: DSLs, RDF, SKOS, PKMs… none of it matters.
FR: Tagaurus est un DSL trivialement lisible qui étend les hashtags Markdown en vocabulaires contrôlés compatibles RDF/SKOS — assez intuitif pour que votre grand-mère fasse émerger un thésaurus multilingue rien qu’en écrivant dans son PKM préféré ou en taguant ses billets de blog, transformant le tout en graphe de connaissances… sans le savoir ni devoir comprendre du jargon ou des concepts obscurs tels que : DSL, RDF, SKOS, PKM… rien de tout cela n’a d’importance pour utiliser Tagaurus.
Pour 1ssg, je souhaite un moteur de gestion des tags intelligent : qui gère les synonymes et les héritages de mots clefs, extensible au fur et à mesure. Inspiration du concepte hashtag combiné/enrichie par celui de Thésaurus lexicographique ou documentaire et de taxonomie hiérarchique. Je met aussi les terme d’ontologie, de traitement automatisé du langage et de traduction ou multilangue, car il en est aussi question.
Syntaxe de construction/définition/association :
- les tags peuvent contenir tout caractères utf8 imprimable à l’exception des caractères suivants : *~#=><,;!?(){}/"`@$|& (dont le caractère « espace ») et ne peuvent pas commencer ni finir par les caractères spéciaux risquant de créer un conflit d’interprétation, notament : _
- les tags ne sont pas sensible à la casse MDPH=mdph
- l’usage des caractères - et ’ sont possible à l’interieur des tag mais sont déconseillés. Ils seront normalisé en interne pour les interpréter comme des _
- les tags sont sensible aux accents, un warning est émis quand il sont utilisés pour suggérer d’expliciter la synonymie avec la version non accentuée.
- il est possible d’expliciter une synonymie entre tag en mettant un = entre eux : tuto=guide=tutoriel
- il est possible d’expliciter une pondération quand la synonymie est partielle. Quand le moteur de construction du glossaire rencontre un conflit de pondération il lève un warning et fait la moyenne des pondérations trouvées entre 2 termes.
Syntaxe de proximité sémantique : frère=0.9=soeur frère=0.8=fratrie
Sans expliciter : soeur=0.8=fratrie la proximité entre soeur et fratrie serait extrapolée aux environ de 0.7.
Le motif de parsing des proximité sémantique est :/=(\-?0?\.?[0-9]+)=/
Si la pondération est strictement comprise en 0 et 1, elle est utilisée telle-quelle.
Si elle est superieur à 1, elle se vois préfixé automatiquement par0.pour revenir dans le cas précédent.
Si elle est égale à 1, elle est interprété comme0.1ET un warning est émis suggérant d’expliciter soit un simple = pour une proximité totale ou synonymie, soit.1ou0.1pour lever l’ambiguité.
Si elle est égale à 0, les deux tags sont inclus, mais aucune proximité entre eux n’est retenue. Un warning est levé pour indiquer que la pondération 0 n’a pas de sens/intérêt et que c’est probablement une erreur à corriger.
Si elle est négative, elle est traité comme les pondérations positive mais en négatif, donc pour accentuer une antonymie : girafe=-0.9=chacal pour expliciter (contexte CNV) que ces termes sont essentiellement des antonyme. - Il est possible d’expliciter l’antonymie stricte entre deux tags comme suit : grand!=petit
- Si un lien entre tag est explicité dans une page mais que dans cette page seul un des termes du lien est pertinant, cela peut être signifié comme suit : horsContext!=pertinantIci
Il n’est pas nécessaire d’utiliser à la fois :- tag pour signifier que ce tag est là pour expliciter le lien mais n’est pas à associer à la page
- tag pour signifier que parmi les associations faites avec ce tag, seul celui ou ceux entre * sont pertinant à considérer dans la page actuelle.
- les warning levés par les tags d’une page doivent être différentiable de ceux issu d’une autre page, afin de pouvoir être affiché dans une section debug spécifique en préambule sur la page concernée dans le contexte « pré-prod » ou « dev » bref, quand le site est construit pour une cible différente que prod/production/public/publish
- Il est possible d’expliciter des proximités hierarchique tel que :
vivant>animal>mamifère>girafe
CNV>(girafe,chacal) - Comme pour les liens horizontaux de synonyme, il est possible d’affecter une pondération dans une association hiérarchique : etre_vivant>.2>girafe, CNV>0.9>girafe
- animal>>girafe explicite que le tag girafe est utilisé avec le sens animal, à l’exclusion des autres héritages sémantique possible. Sans cette explicitation, les autres sens/homonyme sont considéré comme également pertinants
- Il est possible expliciter des homonymes avec le caractère ~ comme suit : CNV>>girafe~animal>>girafe couleur>>vert~récipient>>verre~orientation>>vers
- Il est possible d’expliciter la langue d’un terme en le préfixant du code ISO 639-1 suivi de
:et sa traduction avec la syntaxe de synonyme.
Exemple : soin=9=en:care=8=prévention
Chaque instance utilisant ce système de tag intelligent doit considéré une langue par défaut qui s’applique à tout les tag n’étant pas préfixé.
Si un même tag est utilisé préfixé d’une langue autre que la langue par défaut et sans préfix, un warning est levé signalant l’incohérence et invitant à expliciter la langue pour chaque usage du tag.
Exemple : fr:char et en:char sont homonyme mais pas synonyme comme l’illustre les hierarchie sémantique suivante : véhicule>fr:char~data_type>en:char
Le comportement par défaut si un même tag est utilisé avec et sans préfix de langue est paramétrable de manière global. A défaut tag=0.1=en:tag - Si un tag a le même soundex qu’un autre, le système doit lever un warning de suspission d’erreur orthographique, à moins qu’une explicitation du lien entre les deux n’ai été définie.
Exemple : sain et sein devrait lever un warning s’ils sont tout deux utilisés tant que leur lien n’est pas explicité comme ceci par exemple : sain!=sein
Le comportement par défaut entre deux termes au même soundex dont le lien n’est pas explicité est paramétrable de manière global. A défaut tagSoundLike=0.1=otherPhoneticSimilarTag - Dans un champs dédié aux tags, le # initial est innutile et chaque tag et séparé par un espace et/ou virgule ou point virgule. (en front-matter par exemple)
Dans le corp d’un message, la présence d’un # sans espace à sa suite déclenche l’interprétation en tant que tag avec toutes les syntaxes de construction/définition utilisable, y compris les séparateur pour énumérer des tags tel que , ou ; seul les caractères blancs (espace, tabulation, retour à la ligne) ou caractères interdits (@&` notament) interompent l’interprétation du moteur de tag. Cependant, si le corp d’un message utilise un langage enrichie type markdown, l’interprétation markdown doit primer (pour qu’un lien pointant vers une ancre ne soit pas interprétée comme un tag.
Exemple : # titre avec #tag et lien avec #tag - entre synonymes, si une version préféré doit être déterminée, les critères à prendre en comptes sont :
- la langue du tag (la langue par défaut prime)
priority = tag_lang===default_lang?[3]:1 - la fréquence d’utilisation du tag par rapport à ses synonmyes (le plus fréquent prime)
priority*= this_tag_usage_count/all_synonym_tags_usage_count - la concision du tag (le plus court prime)
priority*= [3]/([3]+tag_length) - le risque de confusion avec les autres tags (le tag ayant la distance lexicale la plus élevée (ou la similarité la plus faible) avec tout tag non synonyme prime)
priority*=[1]/([1]+nearest_non_synonym_tag_similarity_score)
Les constantes entre crochet peuvent être personnalisé dans la configuration d’une instance, de même que l’algorithme de similtude, entre les version de Jaro-Winkler, de Levenshtein et de Hamming
- la langue du tag (la langue par défaut prime)
- Il est possible d’associer une description à un tag en la plaçant entre guillemets.
Exemple : girafe"Mamifère au long cou et au pellage tacheté blanc et orange".
Si plusieurs description sont associé à un même tag, un warning est levé pour signaler le doublon, à moins que les tag soient contextualisé différement.
Exemple : animal>>girafe"mamifère au long cou"~CNV>>girafe"référence symbolique à l’animal du même nom pour illustrer les postures d’écoute et d’expression empathique" ne déclenchera pas de warning.
Interprétation syntaxique lors de filtrage ou recherche par tags
- de la logique booléenne peut être utilisé pour combiner des tags entre eux.
Exemplevoile&(lac|mer|océan)-religion
Un tag précédé de - est équivalent à le précéder de &! mais la syntaxe - est commune dans les moteurs de recherche - la séparation de tags par des espaces est interprété ni comme & ni comme | mais comme une pondération élevé si & tout en tolérant du | avec une pondération de pertinance faible.
- un seuil de pertinance minimal est défini par défaut et peut être surchargé comme les autres paramètres réglables avec la syntaxe : {accuracy_min:0.5,result_min:3,result_max:10} java sport
Dans ce cas, tant qu’il existe des résultats ayant une pertinance superieur à 0.5 et pour un maximum de 10 résultats, retourne les résultat par ordre décroissant de pertinance.
Si accuracy_min n’avait pas été précisé, le système aurait retourné au moins 3 résultats, même avec une pertinance plus faible que accuracy_min par défaut, mais pas plus de 3 si leur pertinance est inferieur au seuil par défaut. - L’utilisation de en:tag ou cnv>>girafe permet de sélectionner un sens spécifique au tag à l’exclusion des autres.
- La navigation dans le graphe sémantique pour obtenir des correspondances approximative est possible avec une aténuation de pertinence à chaque saut. L’attenuation pouvant être variable selon la direction hierarchique du saut. Une pénalité de pertinance est aussi configurable pour les synonymes défini comme stricte, et elle emplifiera la pénalité des synonymie partielles.
- Plus un tag utilisé en recherche/filtrage est rarement présent/utilisé dans les contenus indexé, plus il bénéficiera d’un poid de pertinance important. Par exemple, si sur un blog, il y a de nombreux articles sur la santé mentale (associé au tag psy) mais un seul qui parle de succide et qu’une proximité sémantique est établie entre succide et mort, alors la recherche « mort|psy », même sans que le tag mort soit utilisé dans l’article sur le succide, donnera l’article sur le succide en haut de classement, le tag mort/succide étant très spécifique sur ce blog, là ou le tag psy est bien moins spécifique. Algoritme de référence : TF-IDF
- L’indexation fullText peut être utilisé en complément de résultat si le seuil {result_min} n’est pas atteint à partir des tag explicités comme tel. Dans ce cas, un malus de pertinance est appliqué.
L’indexation fullText doit être activable ou non en fonction du volume des contenus à indexer, surtout pour les cas d’usage de recherche/filtrage client-side
Ressources, références, inspirations
- [SKOS]
- [RDF]
- [JSON-LD]
- [Markdown]
- [FlexSearch]
2 « J'aime »
Peux-tu fournir un exemple de fichier complet illustrant les features ?
Sinon c’est difficilement compréhensible.
Le mieux serait d’ouvrir un dépôt Git pour y écrire la spécification et la faire évoluer en recevant les retours sur le gestionnaire de tickets dédié.
Ca vaudrait sans doute le coup d’encoder ce que tu voudrais avec KRML (krml/docs/specification.md at main · edwardanderson/krml · GitHub) avant de déterminer ce qui ne te plait pas dans KRML et ce que tu voudrais.
2 « J'aime »
Hello @1000i100 ,
Ravi de te voir ici, si tu veux, on peut aussi se faire une visio à plusieurs pour discuter de ce projet, car ça m’intéresse aussi et il est vrai que ce que tu as posté ne m’aide pas à me mettre à la place d’une grand mère
En fonction de la visio, on verra si on créer un autre sujet, voir, on peut te donner les droits pour le faire.
Proposes des dates,
Je t’envoie un sms en parallèle.
Yannick
@thhck a récemment proposé un sujet « LD markdown » comme « work item » du Solid Community Group (CG):
La démo:
Décidément il semble que ce soit un sujet qui intéresse les français 
1 « J'aime »
Encore une initiative autour de l’authoring de linked data en Markdown ! https://mdld.js.org/
Les règles de syntaxe ne sont pas immédiatement hyper claires pour moi, mais l’idée est là !
Le truc est bidirectionnel, en modifiant les triplets ca met à jour le markdown, ce qui est assez cool.
2 « J'aime »
Ooh ca a l’air super @thomas.francart mdld ! Est-ce que t’es entré en contact avec les auteurs ? N’y aurait-il pas un enjeu à réunir les différentes initiatives dans un lieu légitime pour monter un groupe de travail et une initiative de standardisation ?
Oui j’ai eu un échange de mail avec l’auteur (davay42 (davay) · GitHub). Tout à fait dans l’esprit de l’AV (« I will notify you if I get any traction with it. I don’t want big corporations to lock it in proprietary environments though - hence my dual licensing on the project. »)
Je ne sais pas trop ce qu’impliquerait une « initiative de standardisation » - il faudrait se baser sur CommonMark je pense (https://commonmark.org/)
2 « J'aime »
Je trouve ça un peu dingue tout de même que le W3C ne se soit pas occupé de standardiser Markdown non ?
Au sujet de Semantic Markdown, il faudrait demander un avis auprès de Pierre Antoine Champin peut-être ?