Search code examples
sparqlrdfowlontologyprotege

is it necessary to put 0 before the dot in RDF FLOAT type?


I am using a tool trying to generate triples.

I generate this triple:

<http://rs#Rating29728> <rs#ratesBy> ".2"^^<http://www.w3.org/2001/XMLSchema#float> .

Is .2 a correct float value, or should it be 0.2?

In order to try that, I created a literal value in Protege, put the value as 0.2. Then I closed Protege, edited the ontology manually, and changed 0.2 to .2. I opened it in Protege again, but Protege made it 0.2, so i thought that 0.2 is the correct one, not .2, and Protege already prepared for such values.

what do you think please?


Solution

  • What is a legal xsd float isn't a matter of opinion; all we have to do is check the spec.

    3.2.4 float

    float values have a lexical representation consisting of a mantissa followed, optionally, by the character "E" or "e", followed by an exponent. The exponent ·must· be an integer. The mantissa must be a decimal number. The representations for exponent and mantissa must follow the lexical rules for integer and decimal. If the "E" or "e" and the following exponent are omitted, an exponent value of 0 is assumed.

    So the question becomes whether decimal requires a leading zero.

    3.2.3 decimal

    decimal has a lexical representation consisting of a finite-length sequence of decimal digits (#x30-#x39) separated by a period as a decimal indicator.

    Now, I'd say that no leading digits is a zero length sequence of digits, which is definitely a finite length sequence of digits, so .2 would be fine. The spec also defines a canonical representation, and it sounds like protégé might normalize to it:

    The canonical representation for decimal is defined by prohibiting certain options from the Lexical representation (§3.2.3.1). Specifically, the preceding optional "+" sign is prohibited. The decimal point is required. Leading and trailing zeroes are prohibited subject to the following: there must be at least one digit to the right and to the left of the decimal point which may be a zero.

    So both .2 and 0.2 are fine, and they're equivalent, so it's OK that protégé normalizes the first as the second.