Re: Language or technology

On 1/27/2015 22:34, Jose Emilio Labra Gayo wrote:
>
> As far as I know, the semantics of LDOM is in natural language terms 
> nowadays. Where are the mappings from those constructs to SPARQL?

Here: https://w3c.github.io/data-shapes/data-shapes-core/ldom.ldom.ttl

> How do you handle recursive shapes in SPARQL?

Explained here: 
https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jan/0170.html


>
> Any other vendor specific syntax that appear should compete to be the 
> best...in a free market, it would be interesting to see it.

We already have vendor specific syntaxes and in our experience there is 
a strong resistance by customers to use anything that isn't 
vendor-neutral. Overcoming this (in the case of SPIN) is the main reason 
why my employer is participating in this WG.

>     We would be back to square one and end up with nothing useful at all.
>
>>         Users would not even get a way to exchange their constraints
>>         in a concrete syntax?
>>
>>
>>     We could define some concrete syntax...which as I said, could be
>>     RDF or something more human-friendly.
>     I propose LDOM for that role and skip your other abstract documents.
>
>
> I have no problem if you call the language LDOM...but whatever you 
> call it, I think it needs to have a well defined semantics which could 
> be understood without leaving everything to a full stack technology 
> that could be much more problematic.

Fully agreed. And the stack of LDOM is very minimal. Just a syntax on 
top of SPARQL with a simple execution engine. We still need to write up 
that little engine, maybe you can help?

>
>>         What use would such an "abstract" standard have? 
>>
>>
>>     As I said, it would not just be the abstract standard...we could
>>     also have some reference implementation.
>>
>>         And how does it solve the issue of trying to cast some
>>         technology into others? 
>>
>>
>>     Because there is a well defined semantics on the agreed terms
>>     that we have found, letting the controversial terms as unspecified.
>
>     LDOM will be 100% well-defined - every term has a SPARQL query
>     behind it. There is nothing controversial.
>
>
> There are several things where there are appearing some differences:
>
> - How to handle recursive definitions. In SPARQL you cannot define 
> them, so you need something extra.
>
> - How to select which nodes you are validating. I propose to leave it 
> unspecified or to have some extra definition of it. I am definitely 
> against selecting nodes for validation only by rdf:type, or attaching 
> all constraints to a class, when they don't need to be there.
>
> - there could be other differences once we start looking at the 
> details...for that, we would need a formal definition of LDOM that we 
> don't have right now.

Once I get a breather (from all those emails etc) I may have time to 
start writing the pseudo-code of the engine down. We can then discuss 
whether the pseudo-code can be further formalized into some other 
language. If anyone else wants to start, I'd be more than happy to help.

> As far as I know the requirements catalogue is still being developed. 
> Some of those things could be handled while others could not.

Which requirement from the current list cannot be handled by SPARQL 
(with the extensions suggested by LDOM)?

>
> Maybe, we would not need all the SPARQL functionality but a subset of 
> it. For example, string comparisons and arithmetic expressions could 
> be handled by the expressions that appear in the FILTER expressions of 
> SPARQL, which in fact refer to a subset of XQuery. But I suppose that 
> this could be part of another thread.

When you use XQuery why can't you use SPARQL directly? How is that 
different?



>
> But you would need other independent implementations so it could 
> become a recommendation.

I think two implementations are needed. One already exists. I am pretty 
sure someone will do another LDOM implementation in the next 1.5 years.

> I really think it is much more practical to separate an implementation 
> from a spec. That's something that has been done in most of the 
> standards and W3c recommendations and I think it is the way to proceed 
> and move forward.
>
>>     We can not reason about LDOM nor compare if some constraints
>>     expressed in LDOM are equivalent to other constraints...for
>>     example, how could you assert that one shape defined in LDOM is
>>     equivalent to another?
>
>     Which user story and requirement needs such static analysis?
>
>
> Mostly all of the user stories need to know what a shape means and how 
> one can differentiate one shape from another. I went quickly to the 
> wiki and the first story that I met was:
>
> http://www.w3.org/2014/data-shapes/wiki/User_Stories#S12:_App_Interoperability
>
> How could you warrant app interoperability if you don't have a well 
> defined semantics for the shapes?

I have no idea what you mean, sorry. Story 12 is addressed via 
structural declarations such as ldom:property that are sent back from 
the server in any RDF format to inform other applications which 
properties (and classes?) a service takes.

Overall I am not sure what problems you have with LDOM:
- it will have a formal specification
- it is fully transparent (self-defined)
- it is directly executable using SPARQL
- it is extensible
- it has an RDF syntax
- other syntaxes such as ShEx can be mapped into it

I don't understand why you think we need yet another layer in between 
LDOM and the data layer. This is SPARQL to me.

Holger