W3C home > Mailing lists > Public > www-rdf-rules@w3.org > June 2004

RE: SWRL string builtins -- suggestion

From: <massimo@w3.org>
Date: Thu, 3 Jun 2004 10:12:16 -0400 (EDT)
Message-ID: <3152.>
To: "Neil Goldman" <ngoldman@teknowledge.com>
Cc: www-rdf-rules@w3.org

All this is a very small subpart of the much more general issue,
not just belonging to SWRL but to Semantic Web Query/Reasoning in general,
of selecting/reusing a common suitable set of functions and operators.
Cf. from the Conclusions in http://www.w3.org/Submission/2004/03/Comment:
understanding that graceful interoperation within the RDF model and with
the XQuery functions and operators may well be the key to the success of
components of the Semantic Web.

So, the more general issue is, rather then reinventing the wheel,
trying to find the common set that applications can understand/share/reuse.
Obvious candidate for analysis: http://www.w3.org/TR/xpath-functions/

As said, this is not much of an SWRL issue, but of any Web Query/Reasoning
application that wants to gracefully scale.


ps In the very particular case of this discussion, fn:substring would do
what you want.

> I'm not sure what sort of abuse of a "charat" relation you are worried
> about, but certainly such abuse must already be possible via
> swrlb:substring, which allows one-character substrings to be referenced
> via rules.
> My feeling is that since OWL has adopted the XML schema standard datatype
> "string" it is unreasonable to place part of that standard outside the
> scope of "rules" SOLELY because it might be misused.  It is clear that the
> standard (quoted below) makes a "charat" relation well defined.  Any
> application program that obtains a  string value from OWL can readily
> obtain the integer codes of the individual charcters of that string with
> trivial library APIs available in every programming langauge.  My
> suggestion is simply that the built-ins of a rules standard should cover
> this aspect of the string type.
> In any case, we should not think of the type "string" as synonymous with
> "natural language text".  Strings are also used to represent fragments of
> programming language source code and network protocols and passwords and
> DNA codes and many other things which are not natural language at all.
> ===========from http://www.w3.org/TR/2000/WD-xmlschema-2-20000225
> 3.2.1 string
> [Definition:]  The string datatype represents character strings in XML.
> The value space of string is the set of finite sequences of UCS characters
> ([ISO 10646] and [Unicode]). A UCS character (or just character, for
> short) is an atomic unit of communication; it is not further specified
> except to note that every UCS character has a corresponding UCS code
> point, which is an integer. The ordered property of string is the
> [Unicode] character number sequence
>> -----Original Message-----
>> From: Martin Duerst [mailto:duerst@w3.org]
>> Sent: Monday, May 31, 2004 1:07 AM
>> To: Neil Goldman; www-rdf-rules@w3.org
>> Cc: Neil Goldman
>> Subject: Re: SWRL string builtins -- suggestion
>> This may be a bad idea. In English, a lot of functions on strings
>> can be implemented by using functions on individual characters of
>> the string. So a 'charAt' function seems very tempting. But in
>> many other languages, things are not as simple as that. Of course
>> this depends on the operation and the language.
>> Regards,    Martin.
>> At 16:45 04/05/28 -0700, Neil Goldman wrote:
>> >I believe the string builtins should provide a means to get to an
>> >individual character, not just to a string of length 1.
>> >It would suffice to provide:
>> >
>> >swrlb:charAt
>> >Satisfied iff the first argument is equal to the character
>> code of the
>> >character in the string second argument appearing at index
>> third argument
>> >
>> >====================> >
>> >Neil Goldman              Tel:   (310)578-5350 x204
>> >Teknowledge Corporation   Fax:   (310)578-5710
>> >Suite 1010
>> >4640 Admiralty Way
>> >Marina del Rey, CA 90292
Received on Thursday, 3 June 2004 10:12:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:49:40 UTC