This repository was archived by the owner on Mar 17, 2025. It is now read-only.
(will) need support for RDF 1.2 #23
Description
Came up in w3c/vc-data-model#1416 (comment)
RDF 1.2 (and SPARQL 1.2) is in the works in the RDF-star Working Group.
Updating SHACL to match will be very desirable upon TR, if not sooner.
Activity
afs commentedon Jan 31, 2024
From the RDF-star CG: w3c-cg/rdf-star#122
which, depending on the design choices, may well apply to RDF 1.2.
HolgerKnublauch commentedon Feb 1, 2024
I'd be happy to help but does anyone know the W3C process well enough to drive it? Ted, would you chair that effort again?
And how much time would we get? Asking because there is probably a number of other relatively uncontroversial things that we could clean up on this occasion. In a nutshell, I would propose to separate the docs into
and have those as living standards. For the 1.2 deadline only Core and SPARQL would need to be finished, and are quite easy to do, while inferencing may take longer. But once we have them set up as living standards, we could by consensus of implementers move the individual documents forward without getting stuck in a multi-year process.
TallTed commentedon Feb 1, 2024
@HolgerKnublauch —
I might be able to serve as co-chair in similar fashion as the previous Shapes WG. I certainly do not think I could do it justice solo. (Last time, when @irenetq and I took over as co-chairs, she handled most agendas and other pre-meeting effort, while I chaired most concalls.)
Your suggested separation, and shift to Living Standards, makes sense to me.
Our previous team contact (@sandhawke) is no longer a W3C staffer, so we'll need a different person, who might be enlistable in advance to assist with drafting a proposed charter. One possibility is @pchampin, who is currently team contact for a couple of other WGs I'm in, so might be overloaded ... but might have another suggestion.
pchampin commentedon Feb 2, 2024
+1 to eventually align SHACL with RDF 1.2 and SPARQL 1.2 -- that is, once RDF 1.2 and SPARQL 1.2 starts to stabilize...
As @TallTed assumed, I am a bit overloaded, and I don't have anyone to suggest, unfortunately.
But that should, IMO, prevent motivated people to organize towards the creation of a WG. I'll bring the help I can.
TallTed commentedon Feb 2, 2024
should NOT, I think... :-)afs commentedon Feb 5, 2024
Sounds like a short CG phase to create a proposal and show community support. i.e CG telecons, splitting into three docs @HolgerKnublauch suggests, preparing the scope of a SHACL WG to start living standards mode, collecting the errata to address (esp. if the errata fixes are actual changes that don't fix "living standards").
What about DASH?
TallTed commentedon Feb 7, 2024
I don't (yet) have an opinion on whether DASH should become part of any SHACL 1.+ work.
If it were to become such, I think @HolgerKnublauch (and/or TopQuadrant) would probably need to hand over most if not all of the
datashapes.orgcontent to the CG and/or WG for full integration.afs commentedon Feb 9, 2024
In moving forwards with SHACL, being clear about what is "the base" (I would say "core" but ... :-)) and what is extension will matter. Not everything has to be a formal standard - they are slow-cycle evolution, needing to bring together diverse points of view together.
Specific communities and domain interests can produce focused shape-ontologies, "best practices" documents in a lighter weight governance such as a CG and not a WG.
DASH is mostly foundational; other common tasks at datashapes.org probably don't need or benefit from full WG-level governance.
HolgerKnublauch commentedon Feb 9, 2024
Some DASH features could be shifted into the sh: namespace, e.g. dash:singleLine and dash:closeByTypes.
For the dash Forms vocabulary (dash:viewer/editor etc), I am not sure, and a more flexible community driven approach might be best as people will more likely want to extend this.
Dash property roles could be added to SHACL Core at some stage - they are quite harmless annotations.
Dash Templates could be moved into SHACL-SPARQL.
Dash multi-functions COULD be moved into SHACL-SPARQL, assuming SPARQL supports a suitable syntax for functions with multiple result rows and variables.
Overall, I agree that some things evolve more efficiently outside of rigid W3C processes, as witnessed by the success of Neo4J who can simply decide whatever they want and turn around quickly.
HolgerKnublauch commentedon Feb 9, 2024
Oh and the largest of the DASH features - Active Data Shapes - would be competition to RDF-JS and would be hard to standardize. All I can say is that our customers are very heavily using this feature and get a lot of practical work done to solve real-world problems. But again, a community approach would work best here, like an open source project.
HolgerKnublauch commentedon Feb 12, 2024
A previous request for 1.2 support was #15 which I will close as duplicate.
TallTed commentedon Feb 12, 2024
Neo4J is a software project, not a standard development project. Software projects can (sometimes, not always) indeed evolve more efficiently outside of W3C and similar SDO (standards development organization) processes; e.g., they can "move fast and break things".
In the world of SDO, on the other hand, it is almost always a goal, if not objectively better, to move (more) slowly and (as much as possible) avoid breaking things.