Meeting minutes
(from Holger) Working Draft for Core and SPARQL Spec
HolgerK: Documents have been cleaned up since last week,
… Documents now self-contained, have no outside references
… there are few if any semantic changes.
elianaP: What is next step with these documents?
HolgerK: Changes had gone through PRs reviewed and approved by other editors.
gkellogg: Advice is generally, publish frequently. 1st public draft is special event that requires a working-group vote for each doc that will be published.
… Generally does not need to have changes from prior version.
… Next consideration: Auto-publishing when PRs are merged.
… and/or when `gh-pages` is updated.
… The next group vote would be for cor when /... ... and/or when idate releases.
gkellogg: Is there a way to see the formatted versions of PRs before merging?
elianaP: No update on whether this capability is present.
gkellogg: Current review process requires reviewing large diffs on HTML, but not rendered. Some group members rely on htmldiff.
… Githack may also be an option.
… Using a single repository for all documents limits some PR tool reviewability.
… A GitHub Action could be done to assist with reviews.
Eliana planning to send a Call for Consensus.
ACTION: Carine to send a snapshot for the Call for Consensus on the FPWD
<TallTed> s| and/or when `gh-pages` |... and/or when `gh-pages` |
ACTION: Eliana to send the call for consensus
gkellogg: Two actions needed from workin-group. First is agree for 1st working public draft.
… This should all be available in the W3C process document.
… auto-publishing (using Echidna tool)
caribou: One approval may be possible for several documents at once.
gkellogg: Automated publication via echidna is 2nd decision.
<gkellogg> w3c/
PR 261
HolgerK: First item is from original appendix of SHACL 1.0, verbatim copy of SHACL-SHACL inlined into the document.
… Suggests to drop this so SHACL-SHACL Turtle file is a second download.
… Suggest for addressing redundancy, and so a different release cycle can be followed for these two documents.
… For instance, SHACL-SHACL may be extended for purposes beyond Core, such as for SPARQL.
… Pull request is for removing inlined copy, replacing with separate Turtle file.
betehess: No objection, but what is the purpose or plan for SHACL-SHACL?
HolgerK: In the very last weeks of SHACL 1.0 working group, just prior to approval, it was reviewed by (among others) president of W3C, Tim Berners-Lee. He suggested such a document be part of the publication.
… This was created within an afternoon or less.
… No strong opinion, and would rather not spend more time on it.
… But if others are interested, they are welcome to work on it.
… Placement of SHACL-SHACL is now a little confused by having Core and SPARQL documents.
<betehess> We can always decide to publish as NOTE
elianaP: It is nice to have all of these things somewhere
ajnelson-nist: Also like SHACL-SHACL
gkellogg: It seems this may be publishable as a non-normative note.
elianaP Consequences for lifecycle?
gkellogg It is a W3C publication, but a TR, has no normative bearings. There are many documents that are purely informative, such as use cases, tutorials.
… Publishing as a note with parallel access to raw data would be adequate and useful.
betehess I suggest also this go out as a note
… Acknowledging Holger noting SHACL-SHACL's incompleteness. A resource like this has been needed at Netflix.
elianaP If we agree, I would suggest this be kept accurate, up to date, generally maintained by a core party.
… should not interfere with other deliverables.
ajnelson-nist: offer to maintain SHACL-SHACL
… what is the commitment here?
holgerk: vocabulary files with proper PRs
ajnelson-nist: are there notes on the current coverage?
betehess: they are coming
PR 254
HolgerK Have we now approved this pull request?
elianaP Yes, we agree on the separation.
Sorry, NOW topic: PR 254
<gkellogg> w3c/
HolgerK: Introduction of something we have used in production for some time now. It is basically a syntactic sugar.
… This assists with implicit targeting.
<caribou> PR 254
HolgerK: Basically now, a new meta class is introduced, `sh:ShapeClass`, which combines the full semantics of `owl:Class` or `rdfs:Class` coinciding with a shape class.
<betehess> +1 to sh:ShapeClass as long as the definition of implicit target class doesn't change
gkellogg So, this requires entailment in order to see the RDFS class?
HolgerK Not necessarily. But if it is in the spec, implementations would need to formally recognize this term.
… There is an implementation that tests this.
<caribou> Holger: OWL has the same mechanism with a metaclass
betehess I am mostly in favor with this proposal, but not sure I understood the part about a processor having to "Know about it"
… I don't think this houldhave an impact on the way things workt oday
bergos I am in favor.
… If you don't have ann OWL depenency, then this lets the specification be scoped just in SHACL
elianaP: IIRC When you don't have something aware of SHACL, then you don't get the expansion.
<betehess> I assume that people using sh:ShapeClass will be using SHACL 1.2 anyway?
bergos Would you still see these effects on property shapes?
elianaP I suggest tabling discussion. Please discuss further on Issue.
… we will pick up next week.
PR 268
HolgerK This was another feature in production usage as part of the DASH namespace
… This is a simple constraint component, boolean-valued, typically set on property shapes,
… stating this property cannot have line breaks,
… typical use cases: labels, IDs, things showing up in tables or tree structures.
… Can be expressed in `sh:pattern`, excluding certain characters,
… but a boolean simplifies things for users and form developers - query for boolean value to determine if a multi-row text field should be provided.
… One test cases provided.
<caribou> PR 268
betehess SHACL-Core could become a space for many such interesting components. But, there are 10s of other examples like that. Could these constraints be expressed outside of SHACL core?
YoucTagh If we want to keep SHACL-SHACL alive, should we wait until we add the SHACL-SHACL part to this PR?
elianaP This is now a procedures discussion.
… It is fine for CURRENT PRs to not have SHACL-SHACL updates,
… but in future, please keep all the updates within the one PR.
Question on whether page constraint width was considered
<AndyS> w3c/
HolgerK - This seems like a general HTML-level issue, not something for SHACL to fix
AndyS I'd raised another issue about balancing "kitchen sink" vs small core specification
… I suggest drawing up a big list of all the desired features, so we can determine scope / size of space
elianaP Do you think there are many such shortcuts?
AndyS They're domain specific. I found about 3 for strings, checking URIs for namespaces - didn't come up with very many.
elianaP Do these pertain to SPARQL functions?
AndyS Regexes could cover much, but we could also leave paths for implementers to make faster code paths than evaluating general regexes
elianaP Agreed, this seems like a good list to create.
AndyS - Please add to Issue 221.
bergos Agreed with Andy, a list would be good. Can we keep a running list on an Issue?
elianaP Yes, let's please.
gkellogg When adding such convience accessors, it would be nice to have evidence of value.
… Yes, many things can be done with regexes, but there's a reason most languages provide convenience functions for similar functionality.
… Our evidence could include feedback from community
elianaP This evidence could be difficult to gather. We might have most of the interested community right here.
… How would you gather such feedback?
gkellogg Agreed, eliciting use cases can be difficult
… Raised as a principal consideration.
elianaP Another concern: Evaluating feedback. If there's 0 feedback, do we say, throw it out, it's not useful?
gkellogg Why're we spending time on it if "No one" is interested in it?
elianaP Asking for feedback is always good. We can see about evaluating it when it comes in.
… We should add this as a point for the list of simplified/shortcut functions.
<betehess> +1 to the principle discussed by Gregg to be applied when adding something to CORE
elianaP Decision about pull request?
HolgerK - Put it in for now, raise ticket later when we've gathered evidence?
gkellogg We can also add features as "at risk"
… This flags things for community feedback, gives easy mechanism for later removal
PR 265
HolgerK SHACL Turtle file contains terms from SHACL-JS document, which was discontinued, and only attained "working group" draft status
… Terms could be deprecated, too.
… Likely these terms were least-used, less than SHACL-AF
elianaP Seems straightforward
betehess - Is there a rule about modifying resources in-place?
caribou If it's a document, we can publish as discontinued. If a namespace we cannot destroy the URI.
betehess We're discussing editing a resource "in-place". Is this fine?
… E.g. Can rdfs:domain statements be removed?
caribou I don't think we can removing anything from slash-ns (`/ns`).
<AndyS> https://
betehess I mean removing defintions from within /ns/shacl.ttl.
caribou If you want to edit the resource, it must be backed by a change to a REC-track
gkellogg Namespace documents ARE updated from time to time, e.g. JSON-LD document was updated
… seems there's confusion in discussion - removing namespace VERSUS removing resources within the namespace
… What are consequences of removing some resources within namespace document?
… Principal: Resolving a URI should continue to work even after changes, even if lesser information is returned after an update.
… Generally, this mechanism seems to not be catastrophic.
… We should follow principal of least harm.
… Evolution of documents is generally additive, but in cases like this where something may be decided as inappropriately published, cleanup should be fine.
elianaP We're not removing a namespace, just removing parts of it.
gkellogg Comments could always be put in to say deprecated or removed.
caribou Sometimes, some groups have changed contents that was at a specific namespace. Sometimes this was versioned because of backwards-incompatible changes, sometimes done at second namespace.
… This is less possible for normative resources.
… Basically, breaking implementations is not allowed
<betehess> I assume none of the JS-terms were normative?
betehess What happens if the -JS things are kept in the document?
… Not necessarily suggesting this, but would like to understand consequences.
elianaP Summarizing: Nobody in principal opposed to removal, but there might be technical difficulties.
… Out of time for today.
… Please continue discussion on Issues.
HolgerK IIRC, I don't think the namespace document was declared as normative. It happens to include SHACL-AF features as well.
… If we're now deciding we CAN'T change this document, this would be trouble.
caribou This might need a different namespace.
gkellogg This is aproblem showing up in a lot of places, e.g. from MediaType requirements.
AndyS Are we publishing SHACL-Core, but without Node Expressions in it?
gkellogg Do we need a resolution to publish first working draft?
caribou We are doing that offline, as a Call for Consensus.
AndyS We're doing Node Expressions now. But as first draft, this can change.
caribou Doing document now lets us reserve the short name.
elianaP Let's go ahead with the call for consensus.