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

Karen,

It is called a property function (or magic property) because the
relationship is always computed. This is analogous to database views. I
don't care for the name that much myself, but what it is called doesn't
really matter.

I don't believe adding constraints to classes creates any conflict between
RDF and OO since it simply says that these constraints apply to members of
this class. Classes are used as a way to partition the data. This is true
for RDF and OO. How would it be a conflict?

When people don't want to use classes/types at all, as in your examples,
they don't have to. They would need to use some other ways of telling a
constraint validation engine "check this data against this set of
constraints". It may be best to keep these other options open for such
cases and leave them to the implementation details.

Irene

On Mon, Feb 9, 2015 at 4:13 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:

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