[OASIS Issue Tracker] (OSLCCORE-170) Core 3.0 Literal Value Types are closed

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCORE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=69944#comment-69944 ] 

David Honey commented on OSLCCORE-170:
--------------------------------------

Does anyone involved with OSLC 1.0 or 2.0 remember the reason for such a small set of supported types?

Most server implementations based on RDBMs will implement integers as 32 bit, and hence xsd:int would be a more accurate literal type for integer properties. However, the spec currently only allows xsd:integer and doesn't allow the property to define any constraints on values. xsd:integer tends to get mapped to Java BigDecimal rather than int or Integer.

So why not support more or all of the standard xsd datatypes?

Since RDF supports a wide range of type literals, and existing applications may use data of a wide range of types, this could be seen as an impediment to OSLC adoption.

In Ian's example, one might represent a duration as an integer number of milliseconds and use xsd:integer. However, one cannot infer the units from the type or property definition, other than relying on human-readable descriptions. Whereas xsd:duration has well-defined representations and semantic and is therefore a more useful RDF representation.

If we do decide to expand the range of supported literal types, this will impact the OSLC query specification that defines how literal values in query expression should or may be interpreted.

> Core 3.0 Literal Value Types are closed
> ---------------------------------------
>
>                 Key: OSLCCORE-170
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-170
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: New Feature
>          Components: Core
>            Reporter: ian green
>            Assignee: James Amsden
>            Priority: Minor
>
> Core 3.0 specifies a closed set of data types for literals [1]. 
> Is there any advice/suggestion on how an implementation should deal with resources and their shapes when other data types are involved?   
> For example, I work on an application that uses xsd:duration internally, and currently the OSLC representations of that type is identical and hence non-compliant.  We could (i) live with this non-compliance, (ii) refrain from exposing resources of such types on the OSLC API, or (iii) pick some other data type that is supported and map values into that supported type.  For (iii) xsd:string comes to mind. 
> What is the preferred approach? 
> [1] http://docs.oasis-open.org/oslc-core/oslc-core/v3.0/cs01/part6-resource-shape/oslc-core-v3.0-cs01-part6-resource-shape.html#property-shape, "Literal Value Types" 
> Suggestion: Core 3.0 data types should be open, or at least more generous that the current small set.
> Core 2.0 suffers the same issue; guidance on how a core 2.0 implementation should deal with unsupported types would be useful.



--
This message was sent by Atlassian JIRA
(v7.7.2#77003)