- From: Philipp Cimiano <cimiano@cit-ec.uni-bielefeld.de>
- Date: Wed, 9 Sep 2015 12:34:57 +0200
- To: public-ontolex@w3.org
- Message-ID: <55F00B51.5000303@cit-ec.uni-bielefeld.de>
Hi Francesca,
ok, that was my fear... so I will have to go through the KIF annotation.
Any other upper ontologies that we could use for our examples?
Philipp.
Am 08.09.15 um 14:04 schrieb QUATTRI, Francesca [11901993r]:
>
> Hi Philipp,
>
>
> thanks for the reply.
>
> To the extent of my knowledge, I do not recall any automatic way to
> extract all the "role" names for an upper concept and/or its direct
> child in SUMO. In other words, if you are interested in the roles
> ("agent", "patient", "destination", etc.) in first order logic for
> let's say Giving, you will have to go through the KIF axioms, select
> the definition you are interested in (as you noticed, Giving is
> polysemous) and consider the roles assigned to that.
>
>
> Also: These logical annotations are instantiations of events and
> entities as suggested by SUMO developers, i.e. you can come up with a
> different description, and hence different "role" names in first order
> for the same concept.
>
>
> KIF is not the only formal language in SUMO, so the choice of SUO-KIF
> over other formal languages should be specified when selected over the
> others.
>
>
>
> Regards,
> Francesca
>
>
> ------------------------------------------------------------------------
> *From:* Philipp Cimiano <cimiano@cit-ec.uni-bielefeld.de>
> *Sent:* Tuesday, September 8, 2015 7:17 PM
> *To:* public-ontolex@w3.org
> *Subject:* 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
>
>
> /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 Wednesday, 9 September 2015 10:37:07 UTC