`rudof` gives lint:double-link warnings

[VladimirAlexiev]

https://github.com/w3c-cg/awesome-semantic-shapes/actions/runs/12038380640/job/33563929313#step:5:1
Shows a bunch of lint:double-link errors because the "rudof" line is duplicated.
I think we should disable this check: @amivanoff is that possible?

[amivanoff]

It's doable by "ignore" statement (above duplicate items) in markdown, like this:

<!--lint ignore double-link-->
- [rudof](https://rudof-project.github.io/rudof)

But I'm not sure if we should do this. We have faced this issue before with SHACL/ShEx Jena validators #3 (comment) and have decided (if I've got it correctly there) to use more specific links to the submodules in a source code repository.

This decision is already documented in the CONTRIBUTING.md.

Example:

This link https://rudof-project.github.io/rudof with label "rudof" is mentioned in two sections "SHACL Validators" and "ShEx Validators". According to the guide, it should become two links:

• https://github.com/rudof-project/rudof/tree/master/shacl_validation with the label "rudof shacl validation".
• https://github.com/rudof-project/rudof/tree/master/shex_validation with the label "rudof shex validation".

This link https://rudof-project.github.io/rudof/cli_usage/convert.html from the section "Shape Conversion Tools" and label "rudof" should become the link:

• https://github.com/rudof-project/rudof/tree/master/rudof_cli with the label "rudof cli".

So, there are NO duplicate URL links, and duplicate link's text (label).

We could change this approach to any other, but we must update Jena's items in README.md and CONTRIBUTING.md to preserve consistency.

Maybe it is even better to update the CONTRIBUTING.md first.

[VladimirAlexiev]

@amivanoff you make very good points, and I edited the title of this issue.

However, I'd use links to the documentation (and remove or have links to source as secondary):

• https://rudof-project.github.io/rudof/cli_usage/shacl.html
• https://rudof-project.github.io/rudof/cli_usage/shex.html
• https://rudof-project.github.io/rudof/cli_usage/convert.html

@jeswr You contributed rudof, right? Could you fix this?

[amivanoff]

This links points to the command line interface.

But validator libraries have different interfaces
https://docs.rs/shacl_validation/latest/shacl_validation/
https://docs.rs/shex_validation/latest/shex_validation/

It's interesting ontological question. Where are the boundaries of a "validator" in this dependency tree?

Should we recognize as "validator" only a library with an algorithm implementation?

Or this distinction should be "interface based": all modules, involved in a data pass from a user to a validator and backwards, are considered as parts of "validator"?

Or will it be no recognition, just rudof for SHACL, for ShEx, for converter CLI?

Example from the Java world:

• Jena SHACL Validator library
• CLI interface wrapper (with validation commands) + Jena SHACL Validator library (+ many other stuff)
• REST API (with validation requests) + persistent store + Jena SHACL Validator library (+ many other stuff)

[amivanoff]

The same question for rudof. It's quite compleх piece of software. Where are the validator's boundaries on this dependency diagram?

Picture from https://rudof-project.github.io/rudof/overview.html

[amivanoff]

So, besides formatting complications from #16 there are some "semantics" questions:

• ontological grounding and uniform grounds for software classification (relation between an abstract "validator" and a specific "software module" from a particular project)
• information consistency in the list (the same approach applied uniformly to the complex software in any language, like Jena, RDF4J, rudof,...)

[amivanoff]

Another open question:

• how to assign globally unique dereferenceable identifiers of the software and its parts

[VladimirAlexiev]

You're overcomplicating it a bit. All that we care is that rudof includes SHACL, SHEX.

• IMHO the first (leading) link should be to the end-user documentation (I'm neither a rust nor python programmer).
• and we can add links "(library)" pointing to the developer documentation

[VladimirAlexiev]

@amivanoff do you agree with the sentiment in my last comment?

[amivanoff]

Ok, do we need to change Jena's and RDF4J's items to make it a consistent approach?

[VladimirAlexiev]

@amivanoff Yes! Could you please do it? I think I did it for rudof in #31.
And I see in #25 that you add linter switches to turn on/off various validations: is that documented in CONTRIBUTING.md so we don't have to ask you every time?

Huge THANKS for mastering the awesome tools for us!

[amivanoff]

I suggested some further improvements on rudof list items in #31. I'd like to address them first and then we'll return here.

[VladimirAlexiev]

• I went through feat: add rudof #13 and SHACL on Graphs #25, accepted many suggestions, and posted one question.
• Due to Direct link with hash in contents is marked as double-link sindresorhus/awesome-lint#194 we should use your ignore doule-link trick to prevent warnings on known good links
• At the same time, we should continue to provide precise links (with fragments) when appropriate.

Where are the validator's boundaries on this dependency diagram?

I don't know and it's not the job of the awesome list to provide such levels of detail. All we care is to point to "shacl validator" and "shex validator", maybe also to "cli", and to github: that's more than enough info.

So @amivanoff, can we close this or you'd like to continue the discussion?