Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

SHACL on Graphs #25

Open
wants to merge 9 commits into
base: main
Choose a base branch
from
Open

SHACL on Graphs #25

wants to merge 9 commits into from

Conversation

VladimirAlexiev
Copy link
Collaborator

closes #24

tpluscode
tpluscode requested changes Nov 28, 2024
View reviewed changes
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated
Comment on lines 148 to 153
- SHACL on Graphs (as discussed in [shacl#22](https://github.com/w3c/shacl/issues/22) and [Inst4CIM-KG#140](https://github.com/Sveino/Inst4CIM-KG/issues/140))
- [Data Graph](https://w3c.github.io/data-shapes/shacl/#data-graph) and Shapes Graph are the inputs to a SHACL validator - But these are "ephemeral", and spec doesn't concretize how to pass them to the validator.
- [sh:shapesGraph](https://w3c.github.io/data-shapes/shacl/#sh-shapes-graph) - A triple in the data that **suggests** which shapes to select for validation.
- `rdf4j:SHACLShapeGraph` - in RDF4J is the default shape (see [this blog](https://www.ontotext.com/blog/shacl-ing-the-data-quality-dragon-iii-a-good-artisan-knows-their-tools/)).
- `rsx:DataAndShapesGraphLink, rsx:shapesGraph, rsx:dataGraph` - in RDF4J allow to describe exactly which shapes go with which graphs (see [doc](https://graphdb.ontotext.com/documentation/10.8/shacl-validation.html#union-of-data-graphs-when-validating-the-results) or [this blog](https://www.ontotext.com/blog/shacl-ing-the-data-quality-dragon-iii-a-good-artisan-knows-their-tools/)).
- [Extending SHACL to RDF Datasets](https://afs.github.io/shacl-datasets.html) - Proposal that describes applying SHACL to RDF Datasets by Jena's author.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little hesitant to accept vendor-specific extensions in the "Specifications" section.
If we are to include these, maybe add a clear separation from the standards?

Copy link
Collaborator Author

@VladimirAlexiev VladimirAlexiev Dec 3, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it ok now: https://github.com/w3c-cg/awesome-semantic-shapes/blob/VladimirAlexiev-patch-1/README.md#specifications

  • Data Graph and Shapes Graph (SHACL spec) - the inputs to a SHACL validator, but these are "ephemeral", and spec doesn't concretize how to pass them to the validator.
  • sh:shapesGraph (SHACL spec) - A triple in the data graph that suggests which shapes to select for validation.
  • rdf4j:SHACLShapeGraph (RDF4J extension) - default shape graph in RDF4J (see this blog).
  • rsx:DataAndShapesGraphLink, rsx:shapesGraph, rsx:dataGraph (RDF4J extension) - describe exactly which shapes go with which graphs (see doc or this blog).
  • Extending SHACL to RDF Datasets (by Jena's author) - Proposal that describes applying SHACL to RDF Datasets.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tpluscode is it ok now?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure, sorry. Would like a second opinion. @TallTed @amivanoff ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TallTed @amivanoff @labra @dontcallmedom Please weigh in here

Copy link
Contributor

@amivanoff amivanoff Jan 3, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think, I need to clarify some terminology and initial intentions of this sections (embedded in the initial structure of sections). Maybe it needs to be corrected. Maybe some corrected version needs o be added as a brief explainer in each of sections.

  • "Specifications" -- Any more-or-less formal shapes-related useful published document, regardless of it's origin (W3C's, specific vendor's or some expert's) or readiness status (draft/final))
    • "W3C Recommendations" -- The current W3C-recommended specifications (with final status, endorsed by W3C).

Maybe it would be better to break-down "Specifications" into several subsections?

For example:

  1. To divide the "Specifications" top-level section into two second-level sections like "SHACL Specifications" and "ShEx Specifications"? The same way as in the case of "SHACL Validators" and "ShEx Validators"?
  2. To divide "SHACL Specifications" into several 3-rd level subsections. Like this, and add as brief explainer in each section?
    a. "Current W3C Recommendations"
    b. "Ongoing Work in Progress in W3C WG" (I think, "WG SHACL Drafts" as well as "SHACL on Graphs" belongs here). All vendor-spec extensions, related to the new "work-in-progress" features/issues, covered by the new W3C draft, belongs here (with a hope it will be aligned to the spec in the end, or not then it goes to 2.c)
    c. "Vendor-Specific Extensions" (which are not in scope of the new spec draft, or a clear deviations from current Recommendations)
    d. "SHACL-Related Specifications"

Result section structure (section headers):

  • Specifications
    • SHACL Specifications
      • Current W3C Recommendations
      • Ongoing Work in Progress in W3C WG
      • Vendor-Specific SHACL Extensions
      • SHACL-Related Specifications
    • ShEx Specifications

TallTed
TallTed suggested changes Dec 12, 2024
View reviewed changes
Copy link
Contributor

@TallTed TallTed left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm good with the other changes. One small additional suggestion.

README.md Outdated Show resolved Hide resolved
@amivanoff
Copy link
Contributor

amivanoff commented Dec 13, 2024 •
edited
Loading

It will be good to pick a default way to ignore linter's errors.

Examples of two approaches below, assuming there are link duplication (links differs only in #fragments treated as the same) and item formatting problems:

  1. Ignore several lines. This approach will provoke inconsistencies in the formatting of list items.
<!--lint disable awesome-list-item double-link-->
A whole document
or a section,
or several list items here
<!--lint enable awesome-list-item double-link-->
  1. Ignore non-standard list items one-by-one (one per line). This approach will show more clearly problematic items. But requires more efforts.
  <!--lint ignore awesome-list-item double-link-->
  - [SomeSoftware](https://acme.com/some-duplicated-link) some text within an item's name but not a part of the link - description starts with lower-case letter and without an ending comma
  <!--lint ignore awesome-list-item double-link-->
  - [SomeSoftware](https://acme.com/some-duplicated-link) some text within an item's name but not a part of the link - description starts with lower-case letter and without an ending comma

@amivanoff
Copy link
Contributor

I added code suggestions to the relevant lines according to the approach from n.2 (one-by-one).

amivanoff
amivanoff suggested changes Dec 13, 2024
View reviewed changes
Copy link
Contributor

@amivanoff amivanoff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some issues lines causes linting errors

README.md Outdated Show resolved Hide resolved
README.md Show resolved Hide resolved
README.md Show resolved Hide resolved
README.md Show resolved Hide resolved
@VladimirAlexiev @TallTed
commit TallTed's suggestion
b1cd058 
Co-authored-by: Ted Thibodeau Jr <[email protected]>
@VladimirAlexiev VladimirAlexiev mentioned this pull request Dec 17, 2024
Open
@VladimirAlexiev VladimirAlexiev mentioned this pull request Jan 2, 2025
Open
VladimirAlexiev and others added 3 commits January 2, 2025 16:16
@VladimirAlexiev @amivanoff
ignore double-link
8617526 
Co-authored-by: Aleksei Ivanov <[email protected]>
@VladimirAlexiev @amivanoff
ignore double-link
f7bbda8 
Co-authored-by: Aleksei Ivanov <[email protected]>
@VladimirAlexiev @amivanoff
ignore double-link
dbb77a7 
Co-authored-by: Aleksei Ivanov <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@TallTed TallTed TallTed requested changes

@amivanoff amivanoff amivanoff requested changes

@tpluscode tpluscode tpluscode requested changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Add "SHACL on graphs" proposal
4 participants
@VladimirAlexiev @amivanoff @tpluscode @TallTed