Re: replacement for datatype restriction

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/12/2015 12:35 PM, Eric Prud'hommeaux wrote:
> * Peter F. Patel-Schneider <Peter.Patel-Schneider@nuance.com> [2015-02-12
> 12:13-0800]
>> The current version reads:
>> 
>> Property Datatype
>> 
>> The values of a property may be limited to be an RDF Literal with a
>> stated datatype, such as xsd:string or xsd:date.
>> 
>> The earlier version read:
>> 
>> Property Values belonging to Datatype
>> 
>> The values of a property on instances of a class may be limited by
>> their datatype, such as xsd:string or xsd:date.
>> 
>> 
>> The current version is quite explicit that a restriction stating
>> xsd:integer will not be satisfied by an RDF Literal like "1"^^xsd:int,
>> even though the meaning of this literal is an element of xsd:integer.
>> The earlier version was less explicit, although it appears that the
>> restriction would be satisfied in the above situation.  (The earlier
>> version also talked about instances of a class, but that's irrelevant
>> to the discussion here.)
>> 
>> 
>> I propose to split this into two requirements:
>> 
>> Property Datatype
>> 
>> The objects of a property may be limited to be an RDF Literal with a
>> stated datatype, such as xsd:string or xsd:date.  The RDF Literal
>> "1"^^xsd:int would not satisfy a limitation to xsd:integer.
>> 
>> 
>> Property Data Values
>> 
>> The objects of a property may be limited to be an RDF Literal whose
>> value belongs to a stated datatype, such as xsd:string or xsd:date.
>> The RDF Literal "1"^^xsd:int would satisfy a limitation to
>> xsd:integer.
> 
> +1 to the the split, and my votes are +1 and 0 respectively.

Presumably there will be some indication of when the Wiki page can be changed.

>> peter
>> 
>> 
>> PS:  A similar issue affects Property Value Enumerations.  For example,
>> is "01"^^xsd:integer valid when the enumeration is { "01"^^xsd:int }?
>> What about for { "1"^^xsd:integer }?
> 
> Does it make sense for this to be parallel?

Maybe. There are actually four possibilities here so the situation is not
quite parallel.

If the working group includes the ability to dereference IRIs then there is
also going to be the issue of how to treat two different IRIs that
dereference to the same resource.

peter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU3RCnAAoJECjN6+QThfjzP2YIAJK3Zhnx3sY7xYq9U0auL7wZ
2w4oBvdiN5Nlj+YUZAv6Np+HRK05x+HP192HEvSdlK6nNYM0TRJQEDJ+q0tmtDO+
SK0cRUsKSIytJcKdEJAqQ+tDIfFg6qJ9BwjJLkFgxlfWa/fYp4RTCuS/xVDK999G
LAEkxIS/UcQuJrNJo0UylyYr2pKz0pBGa9i1fExa2Jmy0vKfaNIpb+ctWuXghngP
+z2WaJf37WcWK0OodDp1GIlwiWNp9BvhFd3hRdgzD86e0Z05t/B3eML1MSEu5ay1
9oQgaj+tv53rbH9YvOmdhHXY/Iba30bQUITUT4Sl/oyPPlXpsOuhB5pk+d/k9f4=
=p3er
-----END PGP SIGNATURE-----

Received on Thursday, 12 February 2015 20:44:56 UTC