RE: "shape" as a relationship, not a class

Is the proposition that the predicate rdf:type is fundamentally different than other predicates? 
i.e. even though class membership is indicated by a statement that looks like any other triple, it is somehow special. 
So even though a triple with my:hasShape as the predicate looks similar, it is somehow fundamentally different. 

Simon Cox

-----Original Message-----
From: Holger Knublauch [mailto:holger@topquadrant.com] 
Sent: Monday, 9 February 2015 12:40 PM
To: public-data-shapes-wg@w3.org
Subject: Re: "shape" as a relationship, not a class

On 2/9/2015 11:22, Karen Coyle wrote:
> So, with this simple example (and note that there are no classes, 
> either explicit or implicit):
>
> http://lccn.loc.gov/75300479

>    dct:title "Moby Dick" ;
>    dct:creator <http://id.loc.gov/authorities/names/n79006936> ;
>    dct:publisher "M. Kennerley" .
>
> Were you suggesting to add the relationship "hasShape" to this graph 
> like this:
>
> http://lccn.loc.gov/75300479

>    ldom:hasShape ex:bookShape ;
>    dct:title "Moby Dick" ;
>    dct:creator <http://id.loc.gov/authorities/names/n79006936> ;
>    dct:publisher "M. Kennerley" .
>
> If so, this still looks to me to be saying that my book has a 
> relationship to a set of constraints.

I would prefer to not make something like ldom:hasShape part of the standard. It could become an extension for other platforms such as OSLC, via oslc:instanceShape. Indeed it does not need to be asserted as a triple at all, and the information which shapes to use could come from the outside, e.g. from a ShExC file (that is not even RDF). IMHO the standard should only include rules on how rdf:type can be interpreted, if present, because this would be the most natural next step in the evolution of the semantic web stack. Even in the presence of rdf:type, processors may chose to ignore it, but the default interpretation should be that if rdf:type is present then the system would look for constraints defined for the class.

What I am trying to explain in this thread is that - like a "shape" - a class can serve as a set of constraints that are grouped together and organized in a subclass/extension relationship. Classes may be defined for the single purpose of serving as such a set of constraints, so that any resource (such as <http://lccn.loc.gov/75300479>) can be validated against that class. The hasShape relationship is a function that tests whether the resource fulfills the constraints defined by the class, even if it has no rdf:type triple, or even other rdf:type triples.

I cannot comment further on your example because I don't know what constraints you want to check, how you want validation to be triggered and what ex:bookShape would look like. I'd be happy to work through a complete scenario if you can provide enough details.

Holger

Received on Monday, 9 February 2015 03:47:06 UTC