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

On 2/8/15 5:40 PM, Holger Knublauch wrote:
> 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.

OK, this is quite a bit clearer. I'm still not sure how a relationship 
is a function, but I'll leave that to the implementation step.

I understand how classes create a neat "hook" for validation routines. 
However, I'm still not comfortable with the emphasis on classes as units 
of validation because I would prefer that we not encourage folks to 
treat classes in RDF as if they were classes in OO. It may well be that 
for validation we need something that approximates the OO class concept, 
but, like the overloading of OWL for validation, I consider a similar 
overloading of rdf:type to be a dangerous step.

kc

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


-- 
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 21:13:50 UTC