W3C home > Mailing lists > Public > public-rif-wg@w3.org > March 2008

Re: [Fwd: Re: [DTB] Datatypes and Built-ins first run to clean up and extend the initial list]

From: Axel Polleres <axel.polleres@deri.org>
Date: Tue, 04 Mar 2008 01:32:02 +0100
Message-ID: <47CC9882.9010201@deri.org>
To: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
CC: Michael Kifer <kifer@cs.sunysb.edu>

>>> A given IRI is interpreted as some abstract object in a given 
>>> interpretation.  I do not understand how a casting function for 
>>> such abstract objects can be defined in a meaningful way.
>> yes, it seems hairy/impossible to define it properly within the 
>> current FLD framework, because I can, even if I assume fixed 
>> interpretations for cast-functions, not "access" the lexical
>> representation from this fixed interpretation...
> It seems to me that the problem is with an inappropriate use of IRIs.
>  You seem to be treating them as a data type, while IRIs are like RDF
>  resources, and thus are not data types. Maybe you need to introduce
> a data type for what you want (not sure).

hmmmm. ouch.
Just to clarify a point here: It is not *me* who is treating IRIs like 
datatypes here, it is just how it is done in FOAF and in other RDF 
vocabularies... most actually. not my fault.

  To avoid this misunderstanding, I had quoted the FOAF spec in my 
original mail in the part which was cut out in the reply::

> foaf [1] suggests to encode telephone numbers as rdf:resources using
> a tel: scheme qualified URI:
> "Property: foaf:phone phone - A phone, specified using fully
> qualified tel: URI scheme (refs:
> http://www.w3.org/Addressing/schemes.html#tel)."
> in all RDF encodings of vCard I am aware of telephone numbers are
> encoded in String literals, instead.
> Now, if there is no way to get out the actual string of that URI in a
> builtin, I have no clue how to address this simple ontology mapping
> use case, see also [2], slide 4 and slide 10.
> I don't want to go into the philosophical problem of that URLs and
> URIs are intermingled in that FOAF encoding of telephone numbers, I
> just want to write a rule which does that mapping.

This was my original question, how do I do this mapping from
URIs to strings, if I need to (e.g. asking for a certain substing 
appearing in a URL)? yes, this mapping is not possible in the datatype 
system of FLD at the moment.

So, what do we want? Do we want to fix this, or do we want to convince 
all people out there who use RDF in that way that they are doing wrong,
i.e. shall I change my foaf file from

    foaf:phone <tel:+35391495723> ;
    foaf:homepage <http://www.polleres.net/> .


      foaf:phone    "tel:+35391495723"^^xsd:anyURI ;
      foaf:homepage "http://www.polleres.net/"^^xsd:anyURI .

So how do I convince all the rest of the world to change that likewise?
Even the RDF Primer [2] (Example 6):
      <rdf:Description rdf:nodeID="abc">
         <exterms:fullName>Dave Beckett</exterms:fullName>
         <exterms:homePage rdf:resource="http://purl.org/net/dajobe/"/>

or the SPARQL spec [3] (examples in Section 6):

  @prefix foaf:       <http://xmlns.com/foaf/0.1/> .
  @prefix rdf:        <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

  _:a  rdf:type        foaf:Person .
  _:a  foaf:name       "Alice" .
  _:a  foaf:mbox       <mailto:alice@example.com> .
  _:a  foaf:homepage   <http://work.example.org/alice/> .

promote the use of rdf:resources for URLs (homepages, email-adresses, 
etc.). It might be arguable with respect to the concepts, but people 
*do* use URIs like that and it is even done in the specs of RDF as we 
see here.

How do we cater for it?  By just stating I cannot get a substring out of 
a homepage-URL or email-address... just because rdf:resource (and 
rif:iri, respectively) are not datatypes?

I knew somehow why I put that in my signature ;-)


1. http://xmlns.com/foaf/spec/
2. http://www.w3.org/TR/REC-rdf-syntax/
3. http://www.w3.org/TR/rdf-sparql-query/

Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

rdfs:Resource owl:differentFrom xsd:anyURI .
Received on Tuesday, 4 March 2008 00:32:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:49 UTC