Re: Value type constraints

I don’t like using a single property for constraining both literal datatypes and non-literal rdf:types. On the syntactic RDF graph level, these are very different things. So if constraint checking is performed on the syntactic RDF graph level, then different properties should be used.

I prefer sh:valueType over sh:valueClass. Because I assume all it does is check for the presence of rdf:type on the value.

On the other hand, I see the pair of names sh:valueType + sh:datatype as potentially confusing. Using “value” in one property name but not the other is misleading, as it implies a difference where none exists; both properties constrain the value. And to someone unfamiliar with RDF’s terminology, “value type” and “data type” may well sound like the same thing; or at least the names don’t point in the direction of the real distinction, which is between literal datatypes and the rdf:type property.

I see the following pair as being a little bit better:

    sh:valueType - for constraining the value’s rdf:type
    sh:valueDatatype - for constraining the value’s literal datatype

Or maybe even:

    sh:type - for constraining the value’s rdf:type
    sh:datatype - for constraining the value’s literal datatype

A novice’s reaction to either of these would be: “Uh, what’s the difference between a type and a datatype?” Which is at least the right question to ask.

Richard



> On 27 Mar 2015, at 00:02, Holger Knublauch <holger@topquadrant.com> wrote:
> 
> Could we try to agree on the high-level property names for value type restrictions? This topic is comparable to rdfs:range.
> 
> There are obviously two kinds of value types:
> a) data types (xsd:string etc)
> b) classes (ex:Person etc)
> 
> This is complicated a bit by the fact that RDF theoretically allows things like
> 
>    ex:MyInteger rdf:type xsd:integer .
> 
> I see a couple of questions now:
> 
> 1) Should we use one or two properties to specify the value type?
> 2) What should be the names of those properties?
> 
> Resource Shapes suggests two properties:
> - oslc:range (for object properties)
> - oslc:valueType (for datatype properties)
> 
> That naming sounds a bit unintuitive to me (e.g. clashed with rdfs:range), so if we had two properties then I'd prefer
> 
> - sh:valueClass (or sh:valueType, for object properties)
> - sh:datatype (for datatype properties)
> 
> 
> Alternatively we could try to get away with just a single property, say sh:valueType. The implementation of this would roughly be:
> 
> - if the ?valueType is a rdfs:Datatype, then values must be literals with equal datatype
> - otherwise, the values must be instances of the ?valueType via rdf:type
> 
> On the plus side, just having sh:valueType looks more user friendly (e.g. because people cannot use both valueClass and datatype at the same property anyway). RDFS also just has one property for such things (rdfs:range).
> 
> On the negative side, the validation needs to do a little bit of extra work to check whether the ?valueType is a datatype. Also note that this would rule out those reified datatype instances mentioned earlier, but I have not seen real-world evidence that those are needed, ever.
> 
> Properties that can take either node kind just leave the sh:valueType empty. Any of these can be combined with sh:nodeKind. We had long discussions about the interpretation of rdfs:Resource in the olden days, yet I think sh:nodeKind has helped resolve this a bit.
> 
> Could I get input on this topic? I have no strong opinions at this stage.
> 
> Thanks
> Holger
> 
>

Received on Friday, 27 March 2015 11:30:27 UTC