please avoid too generic name for executable

[jonassmedegaard]

Hi,

Thanks for this quite interesting project!

I am looking into packaging it officially for Debian, and have run into an issue with your choice of naming the binary executable: With your deb package, you provide the executable named as sx, which clashes with another binary in Debian (part of the package lrzsz). The maybe obvious name shapes is taken as well (part of the package gerris).

For now, I will use the binary name shapes-sx rdfshapes for my draft packaging work. I hope you will agree to rename the binary as well, so that we will not end up with different names.

One way to check for existing names in Debian is by installing apt-files, run sudo apt-file update once (or do a regular apt update which it hooks into, and then run e.g. apt-file search bin/sx

[jonassmedegaard]

Hmm, I am changing my mind: I will use the name rdfshapes for now.

[labra]

Thanks for your interest in packaging it in Debian. It is a pity that sxis already taken because I would prefer a short name.

Some possibilities, in order of preference for me, could be:

• shx: I like because if is the shortest one and I think is not taken
• rdfsx: this one is quite short and also reminds that the tool is about RDF, so I like this one also.
• rdfshape: I also like this one because it is a reminder of a sister project that I also maintain: https://rdfshape.weso.es/ and in the future I am planning to move most of the code under the web project to depend on the Rust code. However, I hesitate because people could mistake one for the other.
• rdfshapes: I like it, although I am not sure about the extra (s) at the end

[labra]

By the way...once we decide the new name, are you going to do a PR or do you prefer me to change it in Cargo.toml ?

[jonassmedegaard]

Personally, I lean towards shortest-while-descriptive names. That also reduces the risk of the inverse problem of some flying toaster screensaver project getting introduced next month, choosing to use same nonsense-ultrashort name as we now decide on. I therefore vote for rdfshape. But perhaps I am missing some fun word play with "sx", that I then suggest that you add prominently to the README.md. I was guessing it is an abbreviation of ShEx, and has less connotations for users of your project more interested in SHACL and DCTAP.

As for doing the change, it is by far the easiest that you simply do it: I am into copyleft (ie. GPL licensing instead of the more permissive MIT and Apache-2.0 licenses) and while I have used git since 2009, I've never done a Github PR due to scepticism towards clauses in their Terms of Service.

[jonassmedegaard]

if this project is also sensible to reuse as Cargo crates, you might consider renaming the crates as well - and then for consistency the repository itself. When providing both library crates and an executable (and perhaps a daemon too in the future), I find it more sensible that the stem of the repo name is same as for all public lib and bin crates.

[labra]

Indeed, now I recall that one of the reasons for not using rdfshape was that it was already taken as a repository name by us with the rdfshape repo.

Initially, the project started to implement ShEx in Rust, but we later extended the scope to implement SHACL and now for example I am implementing DCTap with the idea to continue expanding the scope to RDF related tools.

At this moment, some of my future plans are the following:

• Support for ShEx schemas and SHACL shapes graphs...both for checking and validating RDF data with them
• Support for RDF data...in different flavors, for example, RDF data in Turtle files, but also RDF data behind SPARQL endpoints
• Support for Wikidata and Wikibase knowledge graphs. Implementing WShEx in the future and the code that can generate Wikidata subsets from WShEx schemas. The wdsub tool.
• Support for DCTap and other RDF data modeling languages like LinkML or rdf-config
• Support for generating visualizations and/or HTML views of RDF Data models created in ShEx, SHACL, DCTap, etc.
• Support for conversions between some of those languages...for example, convert between different RDF formats (Turtle, N-Triples, RDF/XML, etc.) and between RDF shapes formats (ShExC, ShExJ, ...) and languages (ShEx to SHACL, SHACL to ShEx, DCTap to ShEx, etc....)

So the idea of sx was that the s could be seen as a schema or shape and the x as something generic that could be seen as a symbol for cross-conversion or something like that...maybe that's why shx could also make sense where sh reminds of shapes, and x continues with this idea of conversion...or maybe rdfsx would also make sense?

[jonassmedegaard]

Yes, rdfsx makes great sense to me, then.

Please consider adding a section/paragraph to README.md explaining the meaning of the name.

[jonassmedegaard]

I will use rdfsx as both source and binary package name, and name of executable binary. Unless you suggest otherwise.