s/xsd:string/plain literal/g

On Tue, Nov 22, 2005 at 07:36:28AM -0500, Eric Prud'hommeaux wrote:
> On Tue, Nov 22, 2005 at 11:45:19AM +0000, Seaborne, Andy wrote:
> This may actually present some issues in general, but example 11.2.3.8 has a
> statement ""FILTER (lang(?name) = "ES" ) )"".  Technically, "ES" will parse
> to a untyped literal and the LANG function returns a xsd:string, which will
> by the constraints of the language result in a literal compare, which will
> fail in all cases.  To be technically accurate, it should read ""FILTER
> (lang(?name) = str("ES") ) )"".
> 
> dang, he's right
> um, need to think a bit...

I've updated the prototype for LANG to return a "simple literal" [SL]
instead of a typed node with a datatype URI of xsd:string. Following
the impact on the examples, I ended up changing most of the ops to use
"simple literal". I think this reflects most of the implementations. 
Test that works with this model, but not with LC:

  [] dc:title "solitario"@ES .
  [] my:supportsLang "FR", "ES".

  ASK { ?who dc:title ?title .
        ?app my:supportsLang ?lang
        FILTER ( LANG(?title) = ?lang ) }

I'm particularly interested in feedback from implementors. Comments?
Is this what you wrote anyways?

[SL] http://www.w3.org/2001/sw/DataAccess/rq23/#operandDataTypes
-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.