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

I forgot about the value spaces. It would be a relation then, not a function.

michael

On Fri, 11 Jul 2008 00:39:40 +0100
Axel Polleres <axel.polleres@deri.org> wrote:

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

Received on Friday, 11 July 2008 01:54:21 UTC