Dans le cadre du Data Food Consortium je développe un connecteur pour faciliter l’implémentation du standard DFC par les plateformes. Ce connecteur est une bibliothèque qui propose un modèle objet pour encapsuler des données dans les concepts issues de l’ontologie.
Pour aller plus loin, j’ai développé une autre bibliothèque que j’ai appelé « semantizer » qui permet d’exporter et d’importer ces données conceptualisées vers ou à partir du JSON-LD notamment.
Cette bibliothèque étant générique elle dépasse le cadre du DFC et aurait plus d’intérêt à être véhiculée par l’AV…
Ma question est donc la suivante : est-ce OK pour vous pour que je publie cette bibliothèque sur le Github de l’AV ? Sous une licence libre et/ou open source bien sûr.
Curieux de voir ce que fait cette bibliothèque… Peut-être que cet article sur l’utilisation du JSON-LD Framing pour produire des structures JSON propres est lié à la question ? Clean JSON(-LD) from RDF using Framing - Sparna Blog
Merci pour vos réponses. Quelqu’un pourrait-il m’ajouter à l’organisation sur GitHub afin que je puisse créer un dépôt svp ? Peut-être @guillaume.rouyer@srosset@simon.louvet.zen ?
J’aimerais faire une release sur npm, ça pourrait être pas mal d’avoir un namespace pour l’assemblée virtuelle non ? Par exemple @virtual-assembly ? @simon.louvet.zen Tu n’avais pas voulu de namespace pour ldp-navigator ? Vous avez fait un namespace pour @semapps. Y a t-il un avis à l’AV sur cette question ? @srosset
Les namespace servent à regrouper des packages qui appartiennent au même logiciel, comme on le fait pour SemApps. Mais ils ne sont pas vraiment fait pour identifier une organisation. Donc pour moi ça n’aurait pas de sens de créer un namespace pour l’AV.
D’après ce que je comprends de la doc, les namespace servent bien à identifier une organisation :
When you sign up for an npm user account or create an organization, you are granted a scope that matches your user or organization name. You can use this scope as a namespace for related packages.
Ils permettent aussi d’avoir un même nom de paquet publié par différent·es organisations ou projets.
Ah OK. Et bien je dirais que c’est pas une pratique courante. Si je regarde les packages « scopés » que j’ai dans un de mes dossiers node_modules, ce sont plutôt des noms de projets: @moleculer, @comunica, @rdfjs, @lerna, @jest… (Jest c’est un projet de Facebook, mais ils utilisent pas le scope @facebook)
Perso j’ai créé un scope pour @activitypods aussi.
Pas d’objection non plus à créer un scope @virtual-assembly mais je ne compte pas utiliser ce scope pour les packages que je publie hors SemApps, car je vois pas ce que ça apporte.
Dans le cas d’un paquet unique ou d’une bibliothèque formant un seul paquet, le scope d’organisation permet à d’autres organisations de publier un paquet portant le même nom. Par exemple, un paquet http pourrait être publié par différents framework web : @framework1/http et @framework2/http. Cela me parait une bonne pratique pour laisser de la place aux autres.
A scope allows you to create a package with the same name as a package created by another user or organization without conflict.
Dans le cas de projets entiers comme semapps, un scope dédié semble tout à fait adapté.
Idéalement je suppose que les projets devraient même être scopés par organisation ce qui permettrait à 2 organisations différentes de publier un projet qui porte le même nom.