W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > January 2015

Re: Shapes vs Classes (in LDOM)

From: Jose Emilio Labra Gayo <jelabra@gmail.com>
Date: Sat, 24 Jan 2015 08:33:21 +0100
Message-ID: <CAJadXX+U3ELrCxnnbgg=MVQYYDwrp=XKzdsW60MwGQgyZEwmqg@mail.gmail.com>
To: Holger Knublauch <holger@topquadrant.com>
Cc: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
On Sat, Jan 24, 2015 at 8:19 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> On 1/24/15, 5:04 PM, Jose Emilio Labra Gayo wrote:
>
>> A real life example is the use case that I proposed in another email
>> which is the development of statistical data portals for different clients.
>> You share a common model which is the RDF Data Cube vocabulary, but you
>> also inherit other properties specific to those portals.
>>
>> Your task is to generate two different linked data portals for those
>> clients that share a common model but have different shapes for the nodes.
>>
>
> If they have different properties, then the traditional solution is to
> create two different subclasses that inherit the shared properties from a
> base class. Why would this not work? Sounds much cleaner than having some
> "magic" that figures out which constraints to use under which context.
>
> It would help to have specific instances and class definitions, to make
> sure we talk about the same problems. Can you provide some?
>

The real life example I had in mind was the user case the I proposed
yesterday which is documented in [1]. The documentation of the two linked
data portals using ShEx was provided here in [2] and [3].

In that case, I did the data model and I added rdf types, but I there may
be plenty of situations and other models where one would not need to add
those rdf:type declarations and it would not mean that they are not right.

Notice that although the shapes of qb:Observation's in both portals look
quite similar (the data model is in fact very similar and was made by the
same person), in practice it should not necessarily be the case. For
example, the property used to associate time to observations varied from
one portal to the other.

But as I was trying to explain in my previous message, the story doesn't
finnish here. The main reason to both linked data portals is that the data
they contain can be reused by other agents. In that case, there could be
other agents that could automatically look at the shape descriptions and
provide visualizations of the observations. The problem is not solved by a
simple RDF merging tool and a generic browser...in this case, knowing that
we are talking about statistical observations, those agents could do a much
better work.


[1] [1] Validating and Describing Linked Data Portals using RDF Shape
Expressions, Jose Emilio Labra Gayo, Eric Prud'hommeaux, Harold Solbrig,
1st Workshop on Linked Data Quality, Sept. 2014, Leipzig, Germany
PDF: http://labra.github.io/ShExcala/papers/ldq2014.pdf
Slides: http://www.slideshare.net/jelabra/linked-dataquality-2014

[2] http://weso.github.io/wiDoc/
[3] http://weso.github.io/landportalDoc/data/




> Thanks,
> Holger
>
>
>


-- 
Saludos, Labra
Received on Saturday, 24 January 2015 07:34:10 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 24 January 2015 07:34:11 UTC