[Crm-sig] clarification needed

martin martin at ics.forth.gr
Thu Jul 10 15:46:49 EEST 2008

Guenther Goerz wrote:
> Dear Martin,
> Because your last comment is shown somewhere in the text below, let me
> answer here.  It's good to hear that my interpretation seems to match
> with your intention, but then I don't understand the question in your
> second paragraph.
> 1. Yes, "constant" is the term I used --- as opposed to "variable" ---
> to explain the term "nominal", which may not be familiar to people
> unfamiliar with description logics, to indicate that I talk about a
> linguistic object which is used as an identifier for an individual, or
> a "particular", if you prefer that.

In this case, an instance of Type cannot be a "constant". Instances of Type
are the concepts meant by the terms themselves, not the identifiers. Identifiers
in the CRM are instances of Appellation. This conforms with SKOS. Compatibility
of the CRM with SKOS is a desirable feature.

There are neither "Variables" in the CRM.

Yes, we prefer "particular".

> For general terms of logic, my
> terminological references are works as the (online) Stanford
> Encyclopedia of Philosophy or the Routledge Encyclopedia, not some
> coding experience you may associate. 
I wonder if this Encyclopedia regards "constants" and "variables" as
elements of an ontology. Are you sure? Please cite!

> Just a side remark: If you
> suggest "particular" as a central CRM term, there should be a separate
> entry for it in the glossary.  In 4.2.4, it is just mentioned in the
> entry on "universal".
Good point. This is an ISSUE!
> 2. Perhaps you could be so kind to explain in more detail what you
> mean by a mediation system where some instance of a table "agent"
> would have type "artist"... etc. It seems to me that you are referring
> to a relational data base with a schema which is not clear to me by
> your short remark. I'm not sure whether you are asking to introduce
> redundancy, which could be done, of course, but I don't see why.

With "mediation" system I mean what Gio Wiederholt described generally,
in particular here the problem to integrate typical Relational systems,
as we have seen dozens or hundreds, under a global model in a Knowledge
Representation system similar to RDFS. The Relational schema has a Table
"agent" with a field "type" and the value in some record for "type" is "artist".
I refer in particular to Local As View integration (LAV).
> My scenario was the following:
> We associate a (domain ontology) class Artist with the CRM as a
> subclass of E21 Person (just as FRBR classes are associated to CRM
> classes) and we can then generate instances of this class, e.g. the
> Artist "Vincent". We could modify that, of course, by instead make the
> class Artist a subclass of E39 Actor.  If this is your argument, I
> agree --- it's an improvement.  So, the Artist "Vincent" is an E39
> Actor and as such an E21 Person.  Furthermore, we generate an instance
> "Artist" (notice the string quotes) of E55 Type which is a term taken
> from a thesaurus (let it still be WordNet).  So, the example has to be
> modified in that now E39 Actor "Vincent" P2 has type E55 Type
> "Artist". I don't see the need for any further changes, in particular
> not to express something IN the thesaurus --- did you want to say
> BETWEEN the thesaurus and the CRM??   The subsumption relation in CRM
> in combination with the property P2 should be sufficient: From
> "Vincent" we could get by the inverse relation of P2 is type of to E55
> "Artist" and by the CRM subsumption hierarchy to E39 Actor and E21
> Person, etc. So, there is no redundancy, but, as I said, to keep
> semantic integrity --- i.e. that the meaning of the domain class
> Artist and the E55 Type "Artist" coincide --- is the business of the
> user who decides to use the E55 Type machinery.

Good. In that case, we have a duplication of all terms in the thesaurus with
corresponding classes specializing the CRM. If you suggest this as an implementation,
for UMLS for instance you have to create 5 million classes with some IsA
cycles in it. Why creating the subclass "artist" when you have the thesaurus?
> Now you brought in a new term, "agent", as the identifier of some
> (relational DBS) table.  Assuming that "agent" is also in the
> thesaurus, you could of course generate another instance of E55 Type:
> "Agent".
> If "Artist" in the thesaurus is a narrower term than "Agent", we can
> say that the thesaurus term "Agent" applies also "Vincent" because it
> is a more general term than "Artist" to which Vincent is already
> related by P2-inverse is type of: Referring to the thesaurus, whatever
> we call an artist can also be called an agent. This should at least
> cover a part of your question, but maybe I missed something due to the
> brevity of your remark.  If the term "Agent" is not in the thesaurus
> (it certainly is in WordNet...), we have to find another solution; in
> this case we could look whether there is a means to express that it is
> a synonym to some term in the thesaurus --- then the machinery works
> as well.
I actually meant that the mediator makes a mapping process, and
that "agent" maps to "E39 Actor". Then, "type" is either mapped to E55 Type,
or interpreted as a subclass statement for E39 Actor. There is a bunch of
literature about mediation systems.

> 3. Decidability: No, sorry, you are wrong. There is of course an
> equivalent of undecidability in procedural languages (and Turing
> machines --- this was Turing's point in his 1936 paper): endless loops
> or infinite recursion, resp.

Of course. Sorry for my short-hand. I have 20 years programming practice.
No reasonable programmer would let a procedure in an endless loop.
This is regarded as a bug in any good practice. My argument was, that
you can control the cases of undecidability in procedural code, and I still
insist on that. In that case, it is a question of the middleware, and not a
problem I have to circumvent compromising a semantically correct representation.

> For further details, see David Harel's
> nice book "Computers Ltd.: What They Really Can't Do" or some other
> textbook in Theoretical Computer Science on the halting problem.  That
> is the reason why I have been insisting on description logics (or
> OWL-DL), because for any sentence to prove or query to answer the
> reasoner stops and comes up with an answer. Provably, this is not the
> case for full first-order logic and of course for any more powerful
> languages (like those with metaclasses and any other higher order
> constructs).  And, although it seems to be just a theoretical issue,
> it is of utmost and immediate importance for practice (and
> practitioners): What does it help if someone can express whatever he
> wants but there are (provably) no means to decide whether it holds or
> not?
Of course it helps to know that there is no answer. Since when are questions
forbidden that have no answer? Most historical questions have no answer.
I thought, the argument was that the reasoner
crashes. Still I would like to see a real live example. The source Vladimir
pointed to actually describes narrower necessary conditions for undecidability
than the set of necessary conditions you describe. What I am looking
for is if a specific set of arguments we want to make on a metaclass level
leads into undecidability. Obviously, not all questions on metaclasses do that.



> Best regards,
> -- Guenther
> On 7/1/08, martin <martin at ics.forth.gr> wrote:
>> Dear Guenther,
>>  Guenther Goerz wrote:
>>> Dear Christian-Emil,
>>> it's pretty hard to get to your point because your text is truncated in
>>> the middle of a sentence at the end of the first paragraph.
>>> In your first sentence, you are referring to my "first stroke
>>> paragraph" which is, I think, the one in the <quotation> starting with
>>> "The usual way to attach concepts..."  What I am talking about here is
>>> to generate an "extension" of the CRM --- if at all --- only in the
>>> sense of attaching a domain ontology, i.e., concepts of a domain
>>> ontology to the (reference ontology) CRM as it is common in "ontology
>>> engineering".  It's just in the same fashion as FRBR concepts are
>>> connected to CRM concepts.
>>> For the following, there is no need to refer to OWL-DL at all --- it's
>>> only because the quotation was taken from a paper about the OWL-DL
>>> implementation of CRM.  Just think of First-Order Logic, or
>>> preferrably, a decidable subset of it.
>>> Now, for the "E55 type hierarchy": In my copy of the CRM document,
>>> v.4.2.4, it is mentioned in the introductory paragraph "On Types" ---
>>> the one we are discussing about --- on pp. 17f. and furthermore on
>>> pp. 51 (in the section on E55), 65, 74, 75.  In none of these places I
>>> found that a type hierarchy under E55 Type *SHOULD* have a subclass
>>> for each of the classes of the CRM.  Maybe I missed something, so
>>> please direct me to the proper text location.  It could have, of
>>> course, in particular cases.  Whether there are subclasses (for
>>> each??) of the classes of the CRM will in my opinion depend on the
>>> purpose of the particular modelling activity.  (Just a side remark
>>> w.r.t. infinite recursion: If this is serious, I think it is a
>>> conceptual bug and not a feature and it should be fixed as soon as
>>> possible.  This is another argument in favor of my remark that the
>>> text proposed to vote on is not technically mature.  And, by the way,
>>> referring to your earlier remarks about dissemination of the CRM: How
>>> would you explain to a practitioner that this makes sense, and if it
>>> does, what he could gain from it? I think my proposal would not allow
>>> infinite recursion in the sense that the "has-lexconcept" property
>>> mentioned below would have an inverse property pointing back to the
>>> one and only exemplar of the CRM.)
>>> Representing domain classes as subclasses of CRM-classes was my first
>>> idea as well.  And it will work fine regarding subsumption and
>>> inheritance.  In fact, reasoning can be done intensionally (i.e., on
>>> the formal expressions by which the classes are defined) as well as
>>> extensionally (i.e., on the set of all individuals belonging to a
>>> class).  But we have to be careful with E55 Type because the E55 class
>>> has in my view been conceived to provide a weak form of reification.
>>> If we want to keep a decidable version of the CRM we may not allow
>>> full reification (as in unrestricted RDF), because otherwise we could
>>> generate paradoxes with is due to its ability to express
>>> self-reference.  Now, for my mentioning of "contradiction" in the last
>>> sentence of the resp. paragraph which I think is what you refer to by
>>> "why this causes inconsistency": If we allow "artist" to be a subclass
>>> of E21 Person and at the same time to be a subclass of E55 Type, we
>>> are in trouble: E55 Type is a subclass of E28 Conceptual Object which
>>> is something immaterial, whereas an E21 Person is something material.
>>> So, we would have the artist Vincent, being material and immaterial at
>>> the same time.  This is in fact Martin's argument in the discussion of
>>> the last day of the Heraklion workshop in May (which you missed, if I
>>> remember correctly)
>>  To my understanding, the solution you describe below is exactly the current
>> state of
>>  the CRM. I do not prefer the term "constant", because it does not exist
>>  in the CRM, and comes from an encoding perspective, but rather use the
>>  term "particular".
>>  Note, that in a mediation system, the fact that an instance of a table
>> "agent"
>>  would have type "artist" may be used to decide that the instance is not
>> only an
>>  instance of Actor but also of E21 Person. In order to do so, we must
>> express
>>  a relationship in the respective thesaurus between "artist" and E21 Person.
>>  How would you do that?
>>  About the issue of decidability: To my understanding this issue occurs
>> only,
>>  if a declarative language is used. Procedural implementations would not
>> have
>>  this problem. The CRM however does not make any assumptions about the
>> implementation
>>  method.
>>  .
>>> Therefore, another solution has to be provided, which I did in my
>>> second "stroke paragraph", beginning with "Instead, a constant
>>> "Artist" may be used..."  So we have the E21 Person Vincent which P2
>>> has type E55 Type "Artist" (a nominal, i.e. a constant, not a
>>> subclass).  In this representation, we can reason with and on terms
>>> without problems, using the term hierarchy (which may be called an
>>> "E55 Type hierarchy").
>>> To avoid misunderstanding, let me point out what I would understand by
>>> a "E55 Type hierarchy": Take WordNet as a thesaurus --- cum grano
>>> salis, just for the sake of its easy availability --- , and take
>>> furthermore my "artist" example.  The hyperonymy in WordNet provides
>>> "creator" as a broader term to "artist" and "person" as a broader term
>>> to "creator".  Narrower terms to "artist" are "painter", "sculptor",
>>> etc.  In general, I would not claim that such a term hierarchy is a
>>> priori a class hierarchy in the sense of CRM and therefore I would
>>> hesitate to merge both.  I am aware that some people tried to turn
>>> WordNet itself into a formal ontology, but this is another story.
>>> Here I will hold up the claim that the super-/sub-class relation in
>>> the CRM is not *IDENTICAL* to the broader/narrower term relation in
>>> WordNet.  Now we could "navigate" in the CRM class hierarchy
>>> (i.e. perform subsumption inferences) and we could navigate in the
>>> WordNet hierarchy, but to mix both needs further justification.  First
>>> of all I think that a naive combination of both would make problems.
>>> But there is a more sophisticated way to combine both, namely the one
>>> I described in the third paragraph starting with "both representations
>>> are not mutually exclusive..."  Let me repeat that in this case the
>>> semantic integrity is within the user's responsibility.  In the last
>>> paragraph of my last mail I referred to a technical solution we found
>>> to do such a hybrid navigation by introducing a special property
>>> "has-lexconcept" (and its inverse).  With CRM, we would instead have
>>> E55 Type as the "interface" between CRM classes and terms from some
>>> thesaurus related by the property P2 has type (is type of).  Instances
>>> of CRM classes as E21 Person represent (domain) objects, whereas the
>>> WordNet entries just represent words (terms) and their use.
>>> With this background, let me try to understand your T21 example: Let's
>>> connect E21 Person via P2 has-type E55 Type to the WordNet term
>>> "person".  Making the transisition to WordNet, we could then navigate
>>> to the subconcepts I mentioned, like "artist" (or do you mean
>>> something different by a "person thesaurus"??).  Then we would find
>>> that the term ("lexical concept" as we use to call it, because in
>>> general it represents a synonym set which is an equivalence class)
>>> "artist"/WordNet is a narrower term of T21 "person"/WordNet. We might
>>> call the former T21-1 and we could use it to say by means of P2 that
>>> some E21 Person instance P2 has type E55 Type (T21-1)
>>> "artist"/WordNet.  Did I get you right???
>>> Best regards,
>>> -- Guenther
>>> On 6/22/08, Christian-Emil Ore <c.e.s.ore at edd.uio.no> wrote:
>>>> Dear Günther,
>>>>  One does not need to extend the CRM to get your first stroke paragraph.
>> The
>>>> CRM states that the class hierarchy under E55 type should have a sub
>> class
>>>> for each of the classes in the CRM.  This, of cause, opens for an
>> endless
>>>> recursion but that is not the point here. So for the class E21 Person
>> there
>>>> exists a sub...subclass of E55 Type, let us call it T21. The intention,
>> at
>>>> least according to my understanding, is that the terms in a Person
>> thesaurus
>>>> should be mapped to a type-(in the CRM sense) hierarchy under this type,
>>>> T21, corresponding to the formal structure of the thesaurus. An instance
>> of
>>>> E21 Person can then be connected via P2 to an instance of a subclass in
>> this
>>>> hierarchy or to an instance of T21 itself. Due to the generalisation
>>>> mechanism in the CRM all P2 insta
>>>>  The latter case corresponds to your artist case. Could you please
>> explain
>>>> to me without referring to rdf/owl why this causes inconsistency I just
>>>> don't understand your line of arguments.
>>>>  Regards,
>>>>  Christian-Emil
>>>>  On 13.06.2008 15:24, Guenther Goerz wrote:
>>>>> Dear all,
>>>>> As an attempt to clarify the problem of modelling alternatives with
>>>>> CRM-types --- this is the term I will use to distinguish it from other
>>>>> uses of "type", as e.g. in computer science --- let me start with
>>>>> quoting a section from the paper I submitted to the CIDOC 2008
>>>>> conference.  In order to avoid higher-order (logic) constructs which
>>>>> in my view are probably hard to comprehend for practitioners anyway,
>>>>> without excluding a weak form of reification completely, I suggested
>>>>> two ways of representation:
>>>>> <quotation>
>>>>> ``... E55 Type has been implemented as a class which ---
>>>>> for the purpose of reasoning on the conceptual level --- may serve as
>>>>> an interface to external concepts of formal domain ontologies (or
>>>>> thesauri) as subclasses or as constants.  In fact, at least two
>>>>> different representations are possible:
>>>>> - The usual way to attach concepts of a domain ontology to the CRM is
>>>>>  direct subclassing, e.g., the (application domain) class Artist as a
>>>>>  subclass of E21 Person.  So, ``Vincent van Gogh'' would be an
>>>>>  instance of Artist and inherit all properties of E21 Person.  In
>>>>>  that case to represent Artist also as a subclass of E55 Type would
>>>>>  lead to contradictions.
>>>>> - Instead, a constant ``Artist'' may be used; in general, it will be a
>>>>>  term of a domain-specific thesaurus.  Such constants
>>>>>  (``individuals'') are admitted in T-Boxes by means of the ``one-of''
>>>>>  OWL-DL language construct, i.e. an enumeration datatype.  They
>>>>>  correspond to classes with singleton extensions.  So, we could
>>>>>  represent ``Vincent van Gogh'' as an immediate instance of E21
>>>>>  Person and relate it by P2 has type to E55 Type with value
>>>>>  ``Artist''.  In this case, of course, the constants cannot have
>>>>>  instances in turn.
>>>>> Both representations are not mutually exclusive; in our example the
>>>>> name of the class Artist (case 1) could additionally be used as a
>>>>> constant which is assigned as a value to E55 Type (case 2), but then
>>>>> it is up to the user to guarantee for semantic integrity.  In the
>>>>> second case the intention expressed in the CRM document is supported
>>>>> that is shall be possible to deal with domain concepts --- such as
>>>>> Artist --- as objects of discourse.  Which of these representations
>>>>> will be chosen for a particular application will depend on the
>>>>> intended use of the domain model.''
>>>>> </quotation>
>>>>> What I am proposing here is to provide possibilities to argue with and
>>>>> about terms, i.e. use terms in reasoning in a ``de re'' and a ``de
>>>>> dicto'' mode.
>>>>> De re corresponds to the first way of representation: We introduce
>>>>> domain level classes as subclasses of CRM-classes.  The domain level
>>>>> classes may have subclasses in turn as, e.g., Painter and Sculptor as
>>>>> subclasses of Artist; so all of our instances from, e.g., a museum
>> data
>>>>> base are instances of the domain ontology which in turn is connected
>>>>> to CRM as a reference ontology.  In Description Logic (OWL-DL),
>>>>> reasoning with classes (concepts) is possible
>>>>> - intensionally, i.e. in terms of their defining expressions (T-Box),
>>>>>  or
>>>>> - extensionally, i.e. in terms of their instances (A-Box = extension,
>>>>>  i.e. the set of instances).
>>>>> It is important to keep in mind that we have an ``open world''
>>>>> semantics, i.e. if we have as a necessary condition for a FATHER that
>>>>> he is a PERSON and that Exists some CHILD, which is a PERSON,
>>>>> (``existential restriction''), we can represent an instance of a
>>>>> PERSON who claims to be a father without representing explicitly the
>>>>> particular CHILD --- in open world semantics ``I don't know'' is a
>>>>> legitimate answer to the question for a child.  On the other hand,
>>>>> there may be two PERSONS claiming to be the father of some particular
>>>>> CHILD (probably a rare case in the real world...), if we do not
>>>>> combine the existential restriction with a cardinality restriction,
>>>>> i.e., that there must be exactly one father for any CHILD.
>>>>> De dicto corresponds to the second way of representation: We introduce
>>>>> a constant as the value of E55 Type.  In this case, we can reason
>>>>> about the term itself, and not about its denotation.  If we use a
>>>>> thesaurus where a broader term for ``Artist'' were ``Person'' and
>>>>> narrower terms were ``painter'', ``sculptor'', etc., we can reason in
>>>>> the narrower-term--broader-term thesaurus hierarchy as opposed to the
>>>>> class hierarchy in the domain.  Formally, in both cases we have a
>>>>> subsumption hierarchy; in our example on the one hand a class
>>>>> hierarchy which contains CRM classes with integrated domain classes
>>>>> which have a denotation in the domain (de re), in the second case in a
>>>>> thesaurus hierarchy of terms which don't have instances (de dicto).
>>>>> As mentioned above, there may be combinations where the terms are
>>>>> related to domain classes by a particular property such as (an
>>>>> extended version of) P2 has type.
>>>>> The latter situation reminds me of a technique we applied in our NLP
>>>>> work where we have a domain ontology representing a rich domain
>>>>> semantics on the one hand and a hierarchical lexicon --- WordNet in
>>>>> our case --- on the other hand.  The ``terms'' above would correspond
>>>>> to WordNet's ``synsets'', i.e. sets of synonymous words.  As synonymy
>>>>> is an equivalence relation, we have a typical case of an abstraction
>>>>> from word to (lexical) concepts: Each word in the synset may represent
>>>>> the equivalence class.  Then we introduced a property
>>>>> ``has-lexconcept'' into the ontology which relates domain concepts to
>>>>> the lexical concepts, i.e. words by which they are expressed.  But
>>>>> this relation has to be maintained by the system implementors and must
>>>>> be handled with care: Of course, it's up to them to care for semantic
>>>>> integrity.  We can reason within the domain class hierarchy, as well
>>>>> as within the lexical concept hierarchy (WordNet), but combined
>>>>> inferences are possible as well.  In the case of subsumption
>>>>> inferences, e.g., given a certain (domain) class and, by virtue of
>>>>> lex-concept, the corresponding lexical concept(s), we could ask for
>>>>> its superclass and the words it is related to.  Furthermore, we can
>>>>> stay in the WordNet hierarchy, look for the broader lexical concept
>>>>> (synset), and ask for the domain concept it corresponds --- if there
>>>>> is one --- to by virtue of the inverse relation to has-lexconcept.
>>>>> Best,
>>>>> -- Guenther
>>>>> On 6/9/08, Vladimir Ivanov <nomemm at gmail.com> wrote:
>>>>>> ---------- Forwarded message ----------
>>>>>>  From: Vladimir Ivanov <nomemm at gmail.com>
>>>>>>  Date: 2008/6/9
>>>>>>  Subject: Re: [Crm-sig] About Types: ISSUE PLEASE VOTE
>>>>>>  To: Guenther Goerz <guenther.goerz at gmail.com>
>>>>>>  Dear Guenther,
>>>>>>  > Section 9: I don't understand it at all.  Could you please
>> explain
>>>> ---
>>>>>>  > and perhaps also the colleagues who already voted for the text as
>> a
>>>>>>  > whole what they understand?  As a side remark, I cannot make any
>>>> sense
>>>>>>  > out of the last sentence.
>>>>>>  The only sense of the last sentence I've made, was its
>> correspondence
>>>>>>  to OWL Full language.
>>>>>>  If one allows to treat "E55.Types" both as classes and as
>> instances,
>>>>>>  you may face to problems with reasoning.
>>>>>>  Excerpt from OWL spec. (http://www.w3.org/TR/owl-ref/):
>>>>>>  "... However, use of the OWL Full features means that one loses
>> some
>>>> guarantees
>>>>>>  that OWL DL and OWL Lite can provide for reasoning systems."
>>>>>>  these "guarantees" are related to decidability of reasoning.
>>>>>>  "Inference in OWL Full is clearly undecidable as OWL Full does not
>>>>>>  include restrictions
>>>>>>  on the use of transitive properties which are required in order to
>>>> maintain
>>>>>>  decidability." from
>> (http://www.cs.man.ac.uk/~horrocks/Publications/download/2005/Horr05c.pdf
>>>>>>  , p.2)
>>>>>>  As for the sect. 9 as a whole,
>>>>>>  I think the main idea was that
>>>>>>  "you may implement a system of user-defined types (subclasses of
>> E55
>>>>>>  and properties)
>>>>>>  at necessary (in your application) level of granularity, but it
>> should
>>>>>>  correspond to the CRM notion of type".
>>>>>>  Best regards,
>>>>>>  Vladimir.
>>>>>>  >
>>>>>>  > Best,
>>>>>>  > -- Guenther
>>>>>>  >
>>>>>>  >
>>>>>>  > On 6/4/08, martin <martin at ics.forth.gr> wrote:
>>>>>>  >> Dear All,
>>>>>>  >>
>>>>>>  >>  Following the decision in the last meeting, we have to decide
>> via
>>>> e-mail
>>>>>>  >> vote on
>>>>>>  >>  the updated  attached text about types in the CRM document. I
>> have
>>>>>>  >> desparately tried to
>>>>>>  >>  describe as exact as possible what the CRM does, and to avoid
>> the
>>>> metaclass
>>>>>>  >>  question, once this is a philosophical rather than an applied
>>>> question in
>>>>>>  >> the
>>>>>>  >>  current form the CRM describes.
>>>>>>  >>
>>>>>>  >>  Please VOTE:
>>>>>>  >>
>>>>>>  >>  ACCEPT [ ]
>>>>>>  >>
>>>>>>  >>  REQUEST MODIFICATION: [....]
>>>>>>  >>
>>>>>>  >>  by June 12.
>>>>>>  >>
>>>>>>  >>  Best,
>>>>>>  >>
>>>>>>  >>  Martin
>>>>>>  >>  --
>>>>>>  >>
>>>>>>  >>
>> --------------------------------------------------------------
>>>>>>  >>   Dr. Martin Doerr              |  Vox:+30(2810)391625        |
>>>>>>  >>   Principle Researcher          |  Fax:+30(2810)391638        |
>>>>>>  >>                                |  Email: martin at ics.forth.gr |
>>>>>>  >>                                                              |
>>>>>>  >>                Center for Cultural Informatics               |
>>>>>>  >>                Information Systems Laboratory                |
>>>>>>  >>                 Institute of Computer Science                |
>>>>>>  >>    Foundation for Research and Technology - Hellas (FORTH)   |
>>>>>>  >>                                                              |
>>>>>>  >>   Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece |
>>>>>>  >>                                                              |
>>>>>>  >>          Web-site: http://www.ics.forth.gr/isl               |
>>>>>>  >>
>> --------------------------------------------------------------
>>>>>>  >>
>>>>>>  >>
>>>>>>  >> _______________________________________________
>>>>>>  >>  Crm-sig mailing list
>>>>>>  >>  Crm-sig at ics.forth.gr
>>>>>>  >>
>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>>>>>  >>
>>>>>>  >>
>>>>>>  >>
>>>>>>  > _______________________________________________
>>>>>>  > Crm-sig mailing list
>>>>>>  > Crm-sig at ics.forth.gr
>>>>>>  >
>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>>>>>  >
>>>>>>  _______________________________________________
>>>>>>  Crm-sig mailing list
>>>>>>  Crm-sig at ics.forth.gr
>>>>>>  http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>>>> _______________________________________________
>>>>> Crm-sig mailing list
>>>>> Crm-sig at ics.forth.gr
>>>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>> _______________________________________________
>>> Crm-sig mailing list
>>> Crm-sig at ics.forth.gr
>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>  --
>> --------------------------------------------------------------
>>   Dr. Martin Doerr              |  Vox:+30(2810)391625        |
>>   Principle Researcher          |  Fax:+30(2810)391638        |
>>                                |  Email: martin at ics.forth.gr |
>>                                                              |
>>                Center for Cultural Informatics               |
>>                Information Systems Laboratory                |
>>                 Institute of Computer Science                |
>>    Foundation for Research and Technology - Hellas (FORTH)   |
>>                                                              |
>>   Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece |
>>                                                              |
>>          Web-site: http://www.ics.forth.gr/isl               |
>> --------------------------------------------------------------


  Dr. Martin Doerr              |  Vox:+30(2810)391625        |
  Principle Researcher          |  Fax:+30(2810)391638        |
                                |  Email: martin at ics.forth.gr |
                Center for Cultural Informatics               |
                Information Systems Laboratory                |
                 Institute of Computer Science                |
    Foundation for Research and Technology - Hellas (FORTH)   |
  Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece |
          Web-site: http://www.ics.forth.gr/isl               |

More information about the Crm-sig mailing list