[oslc-core] olsc properties - "integer" value-type?

Fri Apr 9 16:36:10 EDT 2010

How would one use the current types to define that a property's type is 
"open" or in XML terms "any"?

For example, in CM we may have a well-defined property on a ChangeRequest 
called 'priority', though we don't want to constraint the type but allow 
it to be determined by each provider's specific resource shape definition. 
 Some systems it may be a String, some it may be a Complex value.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

> From: Arthur Ryman <ryman at ca.ibm.com>
> To: James Conallen/Philadelphia/IBM at IBMUS
> Cc: oslc-core at open-services.net, oslc-core-bounces at open-services.net
> Date: 04/08/2010 02:46 PM
> Subject: Re: [oslc-core] olsc properties - "integer" value-type?
> Sent by: oslc-core-bounces at open-services.net
> 
> James,
> 
> I agree in principle, however there are a lot of XSD datatypes and they 
> are sometimes merely variants of each other, e.g. is the value 
> "42"^^xsd:int really the same concept as "42"^^xsd:integer or 
> "42"^^xsd:positiveInteger? They all map to the same element of the 
numeric 
> value space. How does this affect comparisons in queries? I think we'd 
> have to write queries that pulled out the untyped part to do 
comparisons, 
> e.g. in SPARQL using the STR function.
> 
> 1. RDF distinguishes plain literals from typed literals. Plain literal 
are 
> simple character strings, whereas typed literals have the ^^<datatype> 
> suffix. Technically, we should then use the rdf:datatype attribute in 
all 
> property elements that have typed literal values. We haven't given any 
> OSLC guidance on when to use typed literals versus plain literals. If we 

> use typed literals and all the XSD datatypes, this makes writing queries 

> more complex since we have to get the datatypes right too.
> 
> 2. Not all XSD datatypes are suitable for use in RDF, e.g. xsd:QName. 
The 
> set of suitable datatypes is given in [1]
> 
> 3. For URI literals, we should use xsd:anyURI unless there is a subtle 
> distinction, not invent the new URI 
> http://open-service.net/xmlns/oslc-core/literal-types#URI 
> 
> 4. For XML literals we should use rdf:XMLLiteral, not invent a new URI 
> http://open-service.net/xmlns/oslc-core/literal-types#XMLLiteral 
> 
> [1] http://www.w3.org/TR/rdf-mt/#DTYPEINTERP
> 
> Regards, 
> 
___________________________________________________________________________ 

> 
> Arthur Ryman, PhD, DE
> 
> 
> Chief Architect, Project and Portfolio Management
> 
> IBM Software, Rational
> 
> Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
> Twitter | Facebook | YouTube
> 
> 
> 
> 
> 
> 
> 
> From:
> James Conallen <jconallen at us.ibm.com>
> To:
> Scott Bosworth <bosworth at us.ibm.com>
> Cc:
> oslc-core at open-services.net, oslc-core-bounces at open-services.net
> Date:
> 04/08/2010 12:51 PM
> Subject:
> Re: [oslc-core] olsc properties - "integer" value-type?
> Sent by:
> oslc-core-bounces at open-services.net
> 
> 
> 
> I always feel uneasy about limiting something like data types in a 
context 
> where we are defining a common specification for domains and use cases 
> that we haven't even defined yet.
> 
> Rather, I'd like to say that we can support any XML Schema defined data 
> type in a RDF document.
> 
> For example in queries this would mean that we can optionally qualify 
> values with the type ( i.e. 
> oslc.where=dc:created>"2010-04-07T19:57:05.375Z"^^xsd:dateTime ).
> 
> 
> BTW: I see the following in the current draft of the core:
> oslc:valueType (URI, exactly-one) - may be any of the value types listed 

> above in OSLC Defined Resources, in URI form: 
> Literal value-types 
> String - http://www.w3.org/2001/XMLSchema#string 
> Integer - http://www.w3.org/2001/XMLSchema#int 
> Decimal - http://www.w3.org/2001/XMLSchema#decimal 
> Float - http://www.w3.org/2001/XMLSchema#float 
> Double - http://www.w3.org/2001/XMLSchema#double 
> Boolean - http://www.w3.org/2001/XMLSchema#boolean 
> DateTime - http://www.w3.org/2001/XMLSchema#dateTime 
> URI - http://open-service.net/xmlns/oslc-core/literal-types#URI 
> XMLLiteral - 
> http://open-service.net/xmlns/oslc-core/literal-types#XMLLiteral 
> Resource value-types 
> Resource - 
http://open-service.net/xmlns/oslc-core/resource-types#Resource 
> 
> In-Line - http://open-service.net/xmlns/oslc-core/resource-types#InLine 
> Complex - http://open-service.net/xmlns/oslc-core/resource-types#Complex 

> 
> <jim/>
> 
> jim conallen
> jconallen at us.ibm.com
> Rational Software, IBM Software Group
> 
> 
> 
> Scott Bosworth---04/08/2010 11:32:40 AM---Dave, did we conclude 
yesterday 
> that "integer" should be included in the list of literal value-types
> 
> 
> From:
> 
> Scott Bosworth/Raleigh/IBM at IBMUS
> 
> To:
> 
> oslc-core at open-services.net
> 
> Date:
> 
> 04/08/2010 11:32 AM
> 
> Subject:
> 
> [oslc-core] olsc properties - "integer" value-type?
> 
> Sent by:
> 
> oslc-core-bounces at open-services.net
> 
> 
> 
> Dave, did we conclude yesterday that "integer" should be included in the 

> list of literal value-types in defining oslc properties? and in the 
> resource shape section as well? 
> 
> Should I log an issue for this?
> 
> Thanks....Scott
> 
> 
> 
> Scott Bosworth | IBM Rational CTO Team | bosworth at us.ibm.com | 
> 919.486.2197(w) | 919.244.3387(m) | 919.254.5271(f)
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> 
> 
> 
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100409/d3dac72d/attachment-0003.html>