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

Jos de Bruijn wrote:
> 
>>> Axel corrected my misunderstanding of his proposal but can't send 
>>> directly to the list.
>>>
>>> Axel: That makes more sense though I would still prefer builtins to 
>>> be IRIs so that I could, for example, annotate them in RDF with 
>>> metadata.
>>
>> No problem.... we just have to define the lexical spaces of
>> the respecctive symbol spaces  (let's call them rif:builtinFn and 
>> rif:builtinPred for the moment) the same as the lexical spaces for
>> rif:iri and define cast functions from-to rif:iri for rif:builtinFn 
>> and rif:builtinPred.
> 
> Since rif:iri is not a data type, I do not understand how cast functions 
> could be defined.

I was quite aware that this issue will raise concerns. However, I want 
to stress again my kind of standard use case from ontology mapping in 
this context:

How do I merge/translate telephone numbers from foaf and vCard?

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 addres 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.

> 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...

... still, I can implement a system which does exactly the builtin which 
I have in mind without major troubles... hmmm.

Axel

1. http://xmlns.com/foaf/spec/
2. http://www.polleres.net/presentations/20071127-SPARQL++ODBASE2007.pdf


> best, Jos
> 
>>
>> Axel
>>
>>
> 


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

rdfs:Resource owl:differentFrom xsd:anyURI .

Received on Monday, 3 March 2008 18:44:01 UTC