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

On 4/9/15 1:11 AM, Arnaud Le Hors wrote:
> Holger Knublauch <holger@topquadrant.com> wrote on 04/07/2015 01:59:58 AM:
>
> > ...
> >
> > I think the "core vocabulary" should remain as simple as possible while
> > addressing a good chunk of use cases. Path expressions would make it 
> too
> > hard for many tools (such as UI form builders) to make sense of SHACL
> > models.
>
> I think this is a question we will need to look into. I'm puzzled by 
> your position on this. On the one hand you're saying the core should 
> be kept as simple as possible on the other when we talked about 
> separating the core from the rest you argued that it didn't make sense 
> because the core wasn't useful enough on its own anyway.

Not sure why you keep coming back to the topic of splitting the 
documents. We just had a vote on this, and more people were in favor of 
a single document than multiple documents.

And again you quote me out of context. 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.

> From my point of view, the jury is still out on what the high level 
> functionality ought to cover.

Then we need specific proposals and vote on them. One possible outcome 
is that we define multiple built-in high-level dialects. But expecting 
something like a JavaScript-based form builder to make sense of path 
expressions is IMHO not going to fly - I have been writing such form 
builders for many years. The whole point of the core was to be simple so 
that tools can hard-code against certain basic assumptions. For complex 
cases we already have SPARQL (and macros). It is theoretically possible 
that Simon's use case is common enough, because it can be mapped to 
sliders with a min and a max value. But this doesn't necessarily require 
adding path expressions as a general core feature. Instead what we would 
need to agree on is a name for a property/macro/whatever that links a 
min property with a max property.

Holger