I did something similar in the past, however using a different strategy.
The whole thing basically works like this:
1) I have a C++ Prog with an embedded clips engine (and whatever XML/XSD handling you like)
2) when a request arrives (as XML) look into a mapping table to locate the matching Clips defclass (which must exist), create an instance of that class or locate the already existing instance based on identifying XML attributes
3) Map in XML attributes to Clips instance slots (this may happen recursively for nested XML structures which yields nested Clips instances) by calling message handlers
4) Let the Clips engine run
5) If done, either trigger actions from inside the Clips instances or query instances from the C++ prog to produce a result
This means that all the XML I/O and mapping between XML and Clips
happens mostly in the C++ code using the Clips API - except all logic in
the Clips rules itself. Once I let the engine run (step 4) the C++ prog
does not know anything what's happening in Clips. The mapping stuff was
quite complicated though.
The fundamental idea is to have an equivalent between your XSD and Clips
defclasses and map between each other. Your XML example would then be
something like
(defclass Child (is-a USER)
...
)
(defclass Parent (is-a USER)
(multislot children
(allowed-classes Child)
)
)
and
(definstances x
(foo of Child ...)
(bar of Child ...)
(parent of Parent (children [foo bar]))
...
)
Of course in this example, the defclasses "Parent" and "Child" are quite
static (how are sub-schema of Child named?) but you could also define a
generic
(defclass XmlAttr (is-a USER)
(slot name)
(slot value)
)
(defclass XmlTag (is-a USER)
(multislot children (allowed-classes XmlTag)
(multislot attrs (allowed-classes XmlAttr)
)
This is similar to your approach, only that the parent/child
relationship is already stored nicely as instance slots (no slot
"parent" needed).
Scalability may be an issue, especially with such a generic defclass
(and hence 1000s of instances of XmlTag) may be dangerous if you want to
combine multiple XmlTag instances (since there may be zillions of
partial matches due to all the permutations) - this will most likely a
problem with your original idea too.
> 1. CLIPS and XML? [2 Updates]
> CLIPS and XML?
> Torben Bang Nielsen <torben.b.niel...@gmail.com> Oct 11
> 10:31PM -0700
> Hi all,
> Does anyone have experience or ideas for dealing with XML data
> from CLIPS > code?
> What I'm thinking of is building a request/reply framework
> where I can pass > an XML document (adhering to a given XSD) into CLIPS as facts,
> have the > rules do their thing and then finally build a response XML
> document that > adheres to the same of a different XSD.
> I'm rather new to CLIPS, but one of the thoughts I've had on
> this is to > represent each XML element as a deftemplate fact and then link
> a child > element to its parent using the parent's fact address - does
> this sound > reasonable?
> Something like this:
> (deftemplate element
> (slot name (type STRING))
> (slot value (default nil))
> (slot parent (type INSTANCE))
> (slot predecessor (type INSTANCE)))
> (deftemplate attribute
> (slot name (type STRING))
> (slot value (default nil))
> (slot parent (type INSTANCE)))
> representing this XML document:
> <Root>
> <Parent @attr="flip">
> <Child>foo</Child>
> <Child>bar</Child>
> </Parent>
> </Root>
> I suppose this could represent any reasonable XML document
> we'd encounter - > just seems like it'd be a bit tedious to navigate and then I
> don't know how > it would scale to big XML documents with thousands of
> elements?
> Any examples or ideas would be greatly appreciated.
> cheers, > /Torben
> Artem Novikov <noviko...@gmail.com> Oct 13 07:02AM -0700
> Parsing something using CLIPS is a bad approach. > Read about embedding CLIPS.
> пятница, 12 октября 2012 г., 13:31:44 UTC+8 пользователь
> Torben Bang > Nielsen написал:
> You received this message because you are subscribed to the Google
> Group clipsesg.
> You can post via email.
> To unsubscribe from this group, send an empty message.
> For more options, visit this group.
> -- > You received this message because you are subscribed to the Google
> Groups "CLIPSESG" group.
> To post to this group, send email to CLIPSESG@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/CLIPSESG?hl=en
> --> IF YOU NO LONGER WANT TO RECEIVE EMAIL <-- > Visit this group at http://groups.google.com/group/CLIPSESG?hl=en > Click on "Edit my membership" link.
> Select the "No Email" radio button.
> Click the "Save these settings" button.
> --> IF YOU WANT TO UNSUBSCRIBE <--
> Visit this group at http://groups.google.com/group/CLIPSESG?hl=en > Sign in
> Click on "Edit my membership" link.
> Click the "Unsubscribe" button.
> Note: This appears to be the most reliable way to unsubscribe
> Alternately, send email to CLIPSESG-unsubscribe@googlegroups.com. You
> will receive an email which you must respond to as well to
> unsubscribe. Clicking the link mentioned in the unsubscribe reply does
> not appear to work reliably.
I have also implemented (with my students) a similar solution to Thomas',
concerning the data model mapping.
The differences are:
1) Everything is implemented in CLIPS native code and not C++.
2) There are two phases. In Phase A the DTD that validates the XML file
is loaded into CLIPS and translated into a collection of defclass definitions.
In Phase B, the XML files is loaded and the COOL classes created in Phase A
are populated with instances that map the XML file content. The XML file
is supposed to be valid (no validation occurs).
In case you are interested I can provide the source code,
but unfortunately there is no report in English for this.
Cheers,
Nick
Στις 13/10/2012 11:55 μμ, ο/η Thomas Gentsch έγραψε:
> I did something similar in the past, however using a different strategy.
> The whole thing basically works like this:
> 1) I have a C++ Prog with an embedded clips engine (and whatever
> XML/XSD handling you like)
> 2) when a request arrives (as XML) look into a mapping table to locate
> the matching Clips defclass (which must exist), create an instance of
> that class or locate the already existing instance based on
> identifying XML attributes
> 3) Map in XML attributes to Clips instance slots (this may happen
> recursively for nested XML structures which yields nested Clips
> instances) by calling message handlers
> 4) Let the Clips engine run
> 5) If done, either trigger actions from inside the Clips instances or
> query instances from the C++ prog to produce a result
> This means that all the XML I/O and mapping between XML and Clips
> happens mostly in the C++ code using the Clips API - except all logic in
> the Clips rules itself. Once I let the engine run (step 4) the C++ prog
> does not know anything what's happening in Clips. The mapping stuff was
> quite complicated though.
> The fundamental idea is to have an equivalent between your XSD and Clips
> defclasses and map between each other. Your XML example would then be
> something like
> (defclass Child (is-a USER)
> ...
> )
> (defclass Parent (is-a USER)
> (multislot children
> (allowed-classes Child)
> )
> )
> and
> (definstances x
> (foo of Child ...)
> (bar of Child ...)
> (parent of Parent (children [foo bar]))
> ...
> )
> Of course in this example, the defclasses "Parent" and "Child" are quite
> static (how are sub-schema of Child named?) but you could also define a
> generic
> (defclass XmlAttr (is-a USER)
> (slot name)
> (slot value)
> )
> (defclass XmlTag (is-a USER)
> (multislot children (allowed-classes XmlTag)
> (multislot attrs (allowed-classes XmlAttr)
> )
> This is similar to your approach, only that the parent/child
> relationship is already stored nicely as instance slots (no slot
> "parent" needed).
> Scalability may be an issue, especially with such a generic defclass
> (and hence 1000s of instances of XmlTag) may be dangerous if you want to
> combine multiple XmlTag instances (since there may be zillions of
> partial matches due to all the permutations) - this will most likely a
> problem with your original idea too.
>> 1. CLIPS and XML? [2 Updates]
>> CLIPS and XML?
>> Torben Bang Nielsen <torben.b.niel...@gmail.com> Oct 11
>> 10:31PM -0700
>> Hi all,
>> Does anyone have experience or ideas for dealing with XML data
>> from CLIPS
>> code?
>> What I'm thinking of is building a request/reply framework
>> where I can pass
>> an XML document (adhering to a given XSD) into CLIPS as facts,
>> have the
>> rules do their thing and then finally build a response XML
>> document that
>> adheres to the same of a different XSD.
>> I'm rather new to CLIPS, but one of the thoughts I've had on
>> this is to
>> represent each XML element as a deftemplate fact and then link
>> a child
>> element to its parent using the parent's fact address - does
>> this sound
>> reasonable?
>> Something like this:
>> (deftemplate element
>> (slot name (type STRING))
>> (slot value (default nil))
>> (slot parent (type INSTANCE))
>> (slot predecessor (type INSTANCE)))
>> (deftemplate attribute
>> (slot name (type STRING))
>> (slot value (default nil))
>> (slot parent (type INSTANCE)))
>> representing this XML document:
>> <Root>
>> <Parent @attr="flip">
>> <Child>foo</Child>
>> <Child>bar</Child>
>> </Parent>
>> </Root>
>> I suppose this could represent any reasonable XML document
>> we'd encounter -
>> just seems like it'd be a bit tedious to navigate and then I
>> don't know how
>> it would scale to big XML documents with thousands of
>> elements?
>> Any examples or ideas would be greatly appreciated.
>> cheers,
>> /Torben
>> Artem Novikov <noviko...@gmail.com> Oct 13 07:02AM -0700
>> Parsing something using CLIPS is a bad approach.
>> Read about embedding CLIPS.
>> пятница, 12 октября 2012 г., 13:31:44 UTC+8 пользователь
>> Torben Bang
>> Nielsen написал:
>> You received this message because you are subscribed to the Google
>> Group clipsesg.
>> You can post via email.
>> To unsubscribe from this group, send an empty message.
>> For more options, visit this group.
>> -- >> You received this message because you are subscribed to the Google
>> Groups "CLIPSESG" group.
>> To post to this group, send email to CLIPSESG@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/CLIPSESG?hl=en
>> --> IF YOU NO LONGER WANT TO RECEIVE EMAIL <--
>> Visit this group at http://groups.google.com/group/CLIPSESG?hl=en >> Click on "Edit my membership" link.
>> Select the "No Email" radio button.
>> Click the "Save these settings" button.
>> --> IF YOU WANT TO UNSUBSCRIBE <--
>> Visit this group at http://groups.google.com/group/CLIPSESG?hl=en >> Sign in
>> Click on "Edit my membership" link.
>> Click the "Unsubscribe" button.
>> Note: This appears to be the most reliable way to unsubscribe
>> Alternately, send email to CLIPSESG-unsubscribe@googlegroups.com. You
>> will receive an email which you must respond to as well to
>> unsubscribe. Clicking the link mentioned in the unsubscribe reply does
>> not appear to work reliably.
-- **************************************************************
* Dr. Nick Bassiliades, Associate Professor *
* Dept. of Informatics, Aristotle University of Thessaloniki *
* 54124 Thessaloniki, Greece *
* *
* Tel: +302310997913 E-mail: nbass...@csd.auth.gr *
* Fax: +302310997913 URL: http://tinyurl.com/nbassili *
* ========================================================== *
* LPIS (Logic Programming & Intelligent Systems) Group *
* URL: http://lpis.csd.auth.gr/ *
**************************************************************
> Datum: Sun, 14 Oct 2012 09:44:07 +0300
> Von: Nick Bassiliades <nbass...@csd.auth.gr>
> An: clipsesg@googlegroups.com
> Betreff: Re: Digest for clipsesg@googlegroups.com - 2 Messages in 1 Topic
> Hi Torben and all,
> I have also implemented (with my students) a similar solution to Thomas',
> concerning the data model mapping.
> The differences are:
> 1) Everything is implemented in CLIPS native code and not C++.
> 2) There are two phases. In Phase A the DTD that validates the XML file
> is loaded into CLIPS and translated into a collection of defclass > definitions.
> In Phase B, the XML files is loaded and the COOL classes created in Phase
> A
> are populated with instances that map the XML file content. The XML file
> is supposed to be valid (no validation occurs).
> In case you are interested I can provide the source code,
> but unfortunately there is no report in English for this.
> Cheers,
> Nick
> Στις 13/10/2012 11:55 μμ, ο/η Thomas Gentsch έγραψε:
> > Hi Torben,
> > I did something similar in the past, however using a different strategy.
> > The whole thing basically works like this:
> > 1) I have a C++ Prog with an embedded clips engine (and whatever
> > XML/XSD handling you like)
> > 2) when a request arrives (as XML) look into a mapping table to locate
> > the matching Clips defclass (which must exist), create an instance of
> > that class or locate the already existing instance based on
> > identifying XML attributes
> > 3) Map in XML attributes to Clips instance slots (this may happen
> > recursively for nested XML structures which yields nested Clips
> > instances) by calling message handlers
> > 4) Let the Clips engine run
> > 5) If done, either trigger actions from inside the Clips instances or
> > query instances from the C++ prog to produce a result
> > This means that all the XML I/O and mapping between XML and Clips
> > happens mostly in the C++ code using the Clips API - except all logic in
> > the Clips rules itself. Once I let the engine run (step 4) the C++ prog
> > does not know anything what's happening in Clips. The mapping stuff was
> > quite complicated though.
> > The fundamental idea is to have an equivalent between your XSD and Clips
> > defclasses and map between each other. Your XML example would then be
> > something like
> > (defclass Child (is-a USER)
> > ...
> > )
> > (defclass Parent (is-a USER)
> > (multislot children
> > (allowed-classes Child)
> > )
> > )
> > and
> > (definstances x
> > (foo of Child ...)
> > (bar of Child ...)
> > (parent of Parent (children [foo bar]))
> > ...
> > )
> > Of course in this example, the defclasses "Parent" and "Child" are quite
> > static (how are sub-schema of Child named?) but you could also define a
> > generic
> > (defclass XmlAttr (is-a USER)
> > (slot name)
> > (slot value)
> > )
> > (defclass XmlTag (is-a USER)
> > (multislot children (allowed-classes XmlTag)
> > (multislot attrs (allowed-classes XmlAttr)
> > )
> > This is similar to your approach, only that the parent/child
> > relationship is already stored nicely as instance slots (no slot
> > "parent" needed).
> > Scalability may be an issue, especially with such a generic defclass
> > (and hence 1000s of instances of XmlTag) may be dangerous if you want to
> > combine multiple XmlTag instances (since there may be zillions of
> > partial matches due to all the permutations) - this will most likely a
> > problem with your original idea too.
> >> 1. CLIPS and XML? [2 Updates]
> >> CLIPS and XML?
> >> Torben Bang Nielsen <torben.b.niel...@gmail.com> Oct 11
> >> 10:31PM -0700
> >> Hi all,
> >> Does anyone have experience or ideas for dealing with XML data
> >> from CLIPS
> >> code?
> >> What I'm thinking of is building a request/reply framework
> >> where I can pass
> >> an XML document (adhering to a given XSD) into CLIPS as facts,
> >> have the
> >> rules do their thing and then finally build a response XML
> >> document that
> >> adheres to the same of a different XSD.
> >> I'm rather new to CLIPS, but one of the thoughts I've had on
> >> this is to
> >> represent each XML element as a deftemplate fact and then link
> >> a child
> >> element to its parent using the parent's fact address - does
> >> this sound
> >> reasonable?
> >> Something like this:
> >> (deftemplate element
> >> (slot name (type STRING))
> >> (slot value (default nil))
> >> (slot parent (type INSTANCE))
> >> (slot predecessor (type INSTANCE)))
> >> (deftemplate attribute
> >> (slot name (type STRING))
> >> (slot value (default nil))
> >> (slot parent (type INSTANCE)))
> >> I suppose this could represent any reasonable XML document
> >> we'd encounter -
> >> just seems like it'd be a bit tedious to navigate and then I
> >> don't know how
> >> it would scale to big XML documents with thousands of
> >> elements?
> >> Any examples or ideas would be greatly appreciated.
> >> cheers,
> >> /Torben
> >> Artem Novikov <noviko...@gmail.com> Oct 13 07:02AM -0700
> >> Parsing something using CLIPS is a bad approach.
> >> Read about embedding CLIPS.
> >> пятница, 12 октября 2012 г., 13:31:44 UTC+8
> пользователь
> >> Torben Bang
> >> Nielsen написал:
> >> You received this message because you are subscribed to the Google
> >> Group clipsesg.
> >> You can post via email.
> >> To unsubscribe from this group, send an empty message.
> >> For more options, visit this group.
> >> -- > >> You received this message because you are subscribed to the Google
> >> Groups "CLIPSESG" group.
> >> To post to this group, send email to CLIPSESG@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/CLIPSESG?hl=en
> >> --> IF YOU NO LONGER WANT TO RECEIVE EMAIL <--
> >> Visit this group at http://groups.google.com/group/CLIPSESG?hl=en > >> Click on "Edit my membership" link.
> >> Select the "No Email" radio button.
> >> Click the "Save these settings" button.
> >> --> IF YOU WANT TO UNSUBSCRIBE <--
> >> Visit this group at http://groups.google.com/group/CLIPSESG?hl=en > >> Sign in
> >> Click on "Edit my membership" link.
> >> Click the "Unsubscribe" button.
> >> Note: This appears to be the most reliable way to unsubscribe
> >> Alternately, send email to CLIPSESG-unsubscribe@googlegroups.com. You
> >> will receive an email which you must respond to as well to
> >> unsubscribe. Clicking the link mentioned in the unsubscribe reply does
> >> not appear to work reliably.
> -- > **************************************************************
> * Dr. Nick Bassiliades, Associate Professor *
> * Dept. of Informatics, Aristotle University of Thessaloniki *
> * 54124 Thessaloniki, Greece *
> * *
> * Tel: +302310997913 E-mail: nbass...@csd.auth.gr *
> * Fax: +302310997913 URL: http://tinyurl.com/nbassili *
> * ========================================================== *
> * LPIS (Logic Programming & Intelligent Systems) Group *
> * URL: http://lpis.csd.auth.gr/ *
> **************************************************************
> -- > You received this message because you are subscribed to the Google Groups
> "CLIPSESG" group.
> To post to this group, send email to CLIPSESG@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/CLIPSESG?hl=en
> --> IF YOU NO LONGER WANT TO RECEIVE EMAIL <-- > Visit this group at http://groups.google.com/group/CLIPSESG?hl=en > Click on "Edit my membership" link.
> Select the "No Email" radio button.
> Click the "Save these settings" button.
At the following address
https://dl.dropbox.com/u/3157468/X-DEVICE.rar please find the source code for X-DEVICE, a system
we have developed at the Department of Informatics,
Aristotle University of Thessaloniki, Greece, with
some of my students.
Unfortunately, there is no English report on this, only
a Greek BSc thesis. However, I send it too, in case you would like
to go through the XML and CLIPS code and the figure
that are in there.
In order to run the program, you have to load the batch file load-files.BAT
located the source folder.
Then, at the prompt you type
(import-XML "bibDTD.txt" "bibXML.txt")
The first argument is the DTD and the second is the XML file that conforms
to the DTD. These two files are also located in the source folder.
The system has been developed 8 years ago (2004) and since then
we did not have the chance to further develop it, so please gentle!
In case there is an interest on this, I guess I could consult on some parts
of the code, although I was mainly supervising this and not developed it
myself.
Have fun!
Cheers,
Nick
Στις 14/10/2012 11:42 πμ, ο/η "Peter Löwe" έγραψε:
> it would be great if you would share the source code of your work on XML / COOL integration with the CLIPS-comunity.
> Best,
> Peter
> -------- Original-Nachricht --------
>> Datum: Sun, 14 Oct 2012 09:44:07 +0300
>> Von: Nick Bassiliades <nbass...@csd.auth.gr>
>> An: clipsesg@googlegroups.com
>> Betreff: Re: Digest for clipsesg@googlegroups.com - 2 Messages in 1 Topic
>> Hi Torben and all,
>> I have also implemented (with my students) a similar solution to Thomas',
>> concerning the data model mapping.
>> The differences are:
>> 1) Everything is implemented in CLIPS native code and not C++.
>> 2) There are two phases. In Phase A the DTD that validates the XML file
>> is loaded into CLIPS and translated into a collection of defclass
>> definitions.
>> In Phase B, the XML files is loaded and the COOL classes created in Phase
>> A
>> are populated with instances that map the XML file content. The XML file
>> is supposed to be valid (no validation occurs).
>> In case you are interested I can provide the source code,
>> but unfortunately there is no report in English for this.
>> Cheers,
>> Nick
>> Στις 13/10/2012 11:55 μμ, ο/η Thomas Gentsch έγραψε:
>>> Hi Torben,
>>> I did something similar in the past, however using a different strategy.
>>> The whole thing basically works like this:
>>> 1) I have a C++ Prog with an embedded clips engine (and whatever
>>> XML/XSD handling you like)
>>> 2) when a request arrives (as XML) look into a mapping table to locate
>>> the matching Clips defclass (which must exist), create an instance of
>>> that class or locate the already existing instance based on
>>> identifying XML attributes
>>> 3) Map in XML attributes to Clips instance slots (this may happen
>>> recursively for nested XML structures which yields nested Clips
>>> instances) by calling message handlers
>>> 4) Let the Clips engine run
>>> 5) If done, either trigger actions from inside the Clips instances or
>>> query instances from the C++ prog to produce a result
>>> This means that all the XML I/O and mapping between XML and Clips
>>> happens mostly in the C++ code using the Clips API - except all logic in
>>> the Clips rules itself. Once I let the engine run (step 4) the C++ prog
>>> does not know anything what's happening in Clips. The mapping stuff was
>>> quite complicated though.
>>> The fundamental idea is to have an equivalent between your XSD and Clips
>>> defclasses and map between each other. Your XML example would then be
>>> something like
>>> (defclass Child (is-a USER)
>>> ...
>>> )
>>> (defclass Parent (is-a USER)
>>> (multislot children
>>> (allowed-classes Child)
>>> )
>>> )
>>> and
>>> (definstances x
>>> (foo of Child ...)
>>> (bar of Child ...)
>>> (parent of Parent (children [foo bar]))
>>> ...
>>> )
>>> Of course in this example, the defclasses "Parent" and "Child" are quite
>>> static (how are sub-schema of Child named?) but you could also define a
>>> generic
>>> (defclass XmlAttr (is-a USER)
>>> (slot name)
>>> (slot value)
>>> )
>>> (defclass XmlTag (is-a USER)
>>> (multislot children (allowed-classes XmlTag)
>>> (multislot attrs (allowed-classes XmlAttr)
>>> )
>>> This is similar to your approach, only that the parent/child
>>> relationship is already stored nicely as instance slots (no slot
>>> "parent" needed).
>>> Scalability may be an issue, especially with such a generic defclass
>>> (and hence 1000s of instances of XmlTag) may be dangerous if you want to
>>> combine multiple XmlTag instances (since there may be zillions of
>>> partial matches due to all the permutations) - this will most likely a
>>> problem with your original idea too.
>>>> 1. CLIPS and XML? [2 Updates]
>>>> CLIPS and XML?
>>>> Torben Bang Nielsen <torben.b.niel...@gmail.com> Oct 11
>>>> 10:31PM -0700
>>>> Hi all,
>>>> Does anyone have experience or ideas for dealing with XML data
>>>> from CLIPS
>>>> code?
>>>> What I'm thinking of is building a request/reply framework
>>>> where I can pass
>>>> an XML document (adhering to a given XSD) into CLIPS as facts,
>>>> have the
>>>> rules do their thing and then finally build a response XML
>>>> document that
>>>> adheres to the same of a different XSD.
>>>> I'm rather new to CLIPS, but one of the thoughts I've had on
>>>> this is to
>>>> represent each XML element as a deftemplate fact and then link
>>>> a child
>>>> element to its parent using the parent's fact address - does
>>>> this sound
>>>> reasonable?
>>>> Something like this:
>>>> (deftemplate element
>>>> (slot name (type STRING))
>>>> (slot value (default nil))
>>>> (slot parent (type INSTANCE))
>>>> (slot predecessor (type INSTANCE)))
>>>> (deftemplate attribute
>>>> (slot name (type STRING))
>>>> (slot value (default nil))
>>>> (slot parent (type INSTANCE)))
>>>> representing this XML document:
>>>> <Root>
>>>> <Parent @attr="flip">
>>>> <Child>foo</Child>
>>>> <Child>bar</Child>
>>>> </Parent>
>>>> </Root>
>>>> I suppose this could represent any reasonable XML document
>>>> we'd encounter -
>>>> just seems like it'd be a bit tedious to navigate and then I
>>>> don't know how
>>>> it would scale to big XML documents with thousands of
>>>> elements?
>>>> Any examples or ideas would be greatly appreciated.
>>>> cheers,
>>>> /Torben
>>>> Artem Novikov <noviko...@gmail.com> Oct 13 07:02AM -0700
>>>> Parsing something using CLIPS is a bad approach.
>>>> Read about embedding CLIPS.
>>>> пятница, 12 октября 2012 г., 13:31:44 UTC+8
>> пользователь
>>>> Torben Bang
>>>> Nielsen написал:
>>>> You received this message because you are subscribed to the Google
>>>> Group clipsesg.
>>>> You can post via email.
>>>> To unsubscribe from this group, send an empty message.
>>>> For more options, visit this group.
>>>> -- >>>> You received this message because you are subscribed to the Google
>>>> Groups "CLIPSESG" group.
>>>> To post to this group, send email to CLIPSESG@googlegroups.com
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/CLIPSESG?hl=en
>>>> --> IF YOU NO LONGER WANT TO RECEIVE EMAIL <--
>>>> Visit this group at http://groups.google.com/group/CLIPSESG?hl=en >>>> Click on "Edit my membership" link.
>>>> Select the "No Email" radio button.
>>>> Click the "Save these settings" button.
>>>> --> IF YOU WANT TO UNSUBSCRIBE <--
>>>> Visit this group at http://groups.google.com/group/CLIPSESG?hl=en >>>> Sign in
>>>> Click on "Edit my membership" link.
>>>> Click the "Unsubscribe" button.
>>>> Note: This appears to be the most reliable way to unsubscribe
>>>> Alternately, send email to CLIPSESG-unsubscribe@googlegroups.com. You
>>>> will receive an email which you must respond to as well to
>>>> unsubscribe. Clicking the link mentioned in the unsubscribe reply
On 16 October 2012 08:01, Nick Bassiliades <nbass...@csd.auth.gr> wrote:
I have just been looking over some of your DEVICE work, and at a first
glance it looks most interesting!
> Unfortunately, there is no English report on this, only
> a Greek BSc thesis. However, I send it too, in case you would like
> to go through the XML and CLIPS code and the figure
> that are in there.
Is there a way the rest of us can get hold of this Greek BSc thesis?
Is it posted up somewhere?
> On 16 October 2012 08:01, Nick Bassiliades <nbass...@csd.auth.gr> wrote:
>> Unfortunately, there is no English report on this, only
>> a Greek BSc thesis. However, I send it too, in case you would like
>> to go through the XML and CLIPS code and the figure
>> that are in there.
> Is there a way the rest of us can get hold of this Greek BSc thesis?
> Is it posted up somewhere?
I compiled the CLIPSWin32CPP C++ project in the Microsoft Visual C++ 2008 and it went just fine, but I'm having a very hard time trying to register the CLIPSWin32.dll on Windows 7 (64bits). Any suggestions?
> On 16 October 2012 08:01, Nick Bassiliades <nbass...@csd.auth.gr > <mailto:nbass...@csd.auth.gr>> wrote:
> I have just been looking over some of your DEVICE work, and at a first > glance it looks most interesting!
> Unfortunately, there is no English report on this, only
> a Greek BSc thesis. However, I send it too, in case you would like
> to go through the XML and CLIPS code and the figure
> that are in there.
> Is there a way the rest of us can get hold of this Greek BSc thesis?
> Is it posted up somewhere?
> Thanks
> -- > You received this message because you are subscribed to the Google > Groups "CLIPSESG" group.
> To post to this group, send email to CLIPSESG@googlegroups.com
> For more options, visit this group at > http://groups.google.com/group/CLIPSESG?hl=en
> --> IF YOU NO LONGER WANT TO RECEIVE EMAIL <--
> Visit this group at http://groups.google.com/group/CLIPSESG?hl=en > Click on "Edit my membership" link.
> Select the "No Email" radio button.
> Click the "Save these settings" button.
> --> IF YOU WANT TO UNSUBSCRIBE <--
> Visit this group at http://groups.google.com/group/CLIPSESG?hl=en > Sign in
> Click on "Edit my membership" link.
> Click the "Unsubscribe" button.
> Note: This appears to be the most reliable way to unsubscribe
> Alternately, send email to CLIPSESG-unsubscribe@googlegroups.com. You > will receive an email which you must respond to as well to > unsubscribe. Clicking the link mentioned in the unsubscribe reply does > not appear to work reliably.
-- **************************************************************
* Dr. Nick Bassiliades, Associate Professor *
* Dept. of Informatics, Aristotle University of Thessaloniki *
* 54124 Thessaloniki, Greece *
* *
* Tel: +302310997913 E-mail: nbass...@csd.auth.gr *
* Fax: +302310997913 URL: http://tinyurl.com/nbassili *
* ========================================================== *
* LPIS (Logic Programming & Intelligent Systems) Group *
* URL: http://lpis.csd.auth.gr/ *
**************************************************************
