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

That's what I'm trying to understand. 


-----Original Message-----
From: Karen Coyle [mailto:kcoyle@kcoyle.net] 
Sent: Tuesday, 10 February 2015 12:34 AM
To: public-data-shapes-wg@w3.org
Subject: Re: "shape" as a relationship, not a class



On 2/8/15 7:46 PM, Simon.Cox@csiro.au wrote:
> 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, in your last sentence, "looks similar" to ??? Are you saying that my:hasShape is fundamentally different from rdf:type or from other predicates?

kc


> 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
>
>

--
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net

m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Monday, 9 February 2015 23:12:55 UTC