[rq23 edits] Re: better names for r:IRI and r:Literal

On Mon, Aug 22, 2005 at 01:18:58PM -0500, Dan Connolly wrote:
> 
> On Aug 22, 2005, at 8:20 AM, Eric Prud'hommeaux wrote:
> >SPARQL Query Operand Data Types refers to some mythic datatypes r:IRI
> >and r:Literal. I would like to change them to rdfs:Resource
> >  <http://www.w3.org/TR/2004/REC-rdf-schema-20040210/#ch_resource>
> 
> er... changing IRI to Resource is a use/mention switch, no?
> 
> an IRI is a Term, right?
> 
> I suggest xsd:anyURI .
> 
> http://www.w3.org/2001/XMLSchema#anyURI
> 
> documented in http://www.w3.org/TR/xmlschema-2/#anyURI

done in 1.487

I think you convinced me of this at some point, but I can't remember
it. In order to show this off to the WG, I've followed your suggestion
and used xsd:anyURI, however, I'm not convinced that the term provides
sufficient distinction from run of the mill xsd types. For instance, I
would like the following test to not be a cognitive stretch:

  _:a  foaf:name       "Alice".
  _:a  foaf:mbox       <mailto:alice@work.example> .
  _:a  x:mboxStr       "mailto:alice@work.example" .

 WHERE { ?x x:mboxStr  ?mstr ;
            foaf:mbox  ?mbox .
         FILTER (?mbox = xsd:anyURI(?mboxStr)) }

 WHERE { ?x x:mboxStr  ?mstr ;
            foaf:mbox  ?mbox .
         FILTER (str(?mbox) = ?mboxStr) }

Both of these tests should be as intuitive as possible.
I'd like to avoid making life hard in the future, so I'd like to
consider variants where str is not limited to variables.


I fixed up the corresponding the constructor functions:

From/To str    flt    dbl    dec    int    dT    bool    IRI    ltrl
str     Y      M      M      M      M      M     M       Y      Y
flt     Y      Y      Y      M      M      N     Y       N      N
dbl     Y      Y      Y      M      M      N     Y       N      N
dec     Y      Y      Y      Y      Y      N     Y       N      N
int     Y      Y      Y      Y      Y      N     Y       N      N
dT      Y      N      N      N      N      Y     N       N      N
bool    Y      Y      Y      Y      Y      N     Y       N      N
IRI     Y      N      N      N      N      N     N       Y      Y
ltrl    Y      M      M      Y      M      M     M       Y      Y

The changes are:
  strings are always castable to IRIs or literals.
  IRIs are always castable to literals
  literals are always castable to IRIs

XML Schema (cf http://www.w3.org/TR/xmlschema-2/#anyURI) says:
[[
The ·lexical space· of anyURI is finite-length character sequences
which, when the algorithm defined in Section 5.4 of [XML Linking
Language] is applied to them, result in strings which are legal URIs
according to [RFC 2396], as amended by [RFC 2732].spaceThe 
...
Note: Spaces are, in principle, allowed in the ·lexical space· of
anyURI, however, their use is highly discouraged (unless they are
encoded by %20).
]]

xsd:anyIRI has no lexical constraints (not pattern and not derived
from anything with a pattern) so I feel that, until you teach your
application various URI schemes, it can't tell you what strings are
valid IRIs and which aren't. to that end, I set that cell to "Y".


Apart from simple search/replace, there is the other updated text:
==================== 11.1
[[
In addition, SPARQL introduces additional operators which operate on
RDF terms. The following datatypes correspond to elements of the
Resource Description Framework (RDF): Concepts and Abstract Syntax
[12]:

    * anyURI:xs corresponds to a URIref in the RDF abstract syntax.
    * Literal:rdfs corresponds to a Literal in the RDF abstract
    syntax.
]]

Note, I got rid of the vestigial mention of r:bNode.


==================== Operator table:
[[
A = B	 RDF term	RDF term	sop:RDFterm-equal(A, B)
xs:boolean
A != B	RDF term	RDF term	fn:not(sop:RDFterm-equal(A,
B))	xs:boolean
]]

was r:term, but I heard (and agreed with) adverse feedback.


==================== 11.2
[[
    IRI = xs:anyURI
    ltrl = rdfs:Literal
]]

got rid of " -- introduced by the RDF data model"


> >and rdfs:Literal
> >  <http://www.w3.org/TR/2004/REC-rdf-schema-20040210/#ch_literal>
> >
> >Any objections?

Oof, this has been sitting around in my co tree for a long time,
forcing me to do other work from my tmp dir.
-- 
-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.