Re: [DTB] Extractor function for the datatype? (was: [Fwd: Re: I18N issues an OWL2])

Michael Kifer wrote:
> I think it should be called symbol-space, since we have constants that do not
> belong to any data type (and maybe we need is-datatype, a test, as well).
> 
> Symbol spaces may not have disjoint lexical spaces, but they partition all
> constants into disjoint subsets. So, any given constant belongs to exactly one
> data type. For instance, "1"^^integer and "1"^^decimal.

however, a *function* (such as datatype) can only refer to the value 
space of the constant... and "1"^^integer and "1"^^decimal are exactly 
the same element in the domeain (i.e. in the intersection of integer's 
and decimal's value spaces)... so, what should function calls

   datatype("1"^^integer)
   datatype("1"^^decimal)

return then? by definition of a function, they need to return the same 
thing.

Axel


> 
> 	--michael  
> 
> On Thu, 10 Jul 2008 11:22:42 +0100
> Axel Polleres <axel.polleres@deri.org> wrote:
> 
>> For RIF only:
>>
>> In the discussion arounf language-tags, I rtealized that something like 
>> SPARQL's datatype function [1] is missing in DTB.
>>
>> Note however, that it is probably not so straight-forward to define...
>>
>> func:datatype should return a datatype IRI for its argument.
>> THis is easy as long as we assume disjoint value spaces for all 
>> datatypes, but as soon as we talk about type hierarchies (subtypes)
>> things get messy, what should the function return in case?
>>
>> the most specific or most generic type? I guess, we simply would need to 
>> defint it *per datatype* since this is not easy to answer.
>>
>> I think basically, e.g. for the xsd/xdt built-in datatypes we adopt, we 
>> should rely on the XPath/XQuery typ hierarchy [2], and return the most 
>> specific type from that hierarchy. however, that would, for instance 
>> mean that, for
>>
>> func:dataype("1.0"^^xs:decimal) you would get back
>>
>> xs:integer
>>
>> which may be considered awkward... opinions? Maybe this can be solved 
>> with a predicate instead of a function, similar to pred:iri-to-string, 
>> i.e. datatype-for-value(type, val)
>> which is true for type being the iri of any datatype in which value 
>> space val is.
>>
>> Even if this isn't probabvly important for DTB's first WD, shall I add 
>> an editor's note that we discuss about whether some form of adoption of 
>> a function similar to sparql's datatype() would be feasible? Even if we 
>> don't add a note now, I would like to open this as an issue.
>>
>> Opinions please!!!
>>
>> Axel
>>
>> 1.http://www.w3.org/TR/rdf-sparql-query/#func-datatype
>> 2.http://www.w3.org/TR/2004/WD-xpath-functions-20041029/#datatypes
>>
>>
>> -------- Original Message --------
>> Subject: Re: I18N issues an OWL2
>> Date: Thu, 10 Jul 2008 10:39:50 +0100
>> From: Axel Polleres <axel.polleres@deri.org>
>> Organization: DERI, National University of Ireland, Galway
>> To: Bijan Parsia <bparsia@cs.man.ac.uk>
>> CC: Phillips, Addison <addison@amazon.com>,  Dan Brickley 
>> <danbri@danbri.org>, Sandro Hawke <sandro@w3.org>, Jie Bao 
>> <baojie@cs.rpi.edu>,  OWL 1.1 <public-owl-wg@w3.org>, 
>> public-i18n-core-comments@w3.org <public-i18n-core@w3.org>, 
>> public-rif-comments@w3.org, public-webont-comments@w3.org
>> References: 
>> <4D25F22093241741BC1D0EEBC2DBB1DA013BB642BE@EX-SEA5-D.ant.amazon.com> 
>> <b6b357670807091132r5ac6f292paaefcc8702e9d4d2@mail.gmail.com> 
>> <4D25F22093241741BC1D0EEBC2DBB1DA013BB64C74@EX-SEA5-D.ant.amazon.com> 
>> <48753193.2020509@deri.org> <12918.1215647391@ubuhebe> 
>> <4D25F22093241741BC1D0EEBC2DBB1DA013BB6501A@EX-SEA5-D.ant.amazon.com> 
>> <274FC2EE-7C50-40BE-BAD1-379C85061831@cs.man.ac.uk>
>>
>> Bijan Parsia wrote:
>>> (too many lists! :))
>>>
>>> I'd like to raise a point that Dan Brickley (cced) often champions. If 
>>> it's more appropriate in a narrower scope, please narrow it for me!
>>>
>>> In some applications, like FOAF, it's common to compare as equal two 
>>> strings with different language tags (esp. for such purposes as being a 
>>> database key like identifier). I can think of several ways to do this 
>>> (e.g., always comparing the strings and opting in to distinguishing the 
>>> languages), but I thought I'd raise the issue.
>>>
>>> Cheers,
>>> Bijan.
>> Well, with the built-in functions in DTB [1]... you should be able to do
>> so, there are functions for extracting the string: by casting rif:text
>> to xs:string [2]) as well as extracting the lang-tag (by adopting
>> SPARQL's lang function [3]. Note that the former would be even easier
>> with the langtag-as-dataype proposal, and for the latter, we'd need a
>> function which returns the datatype of a literal... we have to discuss
>> this, since sparql's datatype function [4] is not straightforwardly
>> applicable to RIF semantically... at least there are some implications
>> in defining it, I guess.
>>
>> Axel
>>
>> 1.http://www.w3.org/2005/rules/wiki/DTB
>> 2.http://www.w3.org/2005/rules/wiki/DTB#xs:string
>> 3.http://www.w3.org/2005/rules/wiki/DTB#func:lang_.28adapted_from_SPARQL.27s_lang_function.29
>> 4.http://www.w3.org/TR/rdf-sparql-query/#func-datatype
>>
> 


-- 
Dr. Axel Polleres, Digital Enterprise Research Institute (DERI)
email: axel.polleres@deri.org  url: http://www.polleres.net/

Everything is possible:
rdfs:subClassOf rdfs:subPropertyOf rdfs:Resource.
rdfs:subClassOf rdfs:subPropertyOf rdfs:subPropertyOf.
rdf:type rdfs:subPropertyOf rdfs:subClassOf.
rdfs:subClassOf rdf:type owl:SymmetricProperty.

Received on Thursday, 10 July 2008 23:40:25 UTC