Re: Language or technology

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

Great. I think the trick is to call LDOM the language that I was
proposing...so let's assume that LDOM is that language.



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

I will try.

In order to do that, we need to have a clear definition of the basis of
LDOM which would be independent of SPARQL.

I propose to identify the constructs that belong the core of the new
language from the extension mechanism that allow to write any SPARQL query
in a constraint.

The idea is to encapsulate those calls to SPARQL in a safe place so the
other language constructs can be understood by people who even don't know
SPARQL. In this way, the language will be much more simple and usable.

>From my point of view the users of this language should not be semantic web
experts with a deep knowledge of SPARQL. We should target an audience that
has some basic knowledge of RDF and wants to do useful things with it. That
people should not be exposed to the full SPARQL expressiveness when they
wanted to define those constraints.

There can be some extension mechanisms to embed external definitions for
more advanced users, but I think those mechanisms should be encapsulated
and clearly separated from the core language.

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

I didn't say to use full XQuery, I said that we could just use the same
subset of XQuery/XPath that is used by the FILTER expressions in SPARQL.
The difference is that it is used in a much more controlled place, which is
the evaluation of FILTER expressions so the core of the language can remain
being minimal, while we can reuse that part for the string operations and
so on...

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

What I mean is that in most of the user stories you need to have a well
defined semantics of the language constructs where someone (a person or a
machine) can say if they are the same or not.

If we include the full expressiveness of SPARQL inside the language, then
it will become unfeasible, while if you identify the core parts of it, it
could be done.

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

If you keep LDOM with those properties then it is mostly the language that
I was asking to have.

I think you misunderstood my point. I was not asking for another layer, I
was proposing that the solution should be a language with a core that had a
well defined semantics instead of being a full stack technology with all
the expressiveness of SPARQL embedded in it.

If you agree with that and you prefer to call that LDOM, no problem for me.
The topic of this thread is not about the name of the language, it is about
the focus of the development and the possibility to find agreements on some
things that are being discussed.

Best regards, Jose Labra

>
>
> Holger
>
>


-- 
Saludos, Labra