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

I believe yes, rdf:type can be regarded as a different property than 
others, e.g.

- it implements the instance-of relationship which is very fundamental
- it is very widely used already
- this relationship is well-known to people outside of RDFS/OWL
- there is special syntactic support in SPARQL/Turtle (ex:Instance a 
ex:Person)
- there is special support in JSON-LD ("@type")
- it is already used in the language itself, e.g. when you instantiate a 
constraint type

So while technically it's just another predicate - and anyone is free to 
add their own variation of it - I think rdf:type deserves a special 
place in the design of the shapes language.

Holger


On 2/9/2015 13:46, 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 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 04:01:01 UTC