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

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.


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

Received on Thursday, 10 July 2008 22:43:07 UTC