Rename project?

[rubensworks]

To avoid confusion with the original YASGUI project from Triply, we may consider renaming this project.
This issue is a starting point for discussion around the pros and cons, and which names could be relevant.

[ktk]

I'm pro name change, mainly because there is a lot of stuff with Yasgui in the name we don't control:

• https://yasgui.org/
• https://yasgui.triply.cc/
• https://github.com/TriplyDB/Yasgui
• https://www.npmjs.com/package/yasgui
• https://docs.triply.cc/yasgui/

It does not look like Triply is really interested in it anymore, see for example TriplyDB/Yasgui#246

If we keep the name, this will diverge more and more.

[rubensworks]

If we want to stay in the spirit of YASGUIO, some ideas of other names:

• AMSGUI (A Modern SPARQL GUI) or (A Modular SPARQL GUI)
• ABSGUI (A Better SPARQL GUI)
• EASGUI (Even Another SPARQL GUI)

[vemonet]

Imo Yasgui was good because "Yet Another" was a popular pattern, and you could prononce it as a word, so it was easy to remember.
@rubensworks I feel like your suggestions are a bit hard to remember, I like better EASGUI, but a consonant at the start would probably be easier to pronounce and remember (e.g. BASGUI: Better Another SPARQL GUI, we dont really mind if the meaning of the acronym is a bit funny)

Advantage of keeping this pattern is that we can keep the naming convention of down stream packages: BASQE, BASR

Otherwise we could go with a clearer naming, e.g. sparql-ui (new SparqlUi()) with sparql-editor / sparql-results? This helps with SEO when people search for a SPARQL editor

[rubensworks]

BASGUI has a nice ring to it, I can live with that :-)

Otherwise we could go with a clearer naming, e.g. sparql-ui (new SparqlUi()) with sparql-editor / sparql-results? This helps with SEO when people search for a SPARQL editor

I'm also open to that. The only downside is that sparql-editor seems to be claimed on npm already.

[vemonet]

Yes by me, for a package that wraps yasgui, but it is prefixed (@sib-swiss/sparql-editor), this one would be @rdfjs/sparql-editor

[rubensworks]

Any other thoughts on the suggested new names? @ktk @tpluscode @ludovicm67 @ajuvercr

[ludovicm67]

@rdfjs/sparql-editor is quite explicit, so I like this :)

[vemonet]

Potential names options (I have added some variants):

• 😄 @rdfjs/sparql-editor
  • @rdfjs/sparql-editor-input | @rdfjs/sparql-results
  • Explicit, easier to find when searching it, but naming the editor input textbox vs the full app is difficult
• 🎉 @rdfjs/sparql-playground
  • @rdfjs/sparql-editor | @rdfjs/sparql-results
  • Explicit, now the main name is "playground"
• 👎 @rdfjs/sparql-studio
  • @rdfjs/sparql-editor | @rdfjs/sparql-results
  • Explicit and very findable, "studio" connotes a polished composed tool, and frees -editor to mean only the query-input component
• 👀 @rdfjs/sparql-ui
  • @rdfjs/sparql-editor | @rdfjs/sparql-results
  • Explicit, -ui cleanly marks the composed layer over the editor/results parts, maximally discoverable
• 👍 @rdfjs/amsgui (or @rdfjs/absgui)
  • @rdfjs/amsqe | @rdfjs/amsr
  • A Modern SPARQL GUI (or A Modular SPARQL GUI) | A Better SPARQL GUI
  • More positive, "modular" nicely signals the editor/results split, but hard to pronounce
• ❤️ @rdfjs/easgui
  • @rdfjs/easqe | @rdfjs/easr
  • Even Another SPARQL GUI
  • Most faithful to the YASGUI "yet another"
• 🚀 @rdfjs/sasgui (or @rdfjs/basgui)
  • @rdfjs/sasqe | @rdfjs/sasr
  • Super... Another SPARQL GUI (change punctuation to your liking) | Better Another SPARQL GUI
  • Alternative to YASGUI, I like that it starts with a s like SPARQL
• 😕 @rdfjs/jasgui
  • @rdfjs/jasqe | @rdfjs/jasr
  • Just Another SPARQL GUI
  • Pronounce like YASGUI if said in spanish

Maybe we can start some vote using emojis to see which one are more popular? Feel free to suggest more

@rubensworks @ludovicm67 @ktk

[rubensworks]

For reference, once this rename is done, we should also make sure to update the package.json with the new repo name and author.

[ktk]

Sounds good to me, I like decisions ;)

[vemonet]

I think changing name makes sense, especially if we go with a completely new editor, e.g. Monaco/CM6 + LSP support (completely different API). It will prevent confusion with other actively maintained package like @matdata/yasgui which are closer to the original Yasgui API

Note we don't want to hide the Yasgui legacy, there is a small ecosystem of Yasr results plugins, that we want to keep compatibility with (e.g. GeoSPARQL map or construct graph visualizations). And it should be clear to devs that they can use Yasr plugins with the new named package (@rdfjs/sparql-results)

In that regard I think it is better to keep incrementing on the current version number, it makes it clearer how much we diverged, and keep all commit/release history. In the end we will not completely rewrite it. Mostly Yasqe (Yasgui tabs/endpoint, Yasr and utils will not change much)

Changing name will require all consumers to make a change in their package.json, imo until there are no substantial changes made to the API we should not change it