Meeting minutes
elianaP: any open questions from last time
nicholascar: what would people like to see in overview document; who would like to contribute, do we need further discussion
elianaP: suggest writing shell as starting point
nicholascar: there is a minimal draft so far; do we need history of shacl etc. or minimal
ajnelson-nist: practical point: list of deliverables on charter or readme, could go into overview doc
ajnelson-nist: stubs that we have now should go into the overview document
ajnelson-nist: hard to find things in OWL, there is no single overview
ajnelson-nist: Holger previously you wrote on SPIN and SHACL, it was a good read, would like SHACL inferencing to go in this direction
HolgerK: SPIN rules would iterate until no further data
ajnelson-nist: I think it would be a good overview reference
HolgerK: SPIN, SHEX, and some historical input from IBM would be needed; not sure if still entirely relevant
<HolgerK> https://
ajnelson-nist: the doc helped me understand gap between OWL inferencing and currently more complex than SHACL inferencing; things that seem to currently require SPARQL construct
elianaP: would this help people choose between the different techs
ajnelson-nist: not sure
nicholascar: may be sensible to show awareness of other things e.g. SHEX, an overview doc could potentially have these references
AndyS: aim rule for inclusion, things required to read, does not need to include history. Can include history in separate note. Test is what is required reading if coming back to SHACL
elianaP: a user may be new and want to know which part of SHACL they should use; after basic information
AndyS: overview provides a reading path through documents
elianaP: ideally keep overview short and concise. Keep other details elsewhere
nicholascar: I will do SHACL SHACL, core (?) overview
AndyS: other document to be produced is "what is new in 1.2"
<HolgerK> https://
nicholascar: what is new even within core as well
bergos: think about the audience, some users in detail, interested in theory.
elianaP: keep part of history in main document?
bergos: depends on length, if long put in separate, shorter can keep in relevant spec
nicholascar: as example, background to reasoning systems can go in rules. Other shorter things, that still need to be addressed, could go in overview.
HolgerK: linked in article, what is new in SHACL 1.2, plan to publish tomorrow. One example of how the overview could be done
HolgerK: on primers, these are important. A lot of feedback is people learning SHACL start with the specs, expect them to be less formal than currently. Too formal/difficult currently.
HolgerK: e.g. in Node Expressions there is "getting started with Node Expressions", which is an informal intro. Would be good to have the same in core/rules/others.
HolgerK: hope there is more interest in making the core readable
elianaP: if there are interested people in helping with this please say
nicholascar: I will try and assist with this, have similar problems elsewhere, tension between wanting to write formal/correct spec and explanatory content
nicholascar: pattern section; sh:or is a recent example. Not a comprehensive rewriting, "informal assistance from experience"
HolgerK: should distribute example/explanatory sections among editors; can do this later, just want comprehensive examples at start of spec
nicholascar: agree targeting is a tough area for people. There is still scope for someone to assist in editing core
validation reports and levels
elianaP: revisit this topic from last meeting
bergos: conformance property, a lot of users rely on it, good to keep. A lot of users are used to it, expect a simple property. Do we want it - I think we do, logic behind it.
ajnelson-nist: also think good to have stored rather than computed. For simplicity, can look at a single result.
HolgerK: changed mind; should now keep it, for backwards compatibility. Non strong reason to remove. Ensure meaning is correct. Debug, Trace, should not be violations. Update spec along these lines
nicholascar: propose adding another property, "conforms level", default is only fail on violation, could set to warn
elianaP: good idea, don't like idea of changing meaning of existing
ajnelson-nist: there are a few use cases , explanation/reproduction, e.g. SHACL engine users need to reproduce test results, do end users also need the same. How to inform users on how tests were run, currently use Makefile.
elianaP: we would want to include threshold in reports too
mgberg: custom severity levels, then need to define where in the order it fits so requires sh:order, need to include this in shapes graph
mgberg: can insert them in the order wherever
nicholascar: fixed out of the box order; can insert between these e.g. 3.2
ajnelson-nist: must it be an ordered list, could it be a set?
mgberg: don't think it has to be ordered
bergos: need to be careful with violations, any violation has an impact on the report. Engine setting to choose violation level. Also support order and can include custom ordering. Even if this adds complexity to the spec would help clarify things
elianaP: suggest option specifying cutoff as numerical value with violations assigned numerical value
bergos: engine can then use this numerical value
nicholascar: don't need numerical values necessarily. Must handle current output of violations that are e.g. warning violations
elianaP: so don't need numerical but would it make things simpler
<ajnelson-nist> `[] sh:conformanceDisallows (sh:Violation , sh:Warning) .` ????
<ajnelson-nist> erm, sorry, errant comma.
HolgerK: two approaches: instead of numeric ranges, list result types that don't count as violations, this is backwards compatible. Could use additional triples as pointers to these.
HolgerK: introduce "informative result" property and store non violating results in a separate property. Definition remains same.
nicholascar: decide do some or all levels trigger violations, can see all outputs from these in results, assign meaning as users desire. As alternative to numerical ordering.
bergos: what other use cases are there, to define different threshold that is not ordered?
ajnelson-nist: deprecation warnings, meaning changes over time, something becomes severe over time due to changes in external context
nicholascar: similarly, things I need to fix later, for now make sense as warnings, later can be violations
elianaP: can consider until next meeting, urgent decision not required. Everyone agrees on keeping backwards compatibility. Open topic on ordering/not
elianaP: bergos to create new issue for this topic
<HolgerK> We should just add sh:informativeResult as a new property. This solves the issues IMHO.
status of subgroups
<ajnelson-nist> HolgerK - Agreed, `sh:informativeResult` might also work.
HolgerK: will merge slower in future. Draft is in good state, stable publicly visible document is there now. Need more reviewers
ajnelson-nist: SHACL SHACL nothing further to report,
nicholascar: will get PR in for SHACL SHACL, next meeting this time slot this Friday
nicholascar: SHACL Profiling: on hold until finished SHACL SHACL document, as dependent on this. Overlap in people on both specs. Few weeks off starting
AndyS: Rules: putting HTML doc together, draft not finished, doing formal part first, then will come back to informal overview
edmond: can discuss scope with those interested, need initial meeting
AndyS: where are we on process for SHACL core, ready for horizontal review?
nicholascar: should do informal example before horizontal review. Up to editors to decide if they want this first. Do not want to progress too far with core as may be updates from other specs
caribou: for horizontal review, need "explainer", not quite a primer, related to example. There is an explainer explainer, will be added to minutes.
TallTed: change in other groups to not have explainer but move it into other documents
<caribou> https://
ajnelson-nist: should the explainer go into overview?
<caribou> Writing Effective Explainers
TallTed: explainer has typically been more than a few paragraphs, less than a full spec