RE: [regrep-semantic] Reg/Rep + Reasoning Use Cases

["Jeff Pollock" <Jeff.Pollock@networkinference.com>]

Farrukh,
 
Thank you for your comments and ideas, I am happy to explore further with yourself and the rest of the SCM members. 
 
But before diving in, I wanted to make one point of clarification - in your notes you reflected my statement that TBox and ABox stood for taxonomic and assertional. While this is true, they also stand for other things:
 
Terminological: http://www.cs.man.ac.uk/~horrocks/Slides/leipzig.pdf
Tableaux: http://citeseer.ist.psu.edu/506159.html
Algebraic: http://citeseer.ist.psu.edu/506159.html

Taxonomic: http://www.coling.uni-freiburg.de/pub/schulz/ref/schulz.aime01

Assertional: http://www.cs.man.ac.uk/~horrocks/Slides/leipzig.pdf

 
Generally speaking, the distinction is that tbox is reasoning about classes of things, while abox is reasoning about the things themselves.  A rose by any other name...
 
Many Kind Regards,
 
-Jeff-
 

	-----Original Message----- 
	From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] 
	Sent: Tue 5/4/2004 9:06 PM 
	To: Jeff Pollock 
	Cc: regrep-semantic@lists.oasis-open.org; Matthew Quinlan; Jack Berkowitz; Paul Turner; Ian Horrocks; Stanford - Deborah McGuinness; Rob Shearer; Gary Ng 
	Subject: Re: [regrep-semantic] Reg/Rep + Reasoning Use Cases
	
	

	Jeff Pollock wrote: 

	> Farrukh and SCM team- 
	>  
	> I've attached a candidate use case document with three use cases: 
	> 
	>     * 11 - Reason on Reg/Rep Content Objects (via RIM Query Interfaces) 
	>     * 12 - Reason on Reg/Rep Schema Directly (Tight Binding with OWL) 
	>     * 13 - Reason on Reg/Rep Schema Directly (Loose Binding with OWL) 
	> 
	> These tend to be architectural use cases, contemplating different 
	> mechanisms for accomplishing common business goals. All three 
	> "include" a common use case "Infer Semantics on Content Objects." 
	> Number 11 does no reasoning on the RIM directly.  Numbers 12 & 13 
	> support reasoning on the RIM directly via OWL interfaces, but consider 
	> different binding mechanisms. 
	>  
	> I've attempted be as clear as possible, but the writing and thinking 
	> raised more issues, some of which I only alluded to.  I look forward 
	> to everyone's thoughts. 
	>  

	Jeff, 

	I found the document very well thought out and a very good articulation 
	of the alternative design approaches for supporting reasoning in the 
	context of our SCM work. 
	A few small suggestions follow... 

	1. I think the document is a compilation of Design Alternatives rather 
	than use cases. Call it what we may it is an important document for our 
	work. 
	My suggestion is that we call it "Design Alternatives and Recommendation 
	for Inference Support" (or something along those lines). 

	2. We still need some "Business" oriented use cases for inference 
	support which would be the motivation for the above "Design 
	Alternatives" document. 
	The use cases may be along the lines of the T-Box and A-Box Inference 
	that you mentioned in today's meeting. For those that missed the informative 
	discussion led by Jeff T-Box inferencing is "Taxonomic" inferencing 
	based upon inter-class relationships while A-Box inferencing is based 
	upon "Associative" 
	inferencing based upon instance (aka individual) properties. 

	Would you be willing to contribute a few use cases involving T-Box and 
	A-Box inferencing? 

	3. The current document could use a paragraph at the end that compares 
	the pros and cons of each approach and makes a recommendation (I assume 
	it will be option 3 (loose coupling). 

	4. In option 3 (loose coupling) I like the idea of the Inference engine 
	to be normatively speced as a pluggable web service along the same lines 
	as the design for Content Validation or Content Cataloging service. This 
	would allow a registry to be configured with multiple inference engines, 
	one for each type of Ontology content type (e.g. OWL, KIF etc.). 

	5. After describing option 3 as the chosen option mention that a 
	detailed specification for option 3 will be developed as a separate 
	deliverable. 
	The specification would include a WSDL binding for the inference service 
	and other details. 
	Lastly, I think we should include in our planned deliverables a concrete 
	binding between OWL and RIM and leave other Ontology languages 
	to be defined elsewhere. I think even in the loosely coupled approach we 
	need to make sure that OWL support is explicitly defined. 

	Thanks again for making this valuable contribution to the SC. Team, 
	please comment on the document. Thanks. 

	-- 
	Regards, 
	Farrukh