Meeting minutes
AndyS: The timeline for rules is tight. We have a general sense of where we want to get to, but long way off to a complete document
nicholascar: Compact syntax - Jesse is keen to make time to work on CS, but it may need to drop back to a note
Robert: With CS - with Vlad, he's very busy with projects and may not find the time. No one else is available from Graphwise to volunteer
Review of PRs
<AndyS> https://
AndyS: There appears to be many open PRs. The preference would be to close them if they're not going anywhere. It's easier to manage, and they could always be re-opened.
<ajnelson-nist> usnistgov/
TF Reports
HolgerK: Not many updates in the last 2 weeks for core, but in a sense, those docs are almost feature complete. There may be some movement on the new shui:intent property in the next week or so
nicholascar: Profiling meeting is back on this Thursday. Meet with the task force and discuss scoping and timing.
… There's also a recent PR that will be discussed in this Thursday's meeting. It's about what profiling provides to SHACL
ajnelson-nist: I plan to put my comments in on what I see profiling is in SHACL
edmond: widget scoring section still in progress. Start adding testing for various UI parts, GH Actions?
AndyS: triaging issues and PRs for rules. Could the editors approve PRs that are ready?
… We had a meeting last week with the co-chairs of the N3 WG. We have common problems and solutions regarding rules. Discussed guardrails for long-running rules data generation. Users may need to tolerate limitations in rules such as no blank nodes in rule bodies.
Specific issues worth discussing
AndyS: Should we align the terminology used in abstracts across documents? For example, remove the framing of SHACL as only for validation.
<AndyS> w3c/
nicholascar: Should namespace and suggested prefix go in the abstract?
… PROV and DCAT do this
AndyS: SHACL Core, it's in a separate section and not in the abstract
… We don't need commonality, but at least an aligned definition of what is SHACL in each document would be nice
<caribou> anything normative should NOT be in the abstract
<caribou> (definition of a namespace for example)
HolgerK: A generic definition of what SHACL is, and then a description of what the document is about would be good.
TallTed: It seems odd that some other documents have namespaces and prefixes in the abstract
simonstey: I am unclear on what it means by "generating data for other agents". Just a nitpick
AndyS: I'd like to highlight caribou's point that the abstract should not contain normative content
caribou: If it's defined elsewhere in the doc and also mentioned in the abstract, then it's fine
nicholascar: As part of the Profiles meeting, we will work to emulate the structure for the profiles abstract
General Business
edmond: Are there any restrictions on what kind of GitHub Actions are allowed for the repository?
caribou: For validation, it should be fine. No hard rules.
ajnelson-nist: A downstream repo (e.g., a submodule) may work as well. I've previously done this
AndyS: Should I create a subdirectory for last year's agendas and a separate one for this agenda? It's difficult to find them now that we have a long list of files.
nicholascar: Yes, I will split them into a 2025 and a 2026 folder
rssagent, bye