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

* Nathan <> [2011-04-18 09:50+0100]
> Dan Brickley wrote:
> >On 18 April 2011 01:25, Nathan <> 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,
> >
> >
> > "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"
> >
> >
> >"[Q:] do you know what the difference is and when do you use each one?
> >"[A:]
> >integer is the infinite set of integers.
> >
> >int is derived from integer (via long) with a max value of 2147483647
> >and a minvalue of -2147483648."
> >
> >
> >"[ 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) and the
> >differences emerge...
> >
> >Oh, and ...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?

If "converting it to Turtle" is intended to maintain graph
equivalence, I think implementor has no choice about preserving
the datatype. You could propose some text for
but I'm not sure it's worth the extra bulk.

> Best,
> Nathan


Received on Monday, 18 April 2011 13:26:40 UTC