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

On Mon, Mar 30, 2015 at 11:29 AM, Richard Cyganiak <richard@cyganiak.de>
wrote:

>
> > On 30 Mar 2015, at 00:11, Holger Knublauch <holger@topquadrant.com>
> wrote:
> >
> > We agree that the mapping between named variables such as "message" and
> corresponding property IRIs in the SHACL namespace (sh:message) is trivial.
> Yet I would turn your arguments around. By defining an RDF data model we
> get a lot of stuff for free without any extra work, including several
> exchange formats. For example if we leave the details unspecified, how
> would implementers know how to serialize the values - whether something is
> a IRI or a literal?
>
> My proposed constraint violation data structure is isomorphic to SPARQL
> SELECT results, therefore it comes with several serialization formats for
> free.
>

Richard,

I am still trying to understand your exact proposal. SPARQL SELECT returns
results in RDF or in CSV/TSV/XML/JSON.
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?

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