Re: Value type constraints

Hi!

> - sh:valueClass (or sh:valueType, for object properties)
> - sh:datatype (for datatype properties)

+1 for sh:valueType and sh:datatype

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

-0.5 to +0 using only property for both. I don't think that this is more 
user friendly than having
it seperated in two properties were both property names are actually 
pretty self-explanatory.

simon
---
DDipl.-Ing. Simon Steyskal
Institute for Information Business, WU Vienna

www: http://www.steyskal.info/  twitter: @simonsteys

Am 2015-03-27 01:02, schrieb Holger Knublauch:
> 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 06:38:07 UTC