[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (OSLCCORE-134) literal_value of the oslc_where syntax is not well-defined
[ https://issues.oasis-open.org/browse/OSLCCORE-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=68524#comment-68524 ]
David Honey commented on OSLCCORE-134:
--------------------------------------
The spec simply states: "Semantics of datatypes and operations on these datatypes MUST work as defined in the SPARQL Query Language (reference: SPARQL). ".
In SPARQL:
a) A plain literal only matches a plain literal. For example "abc" is not equal to "abc"@fr. See 2.3.1 in https://www.w3.org/TR/rdf-sparql-query.
b) Integer literals such as 42 are equivalent to specifying "42"^^xsd:integer. See 2.3.2 in https://www.w3.org/TR/rdf-sparql-query. However, "42"^^xsd:integer does not match any of "42"^^xsd:int, "42"^^xsd:decimal, "42"^^xsd:long, "42"^^xsd:short and so on. OSLC supports the following numeric data types in an oslc:Property:
xsd:decimal
xsd:double
xsd:float
xsd:integer
https://www.w3.org/TR/rdf-sparql-query/#QSynLiterals shows the following equivalence:
1, which is the same as "1"^^xsd:integer
1.3, which is the same as "1.3"^^xsd:decimal
1.300, which is the same as "1.300"^^xsd:decimal
1.0e6, which is the same as "1.0e6"^^xsd:double
What this means is that a user cannot query for:
a) An xsd:float literal using any of 1, 1.3, or 1.0e6. The user would be required to specify something like "1.3"^^xsd:float.
b) An xsd:integer property using 1. That's because 1. is an xsd:decimal.
c) an xsd:integer property using "1"^^xsd:int. That's because they both have explicit RDF data types that are different.
d) an xsd:integer property with "1". That's because "1" is a plain literal.
Had the specification referenced specific literals in https://www.w3.org/TR/rdf-sparql-query/#QSynLiterals corresponding to the supported numeric property types of xsd:integer, xsd:decimal, xsd:float, and xsd:double, it would have been clearer how this should work.
Another result of this is that the interpretation of OSLC query literals is very strict. For example, a user cannot query for a xsd:integer property with 1., "1", "1"^^xsd:decimal.
Was this restrictive use of literals intended?
Or should the spec allow implementations to also accept other forms so long as they are unambigious?
For example, for an xsd:integer property of value 42, allow any of 42, "42", "42"^^xsd:int, "42"^^xsd:integer. I took this approach with GCM's OSLC query implementation.
Related to this is the syntax for URIs. The oslc.where syntax only supports <> delimited URI strings. Whereas https://www.w3.org/TR/rdf-sparql-query defines an IRIRef as either an <> delimited reference or a PrefixedName. So if we really want close adherance to SPARQL literal values, this is an omission in the spec.
I also think that a requirement to work exactly as SPARQL is unimplementable for many applications. It's not persistence agnostic enough. For example, querying for string literals and URI values using ">", ">=", "<", and "<=" can be problematic. See https://issues.oasis-open.org/browse/OSLCCORE-111, https://issues.oasis-open.org/browse/OSLCCORE-153, and https://issues.oasis-open.org/browse/OSLCCORE-158. https://www.w3.org/TR/rdf-sparql-query/#OperatorMapping defines an xsd:string comparison as follows:
A < B == op:numeric-equal(fn:compare(STR(A), STR(B)), 1)
A <= B == fn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), 1))
A > B == op:numeric-equal(fn:compare(STR(A), STR(B)), 1)
A >= B == fn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), -1))
The spec also says: "The collation for fn:compare is defined by XPath and identified by http://www.w3.org/2005/xpath-functions/collation/codepoint. This collation allows for string comparison based on code point values. Codepoint string equivalence can be tested with RDF term equivalence."
The problem is that in some cases, there is no support for testing the relative ordering. An example of that are Jazz applications using the Eclipse Modelling Framework. It's possible that some RDBs may define string collation ordering in a different way. The spec does not seem to accommodate the constraints that the underlying persistence might have and seems too SPARQL-centric to me.
> literal_value of the oslc_where syntax is not well-defined
> ----------------------------------------------------------
>
> Key: OSLCCORE-134
> URL: https://issues.oasis-open.org/browse/OSLCCORE-134
> Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
> Issue Type: Bug
> Components: Query
> Reporter: Andrii Berezovskyi
> Assignee: David Honey
>
> The spec is not clear on how to interpret the literals w/o the xsd data type.
> E.g.
> The terms boolean and decimal are short forms for typed literals. For example, true is a short form for "true"^^xsd:booleancode>, 42 is a short form for "42"^^xsd:integer and 3.14159 is a short form for "3.14159"^^xsd:decimal.
> does not specify how I am supposed to know whether 42 is an integer but 3.14 is a decimal (or a single-precision float?), let alone how I am supposed to ensure that 'true' is a boolean True, not a "true" string literal.
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]