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