迈克，一点问题都没有。我只是在长途飞行后感到疲倦。我在SWIG今天。让我们见面。。。。菲尔·特特洛高级顾问IBM商业咨询服务手机。(+44) 7740 923328“迈克尔·乌斯科尔德F“<michael.f.uschol收件人d@boeing.com>Phil Tetlow/英国/IBM@IBMGB 复写的副本28/02/2005 08:10 主题回复：[SE]对注释草案的评论我强烈建议您将本系列转发到列表中，除非你真的想从记录中得到一些东西。你的评论似乎很不错从我的角度来看，适合进行一般性讨论。关于OWL：我认为工作组的全部目的是就如何使用OWL。我想知道其他人怎么想？迈克-----原始邮件-----发件人：Phil Tetlow[mailto:philip.tetlow@uk.ibm.com]发送时间：2005年2月27日星期日下午2:31收件人：Uschold，Michael F主题：回复：[SE]对注释草案的评论迈克，如果你不介意的话，我有一些谦逊的意见。。。？我开始写这篇文章是为了让整个SWBP看到，但后来我想最好直接发送。经过长途飞行那个。。。。。。希望明天见到你？感谢您的早期评论。我们（SWTF）的目标是，希望，我们可以在第二周给这张纸币增加一些更实质性的形状这可能意味着一些重大变化。因此，我全心全意地同意你关于需要更多关注的笔记的观点。如前所述，最初的目的是为辩论确定方向，然后发布更多通过共同讨论和（我相信）达成一致的具体材料。然而，有三个初步想法，1.在你的评论中-“通常，人们提到正式规范提供了完全不含糊的可能性。IMHO，这是一种很容易误导人的误解。我们应该而不是公布它。”当然是非常正确的（在你非常明智的观点中！），但是任何方法，无论是否正式，其要点肯定是它仅仅是一个实施。因此，与大多数实现一样，可以使用任何方法糟糕的工作，完全是错误的工作。概述工具潜力，作为这里的“尝试”并不能保证理解、理解或实践的质量，但我们都可以活在希望中；0)所以，我想我们应该更仔细地考虑我们的目标受众。我个人在写这篇文章时的假设是那个它将主要由从业人员和一些背景在方法理论和应用方面。像往常一样，我被纠正了。显然，你提出了一个非常有效的观点启动，所以我认为添加一些类似于你所引用的-谢谢。2.是的，我完全同意，介绍和整体风格是非常很差。任何额外的帮助都将不胜感激。3.我必须承认，我曾认真考虑过写这张便条特别与W3C技术（如OWL）相关，但就个人而言从这件事中解脱出来。我认为将OWL列为相关技术，但我担心，例如，提供示例使用OWL。这是因为。a.我认为ODA更多的是一种技术架构方法，而是关于语言用法的具体陈述。因为同样的原因我不愿意专门提到UML工具，比如ERD，但被TF其他人的卓越贡献所说服。b.ODM已经涵盖了类似的基础，并得出结论UML和OWL足够不同，需要不同的元模型。这似乎是这是一个有争议的问题，我目前更赞同这个想法围绕UML类图进行的一些认真工作元模型适合-这是一个用于直接接受Grady I想一想？c.语义Web语言领域似乎仍在发展速度很快。我们真的认为在这样的注释中使用特定的OWL语法明智吗在关于软件工程和语义Web？我想唯一务实的答案是肯定的，但有些争论首先是有用的。我相信下周将是一个激动人心的时刻，我期待着为许多啤酒而进行的激烈辩论！谨致问候菲尔·特特洛高级顾问IBM商业咨询服务手机。(+44) 7740 923328“迈克尔·乌斯科尔德F“<michael.f.uschol收件人d@boeing.com> <public-swbp-wg@w3.org>发送人：复写的副本public-swbp-wg-re公司quest@w3.org主题[SE]对票据草案的评论26/02/2005 07:32总体情况：感谢菲尔为我们所有人准备了一些东西有很多有趣的想法和观点，IMHO需要更加清晰地聚焦。当我读到它时，我几乎认不出来它来自前面的笔记和讨论。似乎缺少了一些东西。该注释几乎没有提到“本体驱动的体系结构”。也许我们可以在以下方面达成一致：*本说明的预期受众*特定读者的具体目标是什么？*读者应该理解哪些具体要点？*我们能确定一些具体的需求、要求和潜在的好处吗目标观众中的人会有什么？*我们可以根据如何满足这些要求来构造注释吗，让利益发生？*用一两句话描述我们将要做什么的笔记提纲在每个主要部分说。*我们会给出一些具体的建议吗？*我们要用例子来说明一般观点吗？*这个注释与OWL有什么特别的关系？一旦我们就这些事情达成一致意见，写便条应该很重要更容易的。就目前情况来看，该注释非常通用、抽象和高级与OWL没有任何特别的相关性。此外，还有很多很长的可以拆分以增加清晰度的句子。以下是一些具体的评论：经常提到，正式规范提供了完全没有歧义的可能性。IMHO，这很容易引起误解，和一个常见的误解。我们不应该公布它。这里有一个我最近在另一个上下文中写的一段写道：通常会轻率地假定显式地表示语义形式上，消除了意义上的所有歧义，从而使机器通过编程自动发现含义和行为适当地。这种说法很容易引起误解，或者完全是假的。例如，在基于逻辑的表示语言中定义的术语模型理论语义是高度模糊的（因为有很多可能的模型）。添加更多公理可以排除越来越多的模型，然而，对于许多概念，例如“人类”或“汽车”，有模糊边界。永远不可能给…添加足够的公理消除所有歧义。即使你可以，也不太可能对于每个概念都有几十个或数百个公理很有用-如何它们会被使用吗？我们能说的是，正式的表达有助于消除模糊性。简介：没有明确的目标，相互脱节。背景2.1这很不和谐，需要对注释的总体内容和大纲。然后每一块都会自然接下来，读者会期待他们。也许我们可以用“说”你要说什么；说出来；说你所说的“结构注意。2.2：“工具使用”是指使用工具吗？3：需要介绍短片来谈论这三个想法，然后详细说明。组织福利。例如，易于使用的正式规范支持严格的分类和识别。它还支持知识断言和推理。如果我们从1到6对项目符号进行编号，则存在以下链接。4 -> 2 -> 52 -> 14 -> 3 -> 1链接的语义是：支持、促进、帮助关于3.1：太模糊，需要举例说明。3.3：过于冗长、抽象和行话。具体是什么在此背景下关系模型的重要性/相关性？需要示例4.本节的预期信息是什么？伊塞乌斯：这些是标准的。我们有什么具体的为了我们的特殊目的而谈论它们？
接收日期：2005年2月28日星期一13:21:03 UTC