SWRL Issues List
The issues list document is a repository of issues regarding the Rules proposal. For each issue, we will define its status (open, resolved, etc.), a description and links to any discussions related to it. We will also cover any issues that are out of scope for the current deliverable. The integration of any new features will have to wait until we complete the delivery of this proposal.
This document will also cover language extensions and their own issues as part of the roadmap as defined earlier in the JC.
Issues can be sent directly to Said Tabet and Mike Dean or posted to the JC.
Issues already incorporated in the current draft
- 1. New section 4 (HR Syntax for all examples)
- 2. Informal syntax paragraph in section 2 (as 2.1)
- 2. Mention the definition of facts (as OWL facts but also as special case of rules)
- 3. Get a rules page up on daml.org
- 4. Examples: add more examples (suggested discount by Said and art style by Ian)
- 5. The issues List document has been created and linked from the main proposal
- 6. Naming for variables, e.g. local scoping: local URI vs. literal/string has been discussed on 2003/11/11.
Currently in RuleML syntax it is a string/literal, we can keep that in the short term for the XML version
- 7. Namespaces: Mike Dean updated the namespaces in sections 5 and 6 to use swrl[x], owl[x], and ruleml. After some consideration, also added the namespaces to the XML productions, for clarity
- 8. Said removed the "_" from the variable names in examples
- 9. Mike renamed section 6 to: RDF Concrete Syntax and included links to both RDF Schema and OWL Ontology
- 10. Non-well-formed XML in section 5 fixed by Mike. Updated beginning of section 5 as suggested by Harold
- 11. We finally agreed on the following proposal name: SWRL: A Semantic Web Rule Language Combining OWL and RuleML
- 12. Updated authors list in the main document, removed authors by sections, added links to home pages, affiliations
Issues considered for the next draft
- 1. Show corresponding PR Syntax where appropriate
- 2. Add Queries (assigned to Harold?)
- 3. Warning Label: Benjamin suggested to make it visible in the outline as: 7.1 Extensibility and Interoperability Cautions. Also suggested to remove "(Informative)" at the end of the section 7. title
- 4. ruleml:_head and ruleml:_body in the non-RDF XML encoding but change the RDF encoding to use the RDF convention of capitalization (assigned to Harold)
- 5. Next draft to be released after the 2003/11/18 JC telecon
Issues that are out of scope for the SWRL deliverable
- 1. representation of facts: shall we also have a fact element similar to that in RuleML, i.e., empty-head ground rule cf. RuleML
- 2. related to (1.): bnode semantics in facts
- 3. we need to do an RDF-XML syntax corresponding in tag names etc. to the non-RDF XML syntax
- 4. which syntax will be recommended (e.g., to tool developers) for exchange between systems: RDF-XML, non-RDF XML, or both?
- 5. Integrate the element as a separate fact construct (providing n-ary extension path) to complement the OWL fact (already in)
- 6. Extensibility: n-ary, functions and negation to be considered in future version (out of current scope)
- 7. bNodes: issue has been discussed in a JC call. This includes the ability to generate new nodes from a rule, possibly using a simpler mechanism than that shown in Example 5.1-4.
SWRL Language Extensions
Details to be provided soon.
SWRL Built-ins for module handling
The following functions may be introduced to manipulate modules in SWRL:
- swrlo:declareModule
This is a constructor allowing the creation of new modules. It is not fully side-effect free
- swrlo:getModules
Satisfied iff $arg1 is the list of declared modules
- swrlo:setModule
This is a side-effectfull built-in function
- swrlo:getModuleInfo
Returns the detailed info given a declared module name. (We need to clarify what info is returned)
SWRL Built-Ins Extensions
This section focuses on built-ins extensions including, as listed below, various classes of built-ins, some of them outside the SWRL Kernel, and others are implementation and API level built-ins.
- Control Built-ins: side-effectfull
- Database Built-ins
- Term Comparison Built-ins
- Term Manipulation Built-ins
- Stream I/O Built-ins
- Character I/O Built-ins
- Term I/O Built-ins
- Event Handling Built-ins
- Debugging Built-ins
- Arrays and Global Variable Built-ins
- Coroutining Built-ins
- External Interface Built-ins (imports)
- Prolog Environment Built-ins
- Compiler Directives Built-Ins
- Operating System Built-Ins
- Sorting Library predicates Built-ins
It could also be allowed to extend the Taxonomy by defining further built-ins on the level of the implementation language of the SWRL built-ins.
NOTE: Built-ins for sequences and nodes are not currently supported in SWRL. They can be left as optional for the specification implementations.
Other SWRL Built-Ins Functions Excluded from the current version
- swrlo:stringDiff
Satisfied iff $arg1 is the string representing the diff between string $arg2 and string $arg3 (case sensitive).
- swrlo:stringDiffIgnoreCase
Satisfied iff $arg1 is the string representing the diff between string $arg2 and string $arg3 (case ignored).
SWRL and the use of QNames
We need to clarify the use of QNames in SWRL (already introduced in section 8).
SWRL and empty rule head or body
In general, an empty head (RuleML element <_head> in SWRL) is equivalent to a query. Similarly, an empty body (RuleML element <_body> in SWRL) is equivalent to a fact. In the current specification, we still need to clarify the semantics of these situations. Do we allow users to write rules with empty head or body? do we recommend using a fact element when writing facts?