(in-package "KPML")

;;; File: kpml-kr-interface.lisp
;;; John:Stirling:Oct97
;;;
;;; Contains stubbs for the necessary KR system KPML interface
;;; functions that need definition for any KR system.
;;; Interfaces for particular KR systems supported are generally found
;;; in a subdirectory here or elsewhere as defined in the top level
;;; selected-kpml-kr.lisp file. 
;;;
;;; The user of alternative KR systems should be aware that this will
;;; generally involve also providing a representation of the Upper Model
;;; version that is being used in that KR system. 
;;; ----------------------------------------------------------------------

(defvar *KR-FILE-EXTENSION* "extension" 
  "Contains the file extension that the resource management operations
   are to use when looking for domain model or upper model definitions")

(defun KB-PACKAGE ()
  "Returns the particular Lisp package associated with the
   knowledge base."

  ;; N.B., kb-package is important when the Upper model is in a package
  ;; that is not accessible to the KPML package. There is no reason why
  ;; such a package *should* be accessible, so a sensible definition of
  ;; kb-package really should be provided. If it's value is not sensible,
  ;; it is likely that SPL's will not be correctly parsed since they
  ;; will not find the appropriate upper model concepts.

  ;; Must return some sensible value even if no KR present, i.e.,
  ;; something that can be a package.

  (find-package "KPML"))


(defun KB-CONCEPT-P (c)
  "Checks that c is defined as a concept"
  nil)


(defun KB-SUPERP (c1 c2)
  "Is c1 a superconcept of c2?"

  ;; N.B., KB-SUPERP is something that
  ;; can take inquiry operators as first argument and will in that
  ;; case always return NIL, even though there may be identical
  ;; symbols naming concepts!

  nil)

(defun KB=SUPERP (c1 c2)
  "Is c1 the same or a superconcept of c2?"
  (or (eq c1 c2)
      (kb-superp c1 c2)))

(defun KB-GetNamedConcept (concept)
  "Returns the concept with the specified name"
  nil)

(defun KB-GetNamedRelation (relation)
  "Returns the relation with the specified name"
  nil)

(defun RELATIVE-SUBCONCEPTS (concept list-of-concepts) 
  "Return subconcepts of CONCEPT which are not subconcepts of any of
   LIST-OF-CONCEPTS."
  nil)

(defun KB-ImmediateSubCs (concept)
  "Returns the immediately dependent subconcepts of concept"
  nil)

(defun KB-ImmediateSuperCs (concept) 
  "Returns the immediately dominating superconcepts of concept"
  nil)
  
(defun KB-GetConceptName (concept) 
  "Returns the symbol naming the concept concept"
  nil)

(defun KB-ConceptDisjoint? (c1 c2)
  "True, if C1 and C2 belong to disjoint classes." 
  nil)

(defun KB-entity? (instance)
  "T, if INSTANCE is known to the KB."
  nil)

(defun KB-type (instance)
  "returns the type of instance, if instance is an instance"
  
  ;; this function is not used anywhere in current KPML code but
  ;; could be useful if defined.

  nil)

(defun KB-INITIALIZATIONS ()
  "Call this to perform any initializations the KR system needs after
   loading definitions"
  nil)

;;; Following are optional... that is,  they do not need to return
;;; something sensible, but they *must* be defined if the user
;;; interface is going to work with semantic concepts.
;;; They aid inspection but do not influence 
;;; generation... Thus, if no window interface is being used, they may be
;;; left; otherwise the window interface options for seeing these will
;;; not work. 

(defun KB-GENERATE-SOURCE-DEFINITION (object)
  "Call this to display definitions from the KPML window interface"
  "no source known")
	 
(defun KB-SYSTEM-DEFINED-NAME-P (concept)
  "If the KR system generates its own internal concepts (e.g., in a classification process) it may allow the user to interrogate this status"
  nil)

(defun MAKE-PRINTABLE-CONCEPT-NAME (concept)
  "If the KR can generate a sensible printname that is guaranteed to be presentable in a GUI, then it should be created here."
  nil)



