add initial structure of README

[VladimirAlexiev]

@amivanoff could you please take a first stab at it? Make the structure as per awesomelists (https://github.com/w3c/shacl/issues/78#issuecomment-2309745899) and add sections as per my above comment and the "updated list".

[amivanoff]

Ok, on it

[amivanoff]

After some initial screening of Updated list of implementations I may conclude, it needs to decide upfront (and document in CONTRIBUTING.md maybe) on software inclusion/exclusion criteria:

1 What to do with "abandonware" (5-6 years old from the last update, or more)?

2 What to do with "unusable prototypes"? A "technology readiness level" aspect, like TRL from NASA. Especially in section "Shape Editors, Visualizations". Something like "is cool-looking but unusable -- awesome, or not"; “is novice, but not cool-looking and not usable -- awesome, or not”.

Because there are too much of it in SemWeb area and both cases exist even in "Updated list of implementations". And parallel copy-paste from several lists by several people, even with deduplication, could quickly lead to a mess.

Do we need a criterion “I propose it to the “awesome” because I use it” or not? Or maybe even "many people use it" or "it is suitable for mass usage"?

3 Are we including open-source only or closed-source too? If so, it seems, we need OSS/$$$ mark on every software entry.

4 Should we sort software in categories by its name or by popularity?

[amivanoff]

I also could commit settings for VS Code with "Markdown All in One" and spellchecker with recommend extensions, initial dictionary and so on, if we agree on common IDE.

[tpluscode]

1 What to do with "abandonware" (5-6 years old from the last update, or more)?

Fine if it is known to work. But we could add some marker for software which hasn't received updates in a long time. Like "☠️☠️☠️", or something less loaded

2 What to do with "unusable prototypes" [...]

That's a hard one. Some software may have a narrow use case but do it's job. Some are developed with little resources and an awesome-list can boost visibility. I would not try to be too restrictive because in the end you rely on arbitrary decisions.

3 Are we including open-source only or closed-source too?

+1 to closed/commercial too. +1 to a 💰💰💰 marker

4 Should we sort software in categories by its name or by popularity?

Name IMO. Else, how do you decide on popularity? GitHub stars, package repository download count? Would someone keep the ordering in sync with changes to popularity?

if we agree on common IDE

One should never do that IMO. VS Code may be popular but it's not the only tool. And expect contributions directly from GitHub. All formatting, linting, spellchecking should be IDE-agnostic and runnable from the command line.

[amivanoff]

One should never do that IMO. VS Code may be popular but it's not the only tool. And expect contributions directly from GitHub. All formatting, linting, spellchecking should be IDE-agnostic and runnable from the command line.

IDE-agnostic CLI tools just for one file -- It looks like overkill. It also requires some stack commitment: Java one (Maven/Gradle) or JS (ESLint, etc) or any other...

[VladimirAlexiev]

@amivanoff , thanks for your PR!! I made some comments.

In general I agree with @tpluscode :

• let's be inclusive. Even if something appears dead, if it's promising, someone may revive it
• I like adding icons
• I would really like to have the last updated date and version. I understand these will get obsolete very soon, but still a sofware updated 5y ago is very different from one updated 1 month ago.
• number of contributors, stars and forks is also important info, would be nice to have
• IMHO it's ok to add substantive comments, even though these are subjective. Eg "tried it, can't compile" or "Shaclex is the only implementation of SHACL and ShEx"
• Within big sections, let's have subsections per language: Java, Python, JS. This is a major constraint on selecting a software
• Let's list the most important software first in a section. Eg for Java that's Jena, Rdf4j, TQ, Shaclex. For the less established sections, any order will do.

Last but not least:

• https://index.semanticscience.org/ is a treasure trove: 4.5k repos with SHACL, we need to explore them
• How do you call these? Guess we need a new section "Shape Extensions"?
  • https://index.semanticscience.org/
  • https://shape-fragments.github.io/shape-fragments-spec/

[VladimirAlexiev]

Can you add JS implementatons from https://github.com/w3c/shacl/issues/78#issuecomment-2354996813

[tpluscode]

• I would really like to have the last updated date and version. I understand these will get obsolete very soon, but still a sofware updated 5y ago is very different from one updated 1 month ago.
• number of contributors, stars and forks is also important info, would be nice to have

I like those ideas but I don't see this would be possible without actually generating the list and sourcing some of this information from GitHub directly. Else, as you said, it'd immediately become out of date

[amivanoff]

To indicate the last commit activity we could use bages from https://img.shields.io like here

• awesome-spark/awesome-spark
• wangzhe3224/awesome-systematic-trading

There are similar color-coded bages there for the latest release date from GitHub Releases and for the latest release version

Examples:

Jena SHACL - - tags, but no releases on GitHub

RDF4J SHACL Sail - - there are releases and tags on GitHub

Maybe we should choose only latest release or tag + last commit?

[amivanoff]

Release or Tag -- always blue, Release date or Last commit -- color-coded by "recency".

[amivanoff]

License and programming language formatting example awesome-selfhosted/awesome-selfhosted

[VladimirAlexiev]

More for "last but not least "  https://github.com/hypermedia-app/shape-to-query   https://shape-to-query.hypermedia.app/docs/#extension-spo-rule 

[VladimirAlexiev]

The only Ruby implementation I know: https://github.com/ruby-rdf/shacl/