Re: Property groups and Combinations

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.

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.

- 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.

- 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.

- 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.

Best regards, Jose Labra



>
>> Maybe, the other missing feature would be the addition of semantic
>> actions, which could interact with the validation process in a lot of
>> interesting ways. If the semantic actions contain SPARQL queries, then,
>> they look similar to LDOM, but allowing the semantic actions to contain
>> other kinds of languages would provide future extensibility of the
>> language, which would allow some nice applications like the examples
>> provided in Eric's demos.
>>
>
> I have intentionally chosen the name ldom:sparql to link to SPARQL query,
> because I expect future versions to have something like ldom:javascript. In
> fact TopBraid has included a SPIN extension for JavaScript-based functions
> since 2009 [1] and it's a useful thing to have if you are OK with
> increasing the cost of adoption.
>
> Holger
>
> [1] http://composing-the-semantic-web.blogspot.com.au/2009/03/
> using-javascript-to-define-sparql.html
>
>
>


-- 
Saludos, Labra