[SWS]OWL-S中 parameterValue Property的作用

Parameter类有两个Properties: parameterType ( minCardinality 1 ) parameterValue (在过去的版本中用于制定constant value)
I brought this up a while ago on this list, and no-one objected to deprecating this property, since we have valueData to do the job.
parameterValue is a leftover from earlier incarnations of OWL-S. /Daniel
Maybe the definition of the parameterValue needs to be changed as the "default value" that will be used in case no other value is provided. In any case, a clarification about its use needs to be documented. Evren


 Concerning the inputs and outputs, the philosophy (and practice) in OWL-S is that the I/O is in terms of functional capability not low level details like account number and password. In other words, the inputs and outputs should differentiate one service (e.g. buying a tennis racket) from another (e.g. buying shoes) whereas giving a credit card or a password does not differentiate between the two services. It is the role of the process model in OWL-S to break down the buying of a tennis racket into a login atomic process where account number and password are needed, and then the selection part where the particular type of tennis racket is input, and then the actual buying part where your credit card is input.

[SWS]asymmetric vs. symmetric matching

Asymmetric matching: the provider-published description of its properties is queried by the consumer to identifiy candidates prior to generating requests for resource. Symmetric matching: resource and request are descrbed by the same syntax. The request describes its requirement to the resource while the resource describes its requirement ( or policy ) to the requester.


TRIPLE : a rule language and deductive database system Condor : a matchmaking system Portable Batch System: Redline: a matchmaking framework LARKS/RESINA: multiagent infrastructure, providing ontology-based matchmaking. HP e-commerence matchmaker:      cf.  (1)Description Logics for Matchmaking of Services.           (2)Agent Mediated electronic Commerce at HP Labs. Raman et al's work on resource matching    cf. Matchmaking distrubuted resource management for high throughput computing. 1998  

[SWS]OWL-S 1.1 Process Ontology


[SWS]Congo Process Data Flow Graph


[SWS]OWL-S CompositeProcess 的建议阅读步骤

今天花了一下午+晚上的时间,看完了CongoProcess example。 一开始用多个IE窗口看,然后用XML SPY+IE+UltraEdit看,发现效率都很低。 然后花了一会儿工夫去下了几个OWL-S Editors。基于Protege的那个相对不错(前一个blog里已经描述过了)。 利用这个工具,大大地提高了阅读,并发现一个快读了解CompositeProcess描述的步骤: 准备工作:安装Protege 3.0 + SRI的OWL-S Plug-in。准备一张大点的纸,和2种不同颜色的笔。 首先,利用 Protege 显示Process control structure图的功能,在纸上画一个从最上层的CompositeProcess到AtomicProcess的control structure树。 第二步,把每个Process的Input和Output在图上标出来。 第三步,标出各个Process的Input参数的参数值来源。 从最顶层的那个CompositeProcess开始,在Protege中查看其sub-process的Perform(在Control Structure图中click sub-process方框即可),根据Perform的hasDataFrom (range Binding) 画出Input参数的来源(如果来自TheParentPerform中的同名Input参数,就不要explicitly标出了)。 注:这一步也可以在UltraEdit中,通过搜索“<process:hasDataFrom>”来进行。 第四步,标出各个Process的Output参数是如何得到的。 从最顶层的那个CompositeProcess开始,在Protege中双击该Process,根据hasResult的值,标出某个Output的值在什么Condition下是什么。 注:这一步也可以在Protege的Process栏中,从上到下依次察看各个Process的hasResult的值。      

[SWS]OWL-S 1.1 release 笔记

(1) hasOutput  与 Result.withOutput的区别 前者的range为Output。用于声明process的输出。(类似于定义 函数型构 中的 返回值)。 后者的range为OutputBinding,用于为Process中的Output指定值的来源(来自sub-process的Perform、TheParentPerform或ThisPerform)。(类似于在函数体内,用return定义返回值的取值。) (2) ResultVar, Local 与 swrlx:Variable的区别 ResultVar: scope为 特定的Result,在该Result的Condition中绑定,可在该Result的Effect和OutputBinding中被引用。 Local : scope为整个Process,在该Process的PreCondition中绑定,可在该Process的 Result和Effect中被引用。 后者的scope为condition。仅能在condition内的其他Atom内引用。   (3)  一个Process的Input参数通常在其 TheParentPerform (即process属性的值为本Process的Perform) 中,通过hasDataFrom属性(range Binding)来指定,其值一般来自于父process或兄弟process。 一个Process的Output参数的指定通常是:在他本身的Result中,通过withOutput( range OutputBinding ) 关联到 对某个sub-process的Perform 所产生的Output ( 或以之为参数的函数,该函数的语义 is outside OWL-S )(见上)。 (类似于 用其他函数的返回值(进行一定运算后) 作为本函数的返回值 ) (4) Perform的作用: * 指定具体执行的 Process * 指定Process的 输入参数值 (5)Result的作用(在inCondition成立的条件下): * 为Process指定 输出参数值。 * 描述Process执行后的 效果。

[SWS]Profile-based Class Hierarchies

转载自: http://www.daml.org/services/owl-s/1.1/ProfileHierarchy.html

Profile-based Class Hierarchies Explanatory remarks for ProfileHierarchy.owl OWL-S 1.1 As explained in the Technical Overview and elsewhere, a service profile is used to characterize a service for purposes such as advertisement, discovery, and selection. Service profiles may be published in various kinds of registries, discovered using various tools, and selected using various kinds of matchmaking techniques. OWL-S does not prescribe or limit the ways in which profiles may be used, but rather, seeks to provide a basis for their construction that is flexible enough to accommodate many different contexts and methods of use. In general, this kind of service characterization must effectively position a service within the broad array of services that exists within some domain, or perhaps in the world at large. One very natural technique for this kind of positioning is the construction of a class hierarchy, with inheritance of properties by subclasses. This fundamental technique, which is a familiar part of object-oriented design and programming, is also well supported by OWL and other description logic-based markup languages. This technique, when used to construct a hierarchy of subclasses of the Profile class, p

[SWS]A Policy Based Approach to Security for the Semantic Web (Rei - a policy language)

Author: Lalana Kagal et al., Title: A Policy Based Approach to Security for the Semantic Web CNF: InProceedings, 2nd International Semantic Web Conference (ISWC2003), September 2003. Comment:   OWL-S has been linked to Rei. Rei is a RDF-Schema-based language for policy specification. It is modeled on deontic concepts of
rights, prohibitions, obligations and dispensations. These constructs have four attributes: actor, action,
provision, and constraint. Constraint specifies conditions over the actor, action, and any other context entity
that must be true at invocation. Provisions, which represent the actor’s obligations, describe conditions that
should be true after invocation. These basic constructs allow Rei to represent different kinds of policies,
including authorization, privacy and confidentiality. The class Policy is at the root of the Rei ontology.
Policy has subclasses of PrivacyPolicy, AuthorizationPolicy and ConfidentialityPolicy. Rei’s Policy class is
linked with the OWL-S ontology by defining a new OWL-S description property, policyEnforced, of which
Policy is the range (see www.csee.umbc.edu/~lkagal/rei/examples/ses-sec/swspolicy.owl). Linking OWL-S
with Rei allows specification of privacy, authentication and confidentiality to be specified for service
providers and requesters. 其他资料:Lalana Kagal,

« 1 2 »


«August 2019»
blog名称:World Wide Web Watch
站点首页 | 联系我们 | 博客注册 | 博客登陆

Sponsored By W3CHINA
W3CHINA Blog 0.8 Processed in 0.047 second(s), page refreshed 144294702 times.
《全国人大常委会关于维护互联网安全的决定》  《计算机信息网络国际联网安全保护管理办法》