Re: Property groups and Combinations

Jose,

Much could be said about differences between applications whose main reason for being is to enable mission critical business processes and applications whose main reason for being is to promote and demonstrate new visionary concepts such as linked data portals.

One of the key differences is in the maturity of requirements. In the former applications, requirements and, importantly, their relative importance are much better understood because they support very concrete business uses cases that have well known value. It is easy to determine what is a "must have" and will be commonly used and what is more of a "comer case" or optional. In the case of the latter applications, requirements and their relative importance are much more hypothetical because the value and the use cases are still to be proven and a lot remains to be understood.

Given the differences in maturity of the requirements, I believe it would be a mistake to treat them the same way.

Having said this, I think this whole discussion is taking us backwards. You have, as you pointed several times, voted for using LDOM as the basis of the standard this group will deliver. This was great as it moved us forward. 

Some may argue that SPIN is just a "TopQuadrant" thing. LDOM is not. Unlike SPIN, ShEx, Resource Shapes, etc. it was developed as part of this working group. It was developed in the context of the close detailed discussion within the group and in response to requirements produced by the group. 

What could be accomplished right now by asking a question 'why shouldn't we use ShEx as a starting point instead' other than taking us backwards to the discussions that already took place?

Can we please continue to move forward instead of going back to rehashing past arguments?

Irene 

> On Jan 25, 2015, at 11:07 AM, Jose Emilio Labra Gayo <jelabra@gmail.com> wrote:
> 
>> On Sun, Jan 25, 2015 at 10:11 AM, Holger Knublauch <holger@topquadrant.com> wrote:
>> 
>>> 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
> 
> OK 
>>>>> 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.
> 
> Up until now, probably most (if not all) the use cases and requirements can be covered by ShEx, but at this moment, we are precisely in the process of defining those use cases and requirements, so it does not make any sense to start any confrontation between SPIN and ShEx when what we should do nw is to see which use cases and requirements are finally going to be considered. 
> 
> And really, from my point of view, SPIN (or LDOM) and ShEx should not be confronted when they could be complementary. It would be much more fruitful if we concentrated our efforts on the problem we want to solve (the use cases and requirements) and the features that the future solution should have.
>>> - 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.
> 
> OK. I think that would be really useful.  
>>> - 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.
> 
> You are claiming that ShEx is an academic project which is really false given that it was initially designed by Eric Prud'hommeaux from W3c inspired by RelaxNG and the industry needs. Later on, some other people like me found that the ideas behind it were interesting and we did some research on it. But the initial design was motivated by the industrial needs that were expressed in the RDF Validation workshop.
> 
> Even if it were originally designed as a pure research project (which it wasn't), would it mean something bad at all? Should not we concentrate on its merits as a proposal rather than if it was designed as a research project? Should we reject anything that comes from research projects only because of that?
> 
> You also argument that SPIN was designed 7 years ago, and what? I think we should concentrate on what is the best solution to solve a given problem, rather than constantly checking if some technology that I have fits or not in a solution.  
> 
> With regards to the research papers, they described what Shape Expressions are and how they could be used to describe and validate linked data portals. They didn't pretend to compare technologies. We are currently working on a future paper were we could compare different technologies but that's work in progress...
> 
> With regards to your experience, I don't know why you have to remark that we should take it serious. Of course, we (at least me) are taking your experience seriously, and it is very important to have companies involved in this process. But I would also ask you the same respect for other opinions. Although I work at a University and published some papers on ShEx, I have founded the WESO group where we apply semantic technologies to solve real life problems. In that context, I employed ShEx in the development of two linked data portals. Those projects were in fact no research projects at all.
>>> - 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".
> 
> I think we should not mix those two concepts, because maybe that's another important difference between us. You are probably concentrated on a technology, while I am more interested in a language. I mean, SPIN is probably a full stack technology, while ShEx is a schema definition language that can be used to define the shapes of RDF graphs which can later be validated.
> 
> One nice thing of ShEx as a single language is its flexibility, which means that it can be implemented using different systems (by now, we can implement it javascript and scala but it could also be implemented using SPARQL queries, OWL or even SPIN/LDOM), it can also be defined using different syntaxes (ShExC, RDF, etc.), it can be easily extended with semantic actions and it also separates validation from node selection which allows to define different policies for that task.
> 
>> 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.
> 
> It is not necessary to do that given that ShEx has already been accepted as one of the alternatives. 
> 
> I am not sure if you misunderstood the results of last meeting poll. They don't mean that the WG will use LDOM as the only technology, they mean that LDOM can be considered as a good starting point. I voted +1 in that sense, because I want to encourage that line of cooperative work that you started trying to combine the best of the different alternatives. 
> 
> Best regards, Jose Labra
> 
>> 
>> Regards,
>> Holger
> 
> 
> 
> -- 
> Saludos, Labra