Re: Ditching the Constraint Violation Vocabulary

Richard, the WG has a specific need to serialize and compare constraint 
violations as part of the Test Case library. How would you represent 
those expected values?

Also, if you have a tabular data structure similar to SPARQL bindings, 
how would you handle properties that may have multiple values such as 
sh:message (in multiple languages) and sh:detail (which should be useful 
for sh:valueShape)?

Finally, I'd welcome other opinions.

Thanks,
Holger


On 3/31/2015 6:07, Richard Cyganiak wrote:
>> On 30 Mar 2015, at 14:38, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> wrote:
>>
>> I am still trying to understand your exact proposal. SPARQL SELECT returns results in RDF or in CSV/TSV/XML/JSON.
> No, it doesn’t.
>
> SPARQL SELECT returns an abstract data structured called a solution sequence [1]. A solution sequence is an ordered list of bindings. A binding is a partial function from SPARQL-style variable names to RDF terms. That is how the SPARQL query language is defined. It defines how to evaluate a SPARQL query string over an RDF dataset into a solution sequence.
>
> What SPARQL implementations do with a solution sequence is not specified by the SPARQL specification, and out of scope of the SPARQL specification.
>
> Besides the SPARQL query language, the SPARQL working group also specified some serialisation syntaxes for solutions sequences, and a protocol for sending queries and serialised solution sequences back and forth. It is common for SPARQL implementations to support these. Also common is direct access to the data structure via a programming language API. But all of these things are independent from the SPARQL query language specification, and one doesn’t need to do any of them to have a conformant SPARQL implementation.
>
> (Your statement that “SPARQL SELECT returns results in RDF” is just plain wrong.)
>
>> Since you say "isomorphic" you probably don't propose to use the exact recommendations since it would further increase the implementation complexity to support all formats.
>>
>> If you meant something similar to the RDF results, I don't see any substantial difference between your proposal and Holger's. If we of course exclude the additional annotations, the only possible difference would be a result container structure.
>> Possibly you didn't refer to XML for obvious reasons which then leaves us to a CSV/TSV or JSON format and I assumed the former in my previous mail
>> Could you please provide an quick example of your proposal?
> I assume you understand the difference between an abstract data structure (such as RDF graphs or SPARQL SELECT results or the DOM) and a serialisation format for a data structure (such as Turtle or the SPARQL Query Results JSON Format or XML).
>
> My proposal is that the result of SHACL evaluation, as specified in the spec, should be an abstract data structure. That data structure should be isomorphic to SPARQL's solution sequence data structure, and perhaps might even be identical to it, although we might want to call it something else to avoid confusion about the term “solution” and to avoid allegations of hidden SPARQL dependencies.
>
> The SHACL spec should also define a way of turning that data structure into human-readable messages.
>
> Beyond that, implementations might want to do various other things with this data structure: provide direct API access, turn it into RDF using something like SPARQL CONSTRUCT templates, serialise it into any number of formats, aggregate it to provide higher-level reports, and so on. But it is my view that all none of these things need to be covered in the SHACL spec.
>
> Best,
> Richard
>
> [1] http://www.w3.org/TR/sparql11-query/#solutionModifiers
>
>
>> Best,
>> Dimtiris
>>   
>>
>>> I believe there is value in having a serialization format, and there will be value in being able to run SPARQL queries across the results of constraint validation.
>> There is value in many things, but it doesn’t follow that this working group should be doing those things. This working group should focus on its charter and on the user stories. I don’t see those as requiring the ability to run SPARQL queries across validation reports. Clearly there are some cases where this ability might be useful, but I see those as fringe, and as an area where implementors can differentiate themselves by going beyond what’s mandated by the standard.
>>
>>> And you haven't shown how to represent path expressions yet.
>> That’s shouldn’t be an obstacle to evaluating the proposal.
>>
>> Best,
>> Richard
>>
>>
>>
>>
>> -- 
>> Dimitris Kontokostas
>> Department of Computer Science, University of Leipzig
>> Research Group: http://aksw.org
>> Homepage:http://aksw.org/DimitrisKontokostas

Received on Monday, 30 March 2015 22:40:21 UTC