Re: issue-95 metamodel simplifications

(Meta-comment): I feel this discussion (see Peter's parallel emails on 
this topic) is going in the wrong direction. It seems that some people 
find the metamodel complex, and therefore consider changing the language 
itself so that the metamodel becomes less complex. But the metamodel is 
barely visible to anyone - only expert users who want to create their 
own extensions ever have to worry about it. OTOH the user-facing syntax 
of SHACL is what everyone will see, and it was designed driven by use 
cases and requirements. IMHO, if these use cases and requirements cause 
a certain complexity in the metamodel, so be it. (Honestly I also don't 
find the metamodel draft complex, but that's just my opinion).

Eric, when you speak about "filters", are you referring to 
sh:filterShape or sh:constraint? If you are referring to sh:filterShape, 
where does this even show up in Proposal 3?

Holger


On 3/03/2016 9:24, Eric Prud'hommeaux wrote:
> Looking through the metamodel proposals¹, it seems that a lot of the
> complexity comes from the fact that triple constraints, inverse triple
> constraints, and filter constraints are different beasts. What are the
> use cases that motivate filters?
>
> The XML Schema WG provided only one way, a processing instruction, to
> associate XML elements with types in a schema. Years later, WSDL added
> another, associating parts of the REST I/O for some endpoint with
> types in some schema. The processing instruction seems analogous to
> the sh:classShape property connecting instances of some class to a
> given shape. The WSDL analog would fit naturally in some LDP doc.
>
>
> ¹ <https://www.w3.org/2014/data-shapes/wiki/ISSUE-95:_Metamodel_simplifications#Proposal_3>

Received on Wednesday, 2 March 2016 23:52:03 UTC