Re: A final set of issues with the specification

Dear Francesca,

  thanks, I was there already: 
http://54.183.42.206:8080/sigma/Browse.jsp?kb=SUMO&lang=EnglishLanguage&flang=SUO-KIF&term=Giving

However, I wonder how to get out the "thematic roles" of the concept 
"Giving" from the page. It mentions "agent", "patient", "destination" in 
the KIF axioms, but it says nowhere explicitly that there are the 
expected thematic roles of "Giving".

Or do I miss something?

Philipp.

Am 08.09.15 um 12:25 schrieb QUATTRI, Francesca [11901993r]:
>
> Hi Philipp,
>
>
> regarding SUMO: Maybe you can try
>
> http://www.adampease.org/OP/ > Browse (top of the page) > KB term and 
> Graph (top right corner, same page).
>
> Adam developed an easy-to-read tree structure that allows you to 
> retrieve the direct children of an upper concept without going through 
> the first order logic.
>
> If you change the cardinal number in "Level "above"" and "level 
> "below"" in the Graph page, you can go up to Entity and see all the 
> direct children below.
>
>
>
> Regards,
> Francesca
>
>
> ------------------------------------------------------------------------
> *From:* Philipp Cimiano <cimiano@cit-ec.uni-bielefeld.de>
> *Sent:* Tuesday, September 8, 2015 4:54 PM
> *To:* public-ontolex@w3.org
> *Subject:* Re: A final set of issues with the specification
> Dear all,
>
>  thanks for all your comments so far. I went today in detail over the 
> synsem module, correcting minor things in the definitions, examples etc.
>
> I think that the synsem module is also finished.
>
> To Elena: the reason I used http://ontology.org/giving as a ficticious 
> dummy-concept to represent a change of possession in some ontology. I 
> simply haven't bothered to find an appropriate concept from a real 
> ontology. This is unfortunate as the domain http://ontology.org exists 
> and resolves... You can download "Big Data" at this URL btw. *lol*
>
> I have been browsing SUMO this morning and there is such a concept 
> (Giving as subclass of ChangeOfPossession). So we could point to sumo. 
> The actual properties used in SUMO, however, seem to be the generic 
> "agent", "patient" etc.
>
> Do you think we should use SUMO for illustration here?
>
> Any SUMO experts on this list?  I do not find an easy way to find the 
> "role" names for a process such as "Giving" from the SUMO browser. One 
> can read the KIF axioms and imagine what the role names are, but I was 
> wondering if there is a better way...
>
> The same holds for the example for the condition property. John has 
> used meansOfTransportation as an invented property. If anyone find an 
> ontology with such a concept I would be grateful. It costs a lot of 
> time to look around for ontologies with the appropriate properties.
>
> All: I have rewritten a bit the section on "condition". Please check 
> if the text and examples are aligned and are clear.
>
> Btw: there is not a single mention anymore in the spec to "semantic 
> arguments" ;-)
>
> Elena: to the question: when is a property named linked to the actual 
> ontology in which the property is defined? Good question. At least, 
> the first reference to the property should be linked to the external 
> ontology. It is possible that I have linked future references to the 
> property as well. I think we can a bit lenient here.
>
> The same holds for when to link to the definition of a property / 
> class in ontolex itself, I have not followed a clear principle here. I 
> am not sure it is really worth it though because I am not sure if the 
> conversion to the HTML report will preserve all the intra-document 
> links we have bothered to set. We will have to set them manually in 
> the worst case I guess.
>
> We need to regenerate the figures for the examples in the synsem 
> section still.
>
> Best regards,
>
> Philipp.
>
>
>
> Am 02.09.15 um 15:45 schrieb Elena Montiel Ponsoda:
>> Dear all,
>>
>> Hope you all had a great holiday time.
>> Thanks for this summary. Between lines, some comments by Lupe and 
>> myself.
>>
>> Best,
>> Elena
>>
>> El 26/08/2015 a las 17:51, John McCrae escribió:
>>>
>>>
>>> On Wed, Aug 26, 2015 at 2:16 PM, Philipp Cimiano 
>>> <cimiano@cit-ec.uni-bielefeld.de> wrote:
>>>
>>>     Hi John,
>>>
>>>        thanks for the summary of open issues. I comment on them....
>>>
>>>     Am 24.07.15 um 13:37 schrieb John P. McCrae:
>>>>     Hi all,
>>>>
>>>>     I made a thorough read-through of the specification and have
>>>>     some comments. There are five points that may be controversial
>>>>     and another /few/ that should not be.
>>>>
>>>>     *Important points*
>>>>
>>>>     1. We do not given the abbreviation of "lexicon model for
>>>>     ontologies" as "lemon" although the term lemon is used at
>>>>     several points in the document. Do we agree that the model is
>>>>     called "lexicon model for ontologies" and abbreviated as
>>>>     "OntoLex-Lemon"?
>>>     Indeed, I propose we use the acronym lemon in the document, but
>>>     in the introduction we should have the long name. I have fixed
>>>     this already.
>>>
>>>>
>>>>     2. ontolex/example12 is very difficult to understand now that
>>>>     we have named this property "context" and not "usage". The idea
>>>>     that "riviere" can be extended with a usage note "A riviere is
>>>>     a river that flows into the sea" makes sense but it is not
>>>>     clear why the usage note is called a "context"... we need to
>>>>     either clearly justify this or rename the property to "usage".
>>>>     I prefer the latter option. (see also point 28)
>>>
>>>     True, I propose to move this example down where we discuss the
>>>     usage property.
>>>
>>> There is no "usage" property, we renamed it to "context".
>> After having a look at some bibliography on lexicography, we also 
>> agree on renaming the property "context" to "usage". It is considered 
>> general enough to refer to several types of "conditions" in which the 
>> use of a certain term is justified (context, domain, style, register, 
>> meaning nuances, connotations, etc.)
>>>
>>>
>>>>
>>>>     3. The vartrans:category "property indicates the specific type
>>>>     of a relation", we already have a property to do this namely
>>>>     rdf:type! It is not clear to me from the text why we need to
>>>>     redefine this property. (i.e., either we need to better justify
>>>>     this or drop this property)
>>>     No clear opinion about this yet.
>>>
>> The*category*property indicates the specific type of relation by 
>> which two lexical entries or two lexical senses are related.
>> Indeed, the definition may seem a bit general. However, the rdf:type 
>> property seems to us as"too underspecified" (and, therefore, not 
>> worthy of being included in the vartrans module...) and maybe not 
>> familiar to the linguistic community.
>> We propose to slightly modify the definition as 
>> "The*category*property indicates the specific type of 
>> *lexico-semantic relation* by which two lexical entries or two 
>> lexical senses are related"
>> And add an explanation in this line: This property is meant to 
>> capture different lexical and semantic relations of the sort: 
>> initialism, ortographic variant, dialectal or geographic variant, 
>> register variant, chronological variant, stylistic variant, 
>> dimensional variant, synonymy, antonymy, or translation. A set of 
>> lexico-semantic relations are available in the lexinfo vocabulary.
>> (A nice list of these types of variation and translation relations 
>> was included some time ago at: 
>> http://www.w3.org/community/ontolex/wiki/Specification_of_Requirements/Properties-and-Relations-of-Entries)
>>
>> Finally, ObjectProperty: Category, should be in small letters, right?
>>>
>>>>
>>>>     4. Lime defines a number of properties that are of the form
>>>>     "the number of links from X to Y divided by the total number of
>>>>     X" for example lime:avgNumOfLexicalizations is "the number of
>>>>     links from references to lexical entries divided by the total
>>>>     number of references". This can be put into a table as follows:
>>>>
>>>>     X/Y 	References 	Entries 	Concepts
>>>>     References 	- 	|avgNumOfLexicalizations| 	|avgNumOfLinks|
>>>>     Entries 	|percentage| 	- 	|avgAmbiguity|
>>>>     Concepts 	? 	|avgSynonymy| 	-
>>>>
>>>>
>>>>     The table reveals a few inconsistencies in that we have a
>>>>     missing property and the percentage property should perhaps be
>>>>     named something like avgPolysemy
>>>>
>>>>     5. As the NIF "community" has not responded to our questions,
>>>>     we are forced to drop recommendations of linking using NIF, and
>>>>     instead only recommend OpenAnnotation.
>>>
>>>     Not sure yet.
>>>
>> We wouldn't be so sure of leaving NIF out. It is quite well-known in 
>> the community, don't you think so?
>>>
>>>>
>>>>     *Not-so-important points*
>>>>
>>>>     (JPM) means I will try and fix them within the next two weeks
>>>>
>>>>     6. "Document is structured into eight sections" only there are
>>>>     nine (JPM)
>>>
>>>     Yes.
>>>>
>>>>     7. The first paragraph of the introduction is very academic,
>>>>     perhaps it could be rewritten to be more appealing to a general
>>>>     audience. (JPM)
>>>
>>>     I am not sure about the "academic", but I am ok if you work on it.
>>>>
>>>>     8. "sublcass" and a number of other basic spelling errors exist
>>>>     throughout the document. We must spell-check the document! (JPM)
>>>
>>>     Yes. I spotted some of those already today while doing a first
>>>     pass over the document.
>>>
>>>>
>>>>     9. ontolex/example4 uses "/" around the IPA representations of
>>>>     the terms. I don't think that this is necessary. We should also
>>>>     explain the language tag and reference the IANA subtag catalogue.
>>>
>>>     OK, can you please look into this.
>>>>
>>>>     10. There is little consistency about whether we write "lexical
>>>>     entry" or "LexicalEntry" or use a fixed-width font. (JPM I
>>>>     prefer the real English 'lexical entry')
>>>>
>>>     Yes, we should use small case here, that is 'lexical entry'.
>>>
>>>>     11. Similarly we should check that terms like "rdfs:label" are
>>>>     always fixed-width (JPM)
>>>>
>>>     ok
>>>
>>>>     12. "with canonical form the noun" !? (JPM)
>>>>
>>>     fixed
>>>
>>>>     13. ontolex/example6 seems to duplicate ontolex/example1
>>>
>>>     Not really. Becasue in example1 we did not have the writtenRep
>>>     etc. So this example is incremental. I think it is fine.
>>>
>>> "Lexical entries are further specialized into words, affixes (e.g., 
>>> suffix, prefix, infix or circumfix) and multiword expressions." then 
>>> ontolex/example1
>>>
>>> "Of course, lexical entries need not to correspond to one word only, 
>>> they can correspond to a multi-word term, as the following example 
>>> for the lexical entry "intangible assets" shows:" then ontolex/example6
>>> ontolex/example6 seems to repeat the point and it is not clear why 
>>> it does, could you revise the text before ontolex/example6?
>>>
>>>
>>>>
>>>>     14. We need an example showing how we represent abbreviations
>>>>     relative to their full forms (JPM)
>>>
>>>     True, can you add one example...
>>>>
>>>>     15. In the definition of "other form" we should probably not
>>>>     say "non-dictionary" but "non-lemma". (JPM)
>>>
>>>     Yes, agreed.
>>>
>> We would rather say "non-lemmatic form".
>>>
>>>>
>>>>     16. ontolex/example10 is still not good. The "bank" part of the
>>>>     example makes no sense as it is two separate entries with
>>>>     separate meanings, but it is not well explained why "bank" is
>>>>     two entries. The second part of this example uses the word
>>>>     "apothecary", which is a highly unusual word in English and I
>>>>     would not (personally) say is truly synonymous with
>>>>     "pharmacist". I had suggested using "troll" as the example
>>>>     here, but that seems not to have been adopted. Perhaps we also
>>>>     need a separate example explaining "bank" here too? (JPM)
>>>     I think the example is fine. Why does "bank" make no sense? The
>>>     example gives guidance to people about how to model multiple
>>>     meanings of a word.
>>>
>>> We don't explain why "bank" is two lexical entries and 
>>> "apothecary"/"troll" is one.
>>>
>>>     The case of bank shows the case where there are two different
>>>     entries for the word and both the lexical entries and the
>>>     meanings are unrelated.
>>>     The case of "apothecary" is the other case in which there is one
>>>     lexical entry with two meanings.
>>>
>>>     I am fine though if we replace the "apothecary" example by the
>>>     "troll example".
>>>
>>>     It seems that both meanings are indeed in DBpedia:
>>>
>>>     http://de.dbpedia.org/page/Troll_(Mythologie)
>>>     <http://de.dbpedia.org/page/Troll_%28Mythologie%29>
>>>     https://de.wikipedia.org/wiki/Troll_(Netzkultur)
>>>     <https://de.wikipedia.org/wiki/Troll_%28Netzkultur%29>
>>>     Ok then.
>>>
>> We think that it would be clearer if we divide the example into two 
>> separated examples.
>> As for the explanation included below the example, and I quote: "In 
>> the above example, two lexical entries have been used for/bank/. The 
>> reason is that in this case both words/bank/are actually not 
>> grammatically related and thus represent two independent lexical 
>> entries with meanings that are not related", we are of the opinion 
>> that the statement "are actually not grammatically related" is 
>> unnecessay, since morphologically they have the same sequence of 
>> letterns and are both nouns. Moreover, in a dictionary the entry 
>> would be the same. So we propose to simply remove "are actually not 
>> grammatically related and thus".
>>>
>>>>     17. ontolex/example12 is listed in the text as
>>>>     synsem/example12! (JPM)
>>>
>>>     ok.
>>>>
>>>>     18. Terms like 'Lexicon' and 'Lexical Entry' should not be
>>>>     capitalized they are not proper nouns (JPM)
>>>
>>>     Yes.
>>>>
>>>>     19. The lexical concept can be better explained as follows: The
>>>>     reference in the ontology primarily gives an interpretation of
>>>>     a word in terms of the identifiers that would be generated by
>>>>     the semantic parsing of the sentence. For example if we were to
>>>>     understand the query "when did John Lennon die?" we may
>>>>     understand the word "die" as generating the URI
>>>>     dbpedia:deathDate within a SPARQL query. In contrast many
>>>>     resources will also wish to record the intentional meaning of
>>>>     the word with the mental lexicon, such as "die" referring to
>>>>     the concept of death, for this reason we introduce the class
>>>>     lexical concept which can be evoked by a lexical entry in place
>>>>     of or as well as a denotation in the ontology, e.g.,
>>>>
>>>>      :die a ontolex:Word ;
>>>>        ontolex:denotes dbpedia:deathDate ;
>>>>        ontolex:evokes  wordnet:Dying .
>>>>     (JPM)
>>>
>>>     OK, but I would add this in addition to the explanation we have
>>>     as an elaboration. I like the way you have phrased this.
>>>
>> We agree with adding this as an explanation, but not modifying the 
>> definition.
>>>
>>>>
>>>>     20. Capitalization in definition of OntoMap is wrong. (JPM)
>>>
>>>     Why is it wrong?
>>>>
>>>>     21. I don't like the paragraph 'An OntoMap resembles the
>>>>     SynSemCorrespondence...' as
>>>>     The OntoMap does not really resemble synsemcorrespondence
>>>>     I don't think we should compare to a closed standard like LMF
>>>>     that is unfamiliar to most of our audience
>>>>     Talking about semantic arguments will only create more confusion
>>>
>>>     Well, this is a major issue that I will bring up soon. I indeed
>>>     see the OntoMap as the ontolex counterpart to the
>>>     SynSemCorrespondence. In fact, I will argue not to regard
>>>     OntoMap as a subclass of Lexical Sense. But let us not open this
>>>     box today... ;-)
>>>
>>> I thought (actually hoped) this was closed too.
>>>
>>>
>>>>
>>>>     22. All "dbpedia:" URIs should be fixed width (JPM)
>>>
>>>     This point is not clear to me, sorry.
>>>
>>> Anything staring "dbpedia:" should be in fixed width
>>>
>>>
>>>>
>>>>     23. Some examples use "dbonto" and some "dbpedia"...
>>>>     inconsistent. (JPM)
>>>
>>>     Well, there are different namespaces in DBpedia as well. Should
>>>     we be more consistent that DBpedia? We could try to stick to the
>>>     ontology namespace however...
>>>
>>> We should be consistent, dbpedia: sometimes is short for 
>>> http://dbpedia.org/ontology/ <http://dbpedia.org/ontology/> and 
>>> sometimes for http://dbpedia.org/resource/ 
>>> <http://dbpedia.org/resource/> and sometimes should be short for 
>>> http://dbpedia.org/property/ but isn't
>>>
>>>
>>>>
>>>>     24. "The verb (to) launch" needs quotation marks (JPM)
>>>
>>>     OK
>>>>
>>>>     25. "Complex ontology mappings / submappings" talks about
>>>>     semantic arguments but this is confusing
>>>
>>>     Not sure why this is confusing. I still see the subject and
>>>     object position of a triple as arguments of the triple. Maybe
>>>     the term "semantic" is confusing here?
>>>
>>> I want to remove any discussion of "semantic arguments" from this 
>>> spec, these will be introduced in a future module (per the most 
>>> recent agreement).
>>>
>>>
>>>>
>>>>     26. Indentation of synsem/example8 needs to be fixed (JPM)
>>>
>>>     OK
>>>>
>>>>     27. "If element x decides if x"... this is not a maths paper,
>>>>     use English. (JPM)
>>>     This comes from me. I though this makes it clear that with isA
>>>     we refer to the lambda-abstracted variable of a lambda
>>>     expression or to the argument of a function that characterizes
>>>     the set. I find this quite clear and think that it is
>>>     understandable as such. But we can add an English sentence that
>>>     clarifies this a bit.
>>>
>>>>
>>>>     28. condition is defined as a subproperty of usage (JPM, see
>>>>     point 2)
>>>>
>>>>     29. "not found in many other languages" => "not found in some
>>>>     other languages and more importantly in some ontologies" (JPM)
>>>
>>>     ok
>>>>
>>>>     30. I am not sure from a linguistic point of view that it is
>>>>     correct to say that "otitis" is composed of the affix "itis" in
>>>>     decomp/example3. In particular there is no Spanish word "ot"
>>>>     and "-itis" is a Greek inflection not a true suffix. An easier
>>>>     example would be with a normal prefix such as "un-", "re-" or
>>>>     "dis-"...
>>>     Well, it is. It is clearer if we use the term "apendicitis" In
>>>     which "itis" again means inflammation. "apendic" stands for
>>>     appendix. Is that better?
>>>
>>> "Appendic" is still not a word... we could choose an example which 
>>> is clearer, e.g., "un-"...
>> Appendic is not a word, but appendix + itis, or apéndice + itis (and 
>> the e is dropped)
>> The suffix is added to the root, as in the case of "ot" + "itis"
>> otos means "related to the ear" (referido al oído)
>>
>>>
>>>
>>>>
>>>>     31. It appears that order information has been added to
>>>>     decomp/example6... this is not necessary if we know that order
>>>>     of the words from the main entry and this representation
>>>>     actually saves a triple (ergo IMHO is superior!)
>>>>
>>>>       :AfricanSwineFever a ontolex:MultiwordExpression ;
>>>>         rdf:_1 African_node ;
>>>>         rdf:_2 Swine_node ;
>>>>         rdf:_3 Fever_node .
>>>
>>>     It does not hurt to add this information. Because the order is
>>>     only implicit in the lexical entry. One would need to tokenize
>>>     the lexical entry to get the order... Saving triples is not
>>>     always good if one looses information that needs to be recovered...
>>>
>>> Either way you have to recover some information. If you keep the 
>>> example as is then the tokenization of the lexical entry needs to be 
>>> recovered, if you switch to my model the parse order needs to be 
>>> recovered, but tokenization is more useful and efficient to represent.
>> Why would it be more useful and efficient? Could you explain this?
>>>
>>>
>>>>
>>>>     32. "adjective -> adverb variation" not sure what "minus
>>>>     greater than" means here. (JPM change to arrow)
>>>>
>>>>     33. "Translation" section lists the "following ways [of
>>>>     representing translation] of increasing ontological
>>>>     strength"... but they are clearly not increasing! I am not
>>>>     really sure what ontological strength means.
>>>
>>>     This comes from me. I will revise it.
>>>>
>>>>     34. The diagram for lime metadata needs to be updated. (JPM)
>>>>
>>>>     35. lime/example2 "jnp" => "jpn" (JPM)
>>>>
>>>>     36. I have a comment on "Verb form mood" that appears to never
>>>>     have been answered. I assume that my merge has no objections. (JPM)
>>>>
>>>>     Regards,
>>>>     John
>>>
>>
>> Some more spotted misspellings and stylistic nuances:
>>
>> *Domain:*LexicalSense
>>
>> *Range:*rdfs:Ressource
>>
>> The combined usage of the properties denotes, sense, evokes, concept 
>> and lexicalized sense is demonstrated in the example below for the 
>> case of a lexical resource such as WordNet.
>>
>> OntoLex/Lemon has a much simpler usage, removing many elements that 
>> were in LMF
>>
>> The following example gives an example of a sense relation:
>>
>> Proposal:
>>
>> The following example illustrates a sense relation:
>>
>> The following example shows how to model the relation between "Food 
>> and Agriculture Organisation" and its initialism "FAO" as one example 
>> of a lexical relation
>>
>> Proposal:
>>
>> The following example shows how t_o model the lexical relation 
>> between_ "Food and Agriculture Organisation" and its initialism "FAO"
>>
>> In the introductory paragraph to Syntactic Frames, we think it should 
>> be: stand *on *their own, and not *by *their own
>> In the definition of Syntactic Frame, the definite article "the" is 
>> missing in "in terms of the (syntactic) arguments"
>>
>> A comma is missing in the sentence below "... the preposition in*,* ..."
>> The following example shows how to specify that the intransitive 
>> verb/operate/, subcategorizing a prepositional phrase introduced by 
>> the preposition/in/can be used to denote the propertyregionServed 
>> <http://dbpedia.org/ontology/regionServed>in DBpedia
>>
>> In the next sentence, examples should be in singular:
>> The following example*s* shows how to use thesubmap 
>> <http://www.w3.org/community/ontolex/wiki/Final_Model_Specification#Submap>property 
>> to indicate that the meaning of the phrase "X launched Y in Z" is a 
>> composition of the propertiesdbpedia:product 
>> <http://dbpedia.org/ontology/product>anddbpedia:productionStartYear 
>> <http://dbpedia.org/ontology/productionStartYear>, which together 
>> express the meaning of the syntactic frame
>>
>> In the following sentence below example 6, quantifier should be 
>> quantifying
>> "Indicating that an argument is optional means that it does not have 
>> to be realized syntactically in which case from a semantic point of 
>> view the corresponding semantic argument is existentially quantifier 
>> over."
>>
>> In the definition of Optional, we would avoid the use of "optional" 
>> in the explanation, and say instead: The optional property indicates 
>> that a syntactic argument can be omitted.
>> The*optional*property indicates whether a syntactic argument is 
>> optional, that is, it can be syntactically omitted.
>>
>> In example 7 (Optional): a slash is missing, see:
>>   ontolex:reference<http:/ontology.org/giving>;
>> BTW, is http://ontology.org/giving correct???
>>
>> In example 9 there is a mispelling in Transportation, see:
>>
>> :methodOfTransporation a rdf:Property ;
>> Is this example complete? shouldn't it be pointing to an ontology??
>>
>> Below example decomp/example 2
>> Revise the following sentence (verb is at the end...)
>> "It is important to note that the subterm property does not indicate 
>> the position or even which words a subterm is."
>>
>>
>>
>> Finally, we see that sometimes the names of classes or properies have 
>> hyperlinks, but not always. Which should be the criterion to follow?
>> See for example the paragraph below in which regionServed is 
>> sometimes hyperlinked, others highlighted in bold, or not highlighted 
>> at all (dbpedia:regionServed).
>>
>> "The following example shows how to specify that the intransitive 
>> verb/operate/, subcategorizing a prepositional phrase introduced by 
>> the preposition/in/can be used to denote the propertyregionServed 
>> <http://dbpedia.org/ontology/regionServed>in DBpedia. The entry 
>> specifies that in a construction such as `X operates in Y', the X 
>> refers to the subject of the property dbpedia:regionServed, and the Y 
>> refers to the object of the property*regionServed*. Again, we use 
>> theLexInfo <http://www.lexinfo.net/>ontology in our example to 
>> provide linguistic information:"
>>>
>>>
>>>     -- 
>>>     --
>>>     Prof. Dr. Philipp Cimiano
>>>     AG Semantic Computing
>>>     Exzellenzcluster für Cognitive Interaction Technology (CITEC)
>>>     Universität Bielefeld
>>>
>>>     Tel:+49 521 106 12249 <tel:%2B49%20521%20106%2012249>
>>>     Fax:+49 521 106 6560 <tel:%2B49%20521%20106%206560>
>>>     Mail:cimiano@cit-ec.uni-bielefeld.de
>>>     <mailto:cimiano@cit-ec.uni-bielefeld.de>
>>>
>>>     Office CITEC-2.307
>>>     Universitätsstr. 21-25
>>>     33615 Bielefeld, NRW
>>>     Germany
>>>
>>>
>>
>>
>> -- 
>> Elena Montiel-Ponsoda
>> Ontology Engineering Group (OEG)
>> Departamento de Inteligencia Artificial
>> ETS de Ingenieros Informáticos
>> Campus de Montegancedo s/n
>> Boadilla del Monte-28660 Madrid, España
>> www.oeg-upm.net
>> Tel. (+34) 91 336 36 70
>> Fax  (+34) 91 352 48 19
>
> -- 
> --
> Prof. Dr. Philipp Cimiano
> AG Semantic Computing
> Exzellenzcluster für Cognitive Interaction Technology (CITEC)
> Universität Bielefeld
>
> Tel: +49 521 106 12249
> Fax: +49 521 106 6560
> Mail:cimiano@cit-ec.uni-bielefeld.de
>
> Office CITEC-2.307
> Universitätsstr. 21-25
> 33615 Bielefeld, NRW
> Germany
>
>
> /Disclaimer:/
>
> /This message (including any attachments) contains confidential 
> information intended for a specific individual and purpose. If you are 
> not the intended recipient, you should delete this message and notify 
> the sender and The Hong Kong Polytechnic University (the University) 
> immediately. Any disclosure, copying, or distribution of this message, 
> or the taking of any action based on it, is strictly prohibited and 
> may be unlawful./
>
> /The University specifically denies any responsibility for the 
> accuracy or quality of information obtained through University E-mail 
> Facilities. Any views and opinions expressed are only those of the 
> author(s) and do not necessarily represent those of the University and 
> the University accepts no liability whatsoever for any losses or 
> damages incurred or caused to any party as a result of the use of such 
> information./
>

-- 
--
Prof. Dr. Philipp Cimiano
AG Semantic Computing
Exzellenzcluster für Cognitive Interaction Technology (CITEC)
Universität Bielefeld

Tel: +49 521 106 12249
Fax: +49 521 106 6560
Mail: cimiano@cit-ec.uni-bielefeld.de

Office CITEC-2.307
Universitätsstr. 21-25
33615 Bielefeld, NRW
Germany

Received on Tuesday, 8 September 2015 11:18:20 UTC