search

w3c / shacl

SHACL Community Group (Post-REC activitities)
27 stars 4 forks source link

(will) need support for RDF 1.2 #23

Open TallTed opened 5 months ago

TallTed commented 5 months ago

Came up in https://github.com/w3c/vc-data-model/pull/1416#issuecomment-1915680267

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.

afs commented 5 months ago

From the RDF-star CG: https://github.com/w3c/rdf-star/issues/122 which, depending on the design choices, may well apply to RDF 1.2.

HolgerKnublauch commented 5 months ago

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

TallTed commented 5 months ago

@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 commented 5 months ago

+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 commented 5 months ago

that should, IMO, prevent

should NOT, I think... :-)

afs commented 5 months ago

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 commented 5 months ago

What about DASH?

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.org content to the CG and/or WG for full integration.

afs commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

A previous request for 1.2 support was #15 which I will close as duplicate.

TallTed commented 4 months ago

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.

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.