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

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 Wednesday, 8 April 2015 22:03:40 UTC