W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > July 2014

Re: Shapes - sub-classes / sub-properties

From: Jose María Alvarez Rodríguez <chema.ar@gmail.com>
Date: Thu, 17 Jul 2014 11:09:24 +0200
Message-ID: <CABv_SBhz0HpDyh4wa8hS0x7758DOZkzWKVc9shR8HHpU8cZ28w@mail.gmail.com>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
Cc: Jose Emilio Labra Gayo <jelabra@gmail.com>, Simon Spero <sesuncedu@gmail.com>, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>, "public-rdf-sha." <public-rdf-shapes@w3.org>
Dear all:

I am following the last threads because it is being a very fruitful
discussion. Regarding some examples of using ShEx let me introduce two
scenarios in which we are working on:

1-SKOS validation. Although there are a good number of APIs, parsers, etc.
of SKOS-based vocabularies we have found that some of the constraints in
the recommendation cannot be easily checked. That is why as a proof of
concept we have implemented a SKOS validator [1] (it is still on-going
work) mixing ShEx, a reasoner and some SPARQL queries. The motivation of
this validator is just to know if all SKOS concepts in a scheme accomplish
with the expected shape. We are not trying to develop a complete solution
to check data quality but just to ensure that if someone is going to reuse
a SKOS vocabulary the shape of the concepts is going to be the same. For
instance we have found a problem to validate that "S13 skos:prefLabel,
skos:altLabel and skos:hiddenLabel are pairwise disjoint properties." this
means that these properties cannot have the same value. I am not sure if it
is possible to check it with SPIN, Pellet ICV or OWL restrictions but for
sure it is not possible in ShEX (actually this is a constraing in
values-content not structure) and we finally created a SPARQL query to do
that. Anyway my point here is that we only want to easily ensure and maybe
share the structure, template or shape of the concepts without entering in
other constraints or logical restrictions.

2-OSLC Resource Shapes. We are also working on OSLC and something similar
to ShEx can be found in the Resource Shapes. Building on the comment of
Jose Labra, the use of shapes can be helpful to build data-driven
applications because you will have a kind of contract between two agents
that can serve to integrate different data sources (a kind of static scheme
that you can easily map to an object or whatever).

As a final comment, from my point of view the use of ShEx (it is not easy
to write I purpose to somehow unify the use of capital letters :) ) can be
useful for the aforementioned scenarios and making a simple comparison with
the XML world (perhaps this will go in the other thread):

XML document with correct syntax->Well-formed
XML document with correct syntax and accomplishing with a DTD|XML
Schema->Well-formed and Valid

ShEx is somehow in between these two concepts, we know how to check if a
RDF graph is "well formed" (RDF syntax, etc.) and if the RDF graph is
*valid* under a certain taste RDFS, OWLx, etc. (integrity and cardinality
constraints, etc with a reasoner, SPIN, etc.). With ShEx you could check
the concept of  "well-formed"  RDF graph (structure) and also the concept
of "valid" (for instance cardinality of properties and data types),

This is just my two cents!

Excellent regards,




[1] http://vaskos.chemaar.cloudbees.net/

--
Jose María Alvarez Rodríguez
WWW: www.josemalvarez.es
Skype: josem.alvarez



On Thu, Jul 17, 2014 at 8:09 AM, Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

> On 07/16/2014 10:27 PM, Jose Emilio Labra Gayo wrote:
>
>> On Thu, Jul 17, 2014 at 7:05 AM, Peter F. Patel-Schneider
>> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>
>>     On 07/16/2014 09:39 PM, Jose Emilio Labra Gayo wrote:
>>
>>         On Thu, Jul 17, 2014 at 5:48 AM, Peter F. Patel-Schneider
>>         <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>
>>         <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>__>>
>> wrote:
>>
>>             [...]
>>
>>
>>         I think you are right and Shape checking is more low level than
>> constraint
>>         checking in general. However, I also think there are plenty of
>> practical
>>         applications where one would like to have some way to declare the
>>         shapes of
>>         RDF graphs in a easy and automatically verifiable way.
>>
>>
>>     Now we may be getting somewhere.
>>
>>     What are these practical applications that you think require shape
>> checking?
>>
>>
>> I think I already mentioned them in the previous email. They could be
>> summarized as publish and develop RDF based applications, and consume and
>> integrate data between different linked data portals.
>>
>> For example, I have found Shape Expressions are very helpful to specify
>> the
>> contents of the RDF graphs that I want to publish, so I can tell my team
>> of
>> developers that they have to produce graphs with those shapes...also, I
>> have
>> found that data portals documented with Shape Expressions can help
>> consumers
>> to know which are the shapes of the RDF graphs behind them.
>>
>
> Some specifics, and some examples would be very helpful here.  In
> particular, it looks to me as if ShEx cannot handle these use cases.
>
>
>      My canonical application for constraint checking is that I am writing
>> a
>>     program to consume RDF graphs, and I want to know that some
>> information is
>>     explicitly present in that RDF graph.  For example, I want to know
>> that
>>     each graduate student has a university explicitly given and that that
>>     university is a research university.
>>
>>
>> I think I have already done some shape expressions for that example or a
>> similar one in another thread...it can be done with shape expressions as
>> long
>> as you are interested in the shape of the RDF graphs that you retrieve...
>>
>
> I have asked how ShEx can be used for this kind of constraint checking,
> and haven't got answers.  How would you use ShEx to provide this kind of
> service?
>
>
>  Best regards, Jose Labra
>>
>>
> peter
>
>
>
Received on Thursday, 17 July 2014 09:09:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:39 UTC