W3C home > Mailing lists > Public > public-rdf-wg@w3.org > April 2011

Re: remembering datatypes - was Re: rdf:PlainLiteral (ISSUE-12)

From: Nathan <nathan@webr3.org>
Date: Mon, 18 Apr 2011 09:50:31 +0100
Message-ID: <4DABFB57.7030005@webr3.org>
To: Dan Brickley <danbri@danbri.org>
CC: Steve Harris <steve.harris@garlik.com>, Sandro Hawke <sandro@w3.org>, Ivan Herman <ivan@w3.org>, Richard Cyganiak <richard@cyganiak.de>, Lee Feigenbaum <lee@thefigtrees.net>, antoine.zimmermann@insa-lyon.fr, public-rdf-wg <public-rdf-wg@w3.org>
Dan Brickley wrote:
> On 18 April 2011 01:25, Nathan <nathan@webr3.org> wrote:
>> Steve Harris wrote:
>>> On 2011-04-17, at 19:16, Nathan wrote:
>>>
>>>> Steve Harris wrote:
>>>>> On 2011-04-17, at 17:55, Sandro Hawke wrote:
>>>>>> Of course, this is OWL not SPARQL.   I don't see any good way to deal
>>>>>> with this in SPARQL.    I don't really understand how datatype() and
>>>>>> such are supposed to work in SPARQL -- are stores really supposed to
>>>>>> remember which values came in as xs:int vs xs:integer?
>>>>> Yes.
>>>> Out of interest, what practical difference does it make? I'm racking my
>>>> brains but struggling to think of one, other than perhaps a graph signing /
>>>> encryption case for ground graphs?
>>> Well, one matches { ?x ?y "3"^^xsd:int } and one doesn't. Both match { ?y
>>> ?y ?z . FILTER(?z = 3) }.
>> Yes, but what practical value does anybody in the world get from
>> "3"^^xsd:integer being different to "3"^^xsd:int?
>>
>> Who is the person that doesn't want the 3 if some(body/machine) somewhere
>> once said it's an xsd:int, but does want the 3 if it was said to be an
>> xsd:integer?
> 
> Anyone with tooling, workaround and schemas based on XML Schema (or
> anything with restrictions to 32 bit integers) might well be sensitive
> to such issues and want to handle these types differently.
> 
> A quick sampling of the surrounding confusion,
> 
> http://www.futureware.biz/mantis/view.php?id=386
>  "Is there any reason why all ids in the WSDL are defined as xsd:integer?
> The id fields in the database are defined as Number(10). As far as I
> understand that, that means 32bit integer.
> This would be an xsd:int
> The reason I'm asking this is, that .NET creates string properties for
> xsd:integer but int proeprties for xsd:int"
> 
> http://forums.oracle.com/forums/thread.jspa?threadID=1086586
> "[Q:] do you know what the difference is and when do you use each one?
> "[A:] http://www.w3.org/TR/xmlschema-2/#integer
> integer is the infinite set of integers.
> http://www.w3.org/TR/xmlschema-2/#int
> int is derived from integer (via long) with a max value of 2147483647
> and a minvalue of -2147483648."
> 
> http://bloggingabout.net/blogs/wellink/archive/2011/02/08/xs-int-and-xs-integer-what-s-the-difference.aspx
> "[ with screenshots ]
> xs:int and xs:integer, what's the difference....
> I am busy creating schema's and exposing them as a web service.
> I always generate a client and try to post some messages and this time
> I was again surprised by BizTalk. (or should I say XML).
> When creating a schema you can chose several types for an element.
> Some of these are xs:int and xs:integer.
> I noticed these two before but didn't bother too much.
> But now for the first time I see there is a clear difference in the
> way stuff is treated by .Net. Below is a screenshot of a node with the
> type xs:integer.
> Now after I generated the WCF service for this schema, I imported the
> WSDL into VS 2005 and I was quite surprised to see what intellisense
> did to these elements in visual studio :
>  So intellisense showed me it was actually a string !... And the other
> node of type xs:int was the .Net type I expected to see.
> So what did I learn today, to stay away from xs:integer and use xs:int instead.
> Hope this will help someone in the future, if it does, leave a comment
> 
> Hé Patrick,
> the behavior is expected as the int in XML is limited to 32-bits
> numbers while the integer in XML is unlimited in the numbers it might
> contain. So, use int when the numbers you communicate are always
> within the boundaries of 32 bits and consider integer otherwise.
> Carlo
> 
> Hi Patrick. Whoa!. I never realized this. Good to know. This is a good
> wake-up info, and keep this in mind.
> 
> @Carlo, I knew there was a diference, but i did not expect the
> xs:integer to show up in code as a string..... "
> 
> 
> ...and so on.
> 
> So to answer your question, people seem to care to make this
> distinction only when the underlying tooling cares, such as when using
> code generators.
> 
> The int 3 is small enough for the difference to rarely matter; get
> larger than (I think) http://dbpedia.org/resource/2147483647 and the
> differences emerge...
> 
> Oh, and http://www.google.com/webhp?q=2147483647+bug ...hint at a
> world of pain where software forgets about such limits; About 426,000
> results  for '2147483647 bug'.

Thanks for clarifying Dan, so the distinction matters typically behind 
the interface within tooling, where such boundaries are important (for 
example to optimize storage of numerical values, for system limitations, 
and suchlike), and sometimes this filters out in to the schemas.

I can see the difference between xsd:int and xsd:integer here very 
clearly, however I still can't see what benefit anybody gains from 
exposing these system constraints to the wild web within data, or 
requiring that a search for "3"^^xsd:integer returns different results 
to "3"^^xsd:int. Personally, this seems like dictating storage 
constraints to third parties for no good reason.

Practically then, if I encounter some RDF/XML which has a "3"^^xsd:int 
and want to convert it to Turtle, does that mean that the Turtle must 
also use "3"^^xsd:int rather than just the integer 3? If so, is this 
written anywhere? is there anyway to practically enforce it? If not and 
we accept this can easily get lost in translation, and is of no 
consequence, then why have the distinction at all?

Best,

Nathan
Received on Monday, 18 April 2011 08:51:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:41 GMT