Value type constraints

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 00:03:54 UTC