Meeting minutes
Phase 1 deliverables
nicholascar: Groups have been notified about the Phase 1 review.
… Two issues, #236 and #235 with progress points, on Github
… Likely that only significant changes have to be mentioned, e.g. not privacy, accessibility etc. We do need the architecture review.
… In the previous SHACL version, the implementation report is in the test suite, we need to see if that can remain where it is and if it can be dual-indicated.
… No major implications for the rest of the reviews. We just wait for responses.
… Then documents can move to CR, new changes won't mean that the whole body of those documents will have to be reviewed again.
AndyS: We have an issue about user protocols. Permissions may be tricky.
… SHACL could therefore be a tool to leak data.
… Reviewers for security may raise an issue about this.
… Nothing in the spec says that implementers have to consider potential security risks.
… A change may be necessary in the security section. We don't know right now the preferences W3C has on this point.
nicholascar: In the Privacy and Security section, user actions resulting in data leaks are mentioned. We don't fall into that category. Maybe security more than privacy.
… Validation reports may be accessible to parties unauthorized to access the actual data.
… Once you're in a graph, maybe the SHACL engine can see parts of it.
… In the reviewer reports, in the self-assessment section, now in issue #682 with 22 questions, we have written answers. Should check if we can add more there.
bergos: We have to be careful about what the engine has access to, and who the validation report goes to.
nicholascar: Let's see if this will be an issue for the P&S group. Even if they don't, maybe we should still consider it further.
caribou: Not sure how much attention will be given to this point.
TallTed: W3C won't inspect this point from that perspective. We have to say "be careful with sensitive data" but are not obliged to solve the issue in SHACL.
nicholascar: We should raise this point so that users are aware of potential risks.
Task force reports
nicholascar: Core group update
HolgerK: No significant updates. Also not for SPARQL, just editorial changes. For Node Shapes, we renamed the namespaces for consistency (ns/shacl-[something'])
nicholascar: Profiles group update: Meeting again this week. I have thoughts about adding elements. Question to core: is there a superproperty of sh:targetClass or other targer properties?
… Might be interesting to have a superproperty for targets. Will discuss with the Profiling group.
… SHACL UI group update:
Edmond: PRs have been merged. Widgets are being discussed. Data retrieval from named graphs is another point.
… How do we handle blank nodes, how do we retrieve data from remote sources? Topic has been added to General Business, to discuss if we have time today.
nicholascar: SHACL Rules report
AndyS: Rules TF
… 1. Definitions now in ED : https://
… 2. Process: baseline then features
… Timescale: WG runs until "2026-12"^^xsd:gYear : Need doc+tests+implementation reports.
AndyS: Let's concentrate on the base features, but let's be careful with extra features and see what time allows.
nicholascar: Content ideas need to be written down in Q1 2026 for us to have a better picture. We may have to be harsh when deciding what will make the cut.
AndyS: 3. Tests: http://
… a test is an action (rules+data) and a result.
… syntax (inc well-formedness) and evaluation tests
… w3c/
AndyS: Let's use TF meetings for discussions and do more work asynchronously in documents.
bergos: For validations, we have tests where the data and the shapes are in separate graphs. Reports are usually in the same file.
… Do we have to have new namespaces and structures?
<simonstey> https://
AndyS: We have to keep those to make clear which test is being run
simonstey: Can't we use the way SHACL Construct uses? Do we have test cases for the SHACL 1.0 rules, as that was the same situartion?
AndyS: It's the same indeed
AndyS: FPWD
nicholascar: Haven't thought about tests for Profiles. Worth considering on Thursday.
… Documents have to be moved to FPWD.
caribou: The group can decide this during a call.
AndyS: We signaled that we would do this a couple of weeks ago. Can we vote/agree now? The editors are here.
<simonstey> +1 (happy)
nicholascar: Anyone who needs more time, any objections?
… No objections, we have voted to publish the FPWD.
RESOLUTION: the SHACL Rules document will be published as a FPWD
simonstey: regrets for some future Rules task force meetings, can they be moved?
AndyS: 12:00 CET?
<AndyS> Notation3 discussion with Dörthe Arndt
<AndyS> date/time now to be rearranged
nicholascar: No one on from SHACL-C
… We will have to make some decisions about this. Let's ask for a proposed timeline from the editors.
SHACL UI discussion
Edmond: Should a named graph be supported? Two scenarios and questions.
… Scenario #1: Should SHACL-UI have the capability, when it fetches data, to target named graphs outside the main SHACL data graph. Useful for widgets for data tables. We have some practical use cases.
… Scenario #2: Should editiing (including writing data) be supported by SHACL-UI?
… and should this be supported for different / named data graphs?
… Does SHACL Core have mechanisms that support this already? Does the group have similar use cases? Are those use cases practical to support?
… Scenario #1 seems like a likely yes, Scenario #2 seems harder.
nicholascar: Scenario #2: is this about writing changes to a different graph?
Edmond: Maybe. Or the resources displayed are pulled from multiple graphs.
nicholascar: Is it important to be able to pull from multiple graphs? For shapes and data?
Edmond: Data may live in different named graphs to populate certain widgets and then write back to the named graph.
nicholascar: This is also related to the previously discussed point about security. Is there feedback now?
bergos: We should think of this as general data support. Should there be a Core feature that says you can support general datasets with different levels of complexity or entry? Should we tackle this as a UI-specific issue?
… From an implementer's perspective this may be difficult. But there are scenarios where we may need support on multiple levels.
… In the Core group, no one thought this didn't make sense, but also no one picked it up
HolgerK: We discussed last year November, there was a suggestion to raise a ticket about this. The decision was to keep Core tidy and simple, not add annotations for named graphs to different constraints.
… This is probably too big a change to bring into the picture now
nicholascar: If we don't get such a change into Core, can the UI group survive? What would the implications be?
… (question to Edmond/bergos: what would the outcome be if this change is not made?)
… No other general business items. That's the meeting!