Re: Shapes vs Classes (in LDOM)

On 1/24/15, 4:49 PM, Jose Emilio Labra Gayo wrote:
> On Sat, Jan 24, 2015 at 7:29 AM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>
>     On 1/24/15, 4:03 PM, Jose Emilio Labra Gayo wrote:
>
>         Also, although it was not the case in my example, there could
>         be other examples where you even don't define the type of the
>         nodes. Some times when you are modeling linked data portals
>         that extract data from relational databases or excel sheets,
>         you extract values from tables and link properties to them.
>         You could assign those generated nodes an rdf:type, but it
>         should not be mandatory. And this is or will be a very common
>         use case for linked data applications.
>
>
>     If there is no rdf:type, which other information is used to
>     determine what shape an instance is supposed to have? We need to
>     clarify the starting points of constraint evaluation.
>
>
> Yes, but that's a different issue and that's why we have a requirement 
> about how to select the nodes that you are validating.

Then we need to work on this requirement with high priority. How is this 
solved in ShEx? The rdf:type is a natural starting point for validation, 
that is very likely to be present - what else are all the published data 
models and ontologies (with class definitions) about?

The case to not have rdf:type triples is in our experience the 
exception, and we should not build a whole language around corner cases. 
The language should make the common use cases easy, not force classes 
and their properties to hang off from different URIs.

Holger

>
> In my opinion, not forcing shapes to be related with classes offers a 
> better separation of concerns. And of course, we can also maintain a 
> special case where shapes are associated with classes.
>
>
>
>
>     Holger
>
>
>
>
>
> -- 
> Saludos, Labra