Re: Ditching the Constraint Violation Vocabulary (was: Re: Anyone in support of CONSTRUCT constraints?)

I understand now, I had the impression you were referring to a concrete
serialization (and although it's not a W3C rec some vendors do return
results in RDF).

We could defining something abstract but this specific data structure is
quite limiting.
I would rather to return an RDF graph based on a limited vocabulary that
people can extend than a fixed structure that can hardly change.

Best,
Dimitris

On Mon, Mar 30, 2015 at 11:07 PM, Richard Cyganiak <richard@cyganiak.de>
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
>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org
Homepage:http://aksw.org/DimitrisKontokostas