Re: shapes-ISSUE-41 (property paths (sh:path?)): Using property paths to refer to values/types? [SHACL Spec]

I think there are complex use cases that must be supported. And I think that it is challenging to design a simple enough high level language constructs for complex use cases.

With this, there is a tension between the desire to have a 'simple high level language' and requirements for complex constraints.  However, we have an elegant extension capability which resolves the tension. We don't need to predefine all the high level constructs that would cover the variety of complex possibilities. We can be agile and cover in the prebuilt high level expressions the most obvious and straightforward things. Let other things emerge over time. 

I see this process as similar to software releases - there is always a seductive desire to try to cover more and more in the release 1. Everyone has their own favorite requirement, some simple, some harder and the release gets pushed back farther and farther . To avoid such syndrome , one must be disciplined and committed to "curbing the appetites" - get the product out there, get it used, get the feedback and move forward. To me this seems as the much preferable way forward since we already have a way to address all complex requirements.

Irene

Sent from my iPhone

> On Apr 8, 2015, at 6:02 PM, Holger Knublauch <holger@topquadrant.com> wrote:
> 
> Hi Karen,
> 
> I agree with your general sentiment. But I did not reject paths; I did suggest them as requirement myself [1,2]. Paths are already covered by SPARQL. So the only question here was whether paths should be part of the high-level language, in addition to SPARQL.
> 
> Holger
> 
> [1] https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Transitive_Traversal_of_Properties
> [2] https://www.w3.org/2014/data-shapes/wiki/Requirements#Properties_Used_in_Inverse_Direction
> 
> 
>> On 4/9/2015 7:35, Karen Coyle wrote:
>> 
>> 
>>> On 4/8/15 1:03 PM, Holger Knublauch wrote:
>>> I am against the splitting of documents if this risks a situation in
>>> which the Core gets standardized while the SPARQL bits do not get
>>> standardized. Only in that situation my point is that the SHACL core
>>> language alone would be a step backwards in the evolution of the
>>> semantic web space, because it will cause a fragmentation of the market
>>> without adding much that OWL didn't already have.
>> 
>> I think this depends on how we define core. I think of core as being the functions that will serve the highest percentage of needs - the famed 80% of uses. I don't think that means that those needs are simpler or have a simpler solution or do not use SPARQL.
>> 
>> This means that we should develop standard solutions to that 80% if we can. I prefer that we identify that core and get clarity on it before rejecting features (as in the discussion of paths) for implementation reasons. That doesn't mean that everything we would like to have as core will be provided in the standard; I just think that we musn't leap into implementation questions before we settle the "what do we want" question -- do the "what" then the "how", then iterate until we have the best possible solution.
>> 
>> kc
> 
>

Received on Thursday, 9 April 2015 00:21:59 UTC