I’ll give some background information about the specification, essentially the 
behavior of TBC is correct, but then so would be the behavior you are expecting.

 

What the RDF specification says …

(I’ll omit chapter and verse, I can look those up if you would like them)

 

The ‘meaning’ of a literal is a value.

For example the meaning of “1”^^xsd:decimal is the number 1.

(It is not quite that simple, in that “1”^^xsd:float is also the number 1, but 
different L)

 

The meaning of the “string...@en is the pair (“String”, “en”) where “en” is to 
be understood as a language tag according to the appropriate specification.

 

The meaning of “String” is the string “String”’; the meaning of 
“String”^^xsd:string is also the string “String” – and in this case, these two 
are the same (not different).

 

 

I was in the RDF Core Working Group when we got to this situation. Basically, 
the brief was that RDF from 1999 only had strings (and language tags), and we 
needed to add on datatyping. It was felt important to have interoperability 
between xsd:string and the old-style strings, which was the rationale for 
saying that they meant the same. It was also felt important to follow the XSD 
specification in which for instance there are several different “1”s.

The discussion was very divided and took us the best part of a year, with in 
the end a difficult decision that could have gone either way.

Almost every vote split essentially 50/50.

The alternative approach, that I was supporting at the time, was probably 
worse, in hindsight … and is now, probably only of historical interest.

 

Jeremy

 

 

 

 

From: [email protected] 
[mailto:[email protected]] On Behalf Of James A Miller
Sent: Thursday, April 30, 2009 7:07 AM
To: [email protected]
Subject: [tbc-users] Another multi-lingual question

 


In TBC, when I put a language tag on a string field, in the RDF it appears as 
"String"@en.  But if I omit the language tag, I get "String"^^xsd:string.  
(i.e., the language-labeled string does not have a xsd:string clause). 

Is this intentional or a bug?  Does a reasoner infer the ^^xsd:string when 
there is a language tag?   

I have had issues with some reasoners regarding whether a string is typed or 
untyped, and I am wondering if this is causing some of the problems I have been 
seeing recently. 

Jim 
</font


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TopBraid Composer Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/topbraid-composer-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to