From: Mike Dean (mdean@bbn.com)
Date: 02/20/04
Said and I have been updating the draft SWRL builtins specification. You can see our work in progress at [1] (focus on the operations rather than the surrounding text). We currently have a plethora of individual accessor operations for "composite" datatypes such as get-year-from-dateTime get-month-from-dateTime get-day-from-dateTime get-hours-from-dateTime get-minutes-from-dateTime get-seconds-from-dateTime get-timezone-from-dateTime uri-protocol uri-host uri-port uri-path uri-query uri-fragment ... with plans for constructor operations that let one build each such datatype from its components. Given the new approach of defining operations in terms of satisfiability conditions rather than as functions, I think we just need the constructor operators, e.g. swrlo:dateTime (from xsd:dateTime) Satisfied iff $arg1 is the xsd:dateTime representation consisting of the year $arg2, month $arg3, day $arg4, hours $arg5, minutes $arg6, seconds $arg7, and timezone $arg8. swrlo:uriReference Satisfied iff $arg1 is a URI reference consisting of the scheme $arg2, host $arg3, port $arg4, path $arg5, query $arg6, and fragment $arg7. ... These operations could be satisfied in "either direction" (by grounding $arg1 or grounding $arg2 through $argn). Eliminating all of the accessors would significantly reduce the size of the spec. This may also motivate the inclusion of some sort of "don't care" variable analogous to Prolog's standalone ?. Given the uniform treatment of all SWRL operations, I think we can also dispense with the XQuery distinction between operators and functions, further simplifying the spec. Comments? Mike [1] http://www.daml.org/rules/proposal/builtins.html
This archive was generated by hypermail 2.1.4 : 02/20/04 EST