Re: Reopening the discussion on sh:targetShape

What is your preference on how to record and expose the targetShape 
feature for other potential implementers? It could be the start of a new 
"Suggested features" document, or each feature could become its own 
little document, or it could be a GitHub issue...

On the general topic, yes, an incremental process would be good. We do 
have many potential additions to a SHACL 1.1, including many features 
currently in SHACL-AF or in the dash namespace. From experience, going 
through such a formal process is extremely difficult and needs a lot of 
patience, so I assume it would only be tackled if there are strong 
reasons for why SHACL 1.0 isn't good enough anymore. As an example, we 
are seeing a lot of use cases and customer interest in inferences (e.g. 
sh:values and sh:rule), yet the data shapes WG wasn't chartered to work 
on rules so it didn't go into the main deliverable. If a SHACL 1.1 group 
ever happens, I would strongly push for a charter that includes rules. 
But then, once this gets exposed to the wider audience, there could 
potentially be resistance from, say, RIF people who may state that rules 
are already standardized. There are politics involved here, and you'll 
end up with something very different from what you originally wanted.

I treat SHACL-AF as a "living" standard that evolves dynamically as soon 
as a large-enough group of people is fine with changes. This avoids all 
these complications. But it does require that people do agree, and that 
wasn't the case for this feature yet. This doesn't mean that I don't 
acknowledge your use case or don't appreciate your efforts here.

Holger


On 10/07/2020 18:28, Håvard Ottestad wrote:
> Hi,
>
> The javascript language has a nice phased system where you can 
> contribute your own extensions to the language into the core as long 
> as it goes through a set of phases.
>
> For SHACL we could have:
>
>  - phase 0: formal spec with definition and example
>  - phase 1: proof of concept implementation
>  - phase 2: full implementation
>  - phase 3: two or more competing implementations
>
> And maybe more phases or something official at the end.
>
> This would essentially be creating a new standardisation process, but 
> the benefit would be that everything would essentially get accepted in 
> phase 0 and there would be very clear rules for moving up the ladder.
>
> Things could probably end up in the actual W3C recommendation at some 
> point, but that process is a lot bigger (and costlier).
>
> Then again we are a very small community in contrast to the JavaScript 
> community and they probably have a lot more resources to run this.
>
> I’m very grateful that we in particular have Holger and Irene to help 
> answer questions, review proposals and even go as far as to implement 
> them.
>
> Håvard
>
>> On 10 Jul 2020, at 01:40, Holger Knublauch <holger@topquadrant.com> 
>> wrote:
>>
>> 
>>
>> Yes quite possibly we should have a document similar to SHACL-AF but 
>> for proposed features? Or is keeping PRs open sufficient?
>>
>> In general I think if there is wide agreement on features then they 
>> could directly go into SHACL-AF, as that is an evolving draft towards 
>> a possible 1.1 release. Then I think it's also OK to use the sh: 
>> namespace.
>>
>> Holger
>>
>>
>> On 10/07/2020 06:25, Roman Evstifeev wrote:
>>> I wonder if it would be more appropriate to create something like 
>>> shacl-cg org on GitHub to have a namespace 
>>> https://github.com/shacl-cg/ ?
>>>
>>> On Thu, Jul 9, 2020, 22:50 Vladimir Alexiev 
>>> <vladimir.alexiev@ontotext.com 
>>> <mailto:vladimir.alexiev@ontotext.com>> wrote:
>>>
>>>     Havard and I are thinking of putting this in an rdf4j namespace.
>>>
>>>     Cheers!
>>>