Ask v asks

When an asks element contains a single query it seems redundant to have an identifier for the query.
I suggest the following:

• Introduce the verb ask to formulate a single query to the reasoner, without need for an identifier.
• Use asks only for multiple queries.

Absorption results request

In order to implement precompletion in the instance store we need to have a handle on the state of the TBox after absorption. We therefore introduce four new verbs for DIG asks:

1. allAbsorbedPrimitiveConceptDefinitions
2. unabsorbableGCI
3. allDomainRestrictions
4. allRangeRestrictions

and corresponding verbs for DIG responses.

For example:

<asks
 xmlns="http://dl.kr.org/dig/2003/02/lang"
 uri="urn:test#uri">
 <allAbsorbedPrimitiveConceptDefinitions id="q1"/>
 <unabsorbableGCI id="q2"/>
</asks>


<responses xmlns="http://dl.kr.org/dig/2003/02/lang">
 <absorbedPrimitiveConceptDefinitions id="q1">
     <absorbedPrimitiveConceptDefinition>
         <catom name="d"/>
         <and>
             <catom name="e"/>
             <catom name="f"/>
         </and>
     </absorbedPrimitiveConceptDefinition>
     <absorbedPrimitiveConceptDefinition>
         <catom name="a"/>
         <catom name="b"/>
     </absorbedPrimitiveConceptDefinition>
     <absorbedPrimitiveConceptDefinition>
         <catom name="c"/>
         <top/>
     </absorbedPrimitiveConceptDefinition>
 </absorbedPrimitiveConceptDefinitions>
 <unabsorbed id="q2">
     <or>
         <catom name="d"/>
         <and>
             <catom name="e"/>
             <catom name="f"/>
         </and>
     </or>
 </unabsorbed>
</responses>

querying kb uris

A user request:

Is there any possibility to obtain uri of earlier loaded knowledge base?
For example I load some kb in Racer server from protege and afterwards, with using reasoners API, I want to get to know the uri of this kb.

tells

We must be able to tell OWL ontologies or fragments thereof:

<tells

uri=xsd:anyURI

>

Content: (Ontology |

   	Class |

	EnumeratedClass |

   	SubClassOf |

	EquivalentClasses |

	DisjointClasses |

   	DatatypeProperty | ObjectProperty |

   	SubPropertyOf | EquivalentProperties |

   	Individual | SameIndividual |

	DifferentIndividuals)*

</tells>

Some of the participants at the DIG 2.0 f2f meeting in Manchester. Left to right: Jeff Pan, Daniele Turi, Ian Horrocks, Matthew Horridge, Dmitry Tsarkov, Birte Glimm, Sean Bechhofer 

DIG 2.0 action plan

Produce informal plan and later submit it to W3C.

Produce draft using same style as http://owl.man.ac.uk/2003/concrete/latest/
Base it on OWL-XML.
Sourceforge issue tracking mechanism will be used for discussion together with this blog.

DIG 2.0 meeting notes

Supporting DL reasoning rather than generic reasoning.
General or ontology tools?
--> OWL people main customers.

Main novelty for DIG 2.0:

use OWL XML schema as much as possible.

Publish DIG 2.0 in its own namespace and just use XSLT.
(Communicate with authors of OWL-XML.)

This solves a lot problems with functionality additions.

Concrete domains/Data ranges.
XML-schema datatypes already in OWL.
Unary ok, but not n-ary. Postpone n-ary case for the moment.

Error codes.
Follow suggestion in ID paper.
Copy SOAP (new version). Apache Xerces. (SB.)

Result v results -> result
Response v responses -> response

Query everything and flag whether you want to reason or not.
This means keep track in the reasoner of the asserted stuff.

Allow client to ask for TBox in normalised form. (Eg absorbed.)
The reasoner is free to answer back with the original kb.

ID: strive for regularity. This can require extra effort, but might be worthwhile.
Agreement on at least looking into all possible variations of verbs and constructs and then see what has to be in.

Attribute values. We can assert that Mary's age is 45 but we cannot ask Mary's age.

UNA. OWL does not support it. Add functionality to switch it on and off.
Make clear this not OWL but using it to communicate with DL reasoners. Default not on but can be switched on. Or also make UNA relative to namespaces (IH). Maybe a feature too far for the moment.

Add is_consistent kb_uri. (Implementation: just ask if Thing is equivalent to Nothing.) Issues relative to ABox reasoning.

Role fillers. Hard from a reasoning pont of view. Regularisation issue again.

Anonymous resources. No way of preserving the RDF B-node identities. Not wise pushing them into DL reasoner.
Anonymous individuals more interesting. Mark them out as such using a standard URI (as in OWL API). Thus Skolemise with well-defined spec would do. Both system and client can generate identifiers for anonymous individuals. Use known algorithms to minimise possibility of name clashes. They will be treated specially by system and can be returned to queries. The client will have to handle the answers appropriately.

Query language.
Add at later stage and make sure no clash with above treatment of anonymous individuals.

Parameters for reasoning behaviour.
Get set of options from reasoner. Not for common options, which should be general names, but ok for lower level options. Problem is that different implementations can use lower level to control general options. Thus try to identify general options and allow for a back door allowing users to tweak beahaviour. Use property sets.

KB management (eg is kb uri valid?).
Multiple kbs managements. Problem is that we might move from a reasoner interface to a reasoner service.
In industrial settings one needs to attach metadata to kbs. Provide this at least.
Cannot use the fact that OWL ontologies have names because of incremental tells.
Keep on using generated kburis. Recommend that never a kburi is reused. Racer seems to violate this.
Ability to query metadata of kburi (last change, when created, etc). Make it optional.

OWL schema very large (eg imports etc).
We want to pick and choose the constructs we want.

Timings.
Internal times. An extra attribute in response. Or statistics.
Agreed on general requirement for performance information, but we will come back on actual syntax.

Serialise reasoner content.
Difficult to make it generic. Enough to reload reasoner from client. Save and restore. Problem is that we assume the same reasoner is used. Complexity issues. Danger is we try and do too much.

Supported functionality.
Tighten up specification of exiting verb. Again use property sets.

Zip.
Use v deploy. Since we expect use of this we will test performance on fact++. Problem is all the options for compressing.

Checksums.
Less needed if kburis unique.

Multiuser. Typical scenario one writer many readers. But we can do that with a service on top. Maybe the multiuser scenario does not make sense for DIG. Ask Cerebra people about their requirements.

Removing information from kb.
Easy to do in the interface. Less so at the reasoner level. Support untell but not retract. Tricky to specify so better be on the safe side and make it as easy as possible for implementors. More like a text editing operation than anything else. This requires identifiers for atomic tells which is problematic. String matching also not very good, but we have to live with that.
To be discussed further.

Checkpoints and rollback.
Similar to the point above but easier to implement. Would make query of premises easier.

Temporary assertions.
Put an extra argument in ask containing the temporary assertions.

OWL extensions (eg SWRL).
At least qualified cardinality restrictions and allDisjoints.
Having moved to OWL anyway let us postpone further extensions.
In general, we can go ahead and make them de facto standard.

DIG 2.0 Specification Meeting

DIG 2.0 Specification Meeting

Matthew Horridge's proposals

1. Determine whether or not a uri 'points' to a valid kb in the reasoner. (e.g. validKB id="q0" uri="http://my.kb.com").
2. Get the time that a kb was created.
3. Determine the time of the last tell.
4. Get a list of timings from the reasoner (e.g. time spent classifying a specific concept, which axioms caused 'bottle necks')
5. Be able to serialise and reload the contents of the reasoner (security issues?)
6. Have a shortcut method of specifying inverse properties and functional properties.
7. Have some method of representing cardinality restrictions on datatype properties.
8. Have a proper method of representing hasValue restrictions for both object and datatype properties.
9. Have some way of saying restriction(prop someValuesFrom(xsd:integer)).
10. A recommendation that reasoners should explicitly list all of the elements (Lang, Tell, Ask etc.) that are supported (even if some elements can be inferred by the presence of others).
11. Ability to have the option to send and receive compressed XML (zipped format or whatever) to the reasoner - for very large kb this might make a difference in the time spent transmitting large kbs/queries.
12. Check sum for knowledge bases/ontologies - then we can identify whether our application side kb is synchronised with the reasoner kb.
13. Provision for specifying data ranges e.g. hasTemperature > 36.5.
14. The ability to remove definitions and axioms from the knowledge base.

Dmitry Tsarkov's proposals

1. Allow clients to control reasoner's behaviour via options. I'll prepare a small presentation on how this can be done.
2. Add queries about DL storage (get concept definitions, simplifications, normal forms etc).
3. Add SWRL-like rules (as SWRL is going to be a W3C recommendation).

Birte Glimm's proposals

1. Add a query language extension to the DIG standard?
2. Add the possibility to specify temporary assertions, which are valid only for the time of a query.

Ian Horrocks' proposals

1. KB syntax: should DIG use OWL syntax (either XML or RDF)?
   
2. Extended functionality: in several applications we find ourselves writing code that duplicates functions performed within the classifier but not accessible via DIG, e.g., KB pre-processing tasks such as lexical normalisation and absorption.
   
3. Extensions to OWL: if all DIG implementers start to support commonly requested extensions (e.g., qualified cardinality constraints, allDisjoint, complex role inclusions) they could become a de facto standard.