Re: Property groups and Combinations

On 1/25/15, 6:33 PM, Jose Emilio Labra Gayo wrote:
> On Sat, Jan 24, 2015 at 12:19 PM, Holger Knublauch 
> <holger@topquadrant.com> wrote:
>
>
>     On 1/24/15, 8:36 PM, Jose Emilio Labra Gayo wrote:
>
>
>         And how would you combine it with closed shapes? Should you
>         add another SPARQL query negating all the definition?
>
>
>     Closed shapes are one very specific scenario, and whether they are
>     important enough is yet for the WG to decide. If they are as rare
>     as I believe they are, then the hack with SPARQL is sufficient
>     IMHO. If they are more common, then we can add a feature to LDOM
>     to make them more convenient. No problem.
>
>
> On the contrary, being able to declare and validate closed shapes is 
> quite important to be able to check the contents of linked data 
> portals. I think the possibility to define both open and closed shapes 
> is necessary so you can support different use cases.

I suggest we continue that topic at

https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Closed_Shapes

>
>         Anyway, it is nice to see that the LDOM is going in a
>         direction that is very close to ShEx...once you separate
>         shapes from classes and add recursive shapes, ShEx with
>         semantic actions represented in SPARQL seems almost the same
>         as LDOM, isn't it? What I am missing now is why should we need
>         a different technology if we could use and improve ShEx...
>
>
>     Jose, I am trying very hard to come up with a design that is a
>     compromise that we all feel at home with. I could make exactly the
>     same statements about SPIN. Of course there can be multiple
>     starting points, as long as we merge the best ideas together. But
>     ShEx is a largely untested language with a very short history,
>     mostly in academia. SPIN has been around for 7 years or so, and
>     has passed the test of time in large industry projects, no matter
>     how many times you repeat your personal preference to separate
>     classes and shapes.
>
>
>     The fact that the whole ShEx community is present on this WG does
>     not mean that ShEx has wide support or will be a popular technology.
>
>     We are producing a new technology, with a new name, which includes
>     lessons learned from multiple input technologies.
>
>
> Your comment didn't answer my question. Some remarks:
>
> - ShEx is a technology that was created to solve the problems that is 
> trying to solve this working group from scratch. I think it is quite 
> normal that the proposal is approaching ShEx.
>
> - SPIN is a technology that was created to solve the more general 
> problem of adding OO behaviour and business rules to classes. It adds 
> rules and constraints and thus, can be applied to solve this problem. 
> But it was not created to solve just this problem and that's why there 
> are some missing features that it needs and that you are including in 
> LDOM.

Sure, and ShEx is missing dozens of other features already covered by 
SPIN. For a start, I would encourage you to go through the User Stories 
and Requirements and check off how many are covered by ShEx. I am pretty 
sure that a neutral observer will find that SPIN was a much closer 
starting point and required less additions, so I evolved SPIN into LDOM. 
If you think such a head-to-head comparison would be useful, I don't 
mind helping on that.

>
> - You have proposed LDOM as a starting point that was based on the 
> different approaches and it was well accepted in the last meeting. I 
> also voted +1 because I think the general idea is good and because 
> both LDOM and ShEx could be complementary having ShEx as a higher 
> level profile or syntax that could be implemented in LDOM. I really 
> encourage you to continue working on this line and that's why I am 
> comparing features and trying to see what things are missing.

We need to make sure we are talking about the same things. You seem to 
above switch to the topic of ShEx as a higher level syntax. That is a 
very different topic than ShEx as a data model (and its RDF format). I 
have nothing against redefining the ShEx Compact Syntax on top of the 
core data model currently called LDOM. This could become its own 
deliverable.

>
> - Saying that the whole ShEx community is present on the WG is false 
> without specifying what you mean by ShEx community. The people that is 
> part of this WG are interested to solve this problem which is the same 
> that ShEx was trying to solve, so I think is quite natural that some 
> of the people behind ShEx are members of this WG. That's my case at least.

Understood and I appreciate having all you here. The WG however only 
represents a very small snapshot through the overall group of people who 
may be interested in this topic. We have probably one thousand users of 
TopBraid tools. Many (if not most) of them have used SPIN in one way or 
another. Even if I am just one single person in the WG, I believe you 
may want to take my input serious, because it is based on a much larger 
group of people invisible to the WG. I have no evidence that ShEx has 
been used that much, so it is pretty much based on unproven research. 
And with all respect (I have been at various research jobs long enough), 
writing a paper explaining a solution of problem X with technology Y is 
not very interesting if it didn't repeat the same exercise with 
technology Z.

>
> - When you say "we are producing new technology", I expect that you 
> are referring to TopQuadrant, not the WG. Because as far as I know, 
> the WG goal is not to produce new technology, it's goal is to produce 
> the best recommendation that can solve a given problem.

If you prefer: "Technology" = "Language".

If you want to restart the process and have the group do a straw poll 
about ShEx then please put this on the agenda for a future meeting. 
Otherwise, I am not sure what we are discussing here. Whether we start 
at ShEx to produce X or start at SPIN to produce the same X makes zero 
difference.

Regards,
Holger