Re: Language or technology

Jose,

I do not understand what you mean by 'language or technology'. W3C produces standards.

Could you please point out which of W3C standards have been languages and which technologies? If they all have been languages why do you think this one would be different?

As for the "LDOM" (name to be decided, LDOM should be seen as a code name) specification not being complete, it is not intended to be complete at this point. In fact, it could not be complete. It is a straw man for the group to work on.

As for the implementation for this straw man existing, how else would you check out that the specification is implementable? Reference implementations need to proceed in parallel.

Irene

Sent from my iPhone

> On Jan 27, 2015, at 7:34 AM, Jose Emilio Labra Gayo <jelabra@gmail.com> wrote:
> 
>> On Tue, Jan 27, 2015 at 7:58 AM, Holger Knublauch <holger@topquadrant.com> wrote:
>> 
>>> On 1/27/15, 4:41 PM, Jose Emilio Labra Gayo wrote:
>>> On Tue, Jan 27, 2015 at 7:26 AM, Holger Knublauch <holger@topquadrant.com> wrote:
>>>> You mean we should create something like OWL Structural Specification
>>>> 
>>>>     http://www.w3.org/TR/owl2-syntax/
>>>> 
>>>> i.e. some abstract data model only,
>>> 
>>> No, I mean we should create some structural syntax like the one for OWL accompanied with a well defined semantics as:
>>> 
>>> http://www.w3.org/TR/2012/REC-owl2-direct-semantics-20121211/
>> 
>> Such a thing already exists, it's called SPARQL. There is no need to reinvent what it means to count triples or to compute a + b. And the mapping of something like maxCardinality is already specified in LDOM itself.
> 
> As far as I know, the semantics of LDOM is in natural language terms nowadays. Where are the mappings from those constructs to SPARQL? 
> How do you handle recursive shapes in SPARQL? 
>>>> and leave all the details to individual groups outside of the               WG?
>>> 
>>> No, the individual groups should have to validate their implementations against the test cases and the semantics wedefined by the WG
>> 
>> But where is anything that end users can use here, if you end up with a number of vendor-specific syntaxes that are not standardized?
> 
> As I said, we can have the well defined RDF syntax which I think all of us agree with. 
> 
> I would also propose a more human friendly syntax like ShEx, but even if people don't like it, we could have a separate document for it.
> 
> 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 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.
> 
>>>> 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.
>  
>>>> You basically just create another layer of indirection that               all languages have to map into, while LDOM directly maps into SPARQL which is already well-established and supported by all triple stores.
>>> 
>>> We could maintain SPARQL compatibility also. We could define a mapping to SPARQL as a recommendation if you prefer.
>> 
>> Looking at the requirements catalogue (string operations, language tags, aggregations etc) it is clear that the language would actually have to be SPARQL itself. Why invent another language all over again?
> 
> As far as I know the requirements catalogue is still being developed. Some of those things could be handled while others could not. 
> 
> 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.
> 
>>>> If it just wraps SPARQL, how would it be different from LDOM?
>>> 
>>> LDOM as far as I know now has not a well defined semantics. Its semantics appears to be in natural language accompanied with *your* implementation.
>> 
>> The detailed LDOM spec will have this written up so that anyone can implement it, of course.
> 
> But you would need other independent implementations so it could become a recommendation. 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?
> 
> -- 
> Best regards, Labra