Re: sh:equal, sh:hasValue, sh:in: identity (sameTerm) vs equality

On 18/05/2022 00:32, Holger Knublauch wrote:
....
 > One way to evolve your use cases could be to introduce an optional
 > boolean flag such as sh:matchEquality true which could be a second
 > argument to sh:equals, sh:hasValue and sh:in. Another way would be (as
 > you say) to introduce completely new constraint components.

Another option ("as well as", not "instead of") is to describe a 
validation mode.

It would also cover the case where the data were to be canonicalized as 
some triplestores already do.

 >
 > Maybe this should become a GitHub issue so that a SHACL 1.1 WG can pick
 > this up?
...

> PS: Given the increasing interest in SHACL, I guess once a 1.1 WG is 
> created, many people will suggest new features and improvements. All it 
> needs is a couple of dedicated individuals to drive the process and 
> build a functioning WG.

Nowadays, the way forward is for the CG to start working on material to 
show community active contribution. A CG final report, or reports, would 
be input to a WG.  It shows that there will be active participation, as 
well as community interest (in other people doing work :-)

For SHACL, the WG can be of a relatively short duration - I think the 
active-CG phase would surface the vast majority of the mature, 
considered options. That should also cover implementations of the CG 
outputs.

See the CG as the old-style WG steps of UCR phase + initial proposals.

     Andy

Received on Wednesday, 18 May 2022 07:54:43 UTC