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

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

From: Axel Polleres <axel.polleres@deri.org>
Date: Fri, 11 Jul 2008 10:50:52 +0100
Message-ID: <48772CFC.8050607@deri.org>
To: kifer@cs.sunysb.edu
CC: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

Michael Kifer wrote:
> I forgot about the value spaces. It would be a relation then, not a function.

yup, that's what I meant to say, we thus need a predicate here, 
something like:

  pred:inDatatype( val, dt )

which is true if val is in the value space of one of the considered 
datatypes and dt being an xs:string denoting a valid datatype-IRI for 
this datatype.



> 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

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 Friday, 11 July 2008 09:52:12 UTC

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