Discussion on WSMO document, version of 26., 27. and 29.01.2003.

walkingceilInternet και Εφαρμογές Web

22 Οκτ 2013 (πριν από 3 χρόνια και 7 μήνες)

99 εμφανίσεις

I have no glue whether the comments are complete.




Meeting Protocol WSMO


Participants:

Innsbruck: Ying Ding, Ruben Lara, Dumitru Roman, Uwe Keller, Holger Lausen

Galway: Juan Miguel Gomez, Dieter Fensel,
Sung
-
Kook
Han,
Ma
tthew Moran,
Michal

Zaremba



Di
scussion on WSMO

document,

version of 26., 27. and 29.01.2003.

Remark:

versioning and should be handled more professional, i.e. it has to be defined
which version

will be discussed for

Title page


Acronym WSMO should be
included


Project

title

may be kept
for the moment

General


All captions for sections words should start uppercase

Introduction

Should mention where th
e example for WSMO is, since people expect it in this
deliverable

Ontology

(General)

This section made a t
o
o scattered impression, therefore
some parts of the
definitions should move to the appendix


NO! A structured definition based on inheritance of attributes should be provided
in the appendix. In the text, I want to see all attributes of an entity.

Concept Definition:

has non functional pro
perties

types

types do not exist
, all types are concepts

Attributes


Should have a name and a type (logical expression)

Methods


Should be introduced
, taking f
-
logic as inspiration

SuperConcept and DirectSuperConcept


Should

be converted to isA relation/a
ttribute

basicConcept and defined Conept


Distinction
in

unnecessary

and should be
dropped

RelationDefinition


Should
be an n array relation

Axioms

Should have a name, described Element, nonfunctional properties and a logical
expression.

(like all elements
)

MetaData should be added

under non
-
functional properties


i.e. key words, defined vocabularies.



The Distinction between instance and class can be problematic. DL makes this distinction
explicit. Our language should be flexible and allow binding of indi
viduals as well as
classes to variables.


Discussion about last paragraph on page 2 (ontologies):
It
should be written different. We
have two predefined relations: instanceOf and isA
, the rest can be mentioned in the
Annex (l
ike transitive symmetric an
d in
verse)


Questions at the end of chapter 2

1)

this
property
should be stated informally for the moment

2)

should disappear

3)

sketch this, but reference other deliverables

4)

we build a

meta ontology about ontologies


5)

We refer to the model theory of frame logic and ke
ep the ontology meta
ontology as simple as possible.


This were all comments according to the o
ntology


Continuation of the
discussion on v0.03 section GOALS

Fine, nonfunctional properties should be a set of tuples, each is a parameter and a
constraint on
the value of the parameter

Meta Data should be moved to non
-
functional properties.


Imported Ontology should be replaced by usedMediator (as in section Ontology)


Pre condition
:

the variables are input should be deleted.


Post conditions
:

are slightly wron
g. Replace sentence 2 and 3 by it defines the relation
between input and output
.


Delete 3
rd

paragraph.


Assumption
s:

delete everything expect the first sentence.


A discussion about how to make the input explicit at the goal level arose. Dieter decided
th
at input and outputs have not to be declared explicitly. “Some elements might by an
input, but we do not need to declare them explicitly”


Please do not forget that somebody needs to define the non
-
functional properties, i.e.,
Dublin core plus qualitiy of

service parameter.

Mediator

Dieter decided that
the term
link
in the picture
is the wrong word. It should
be usage.

A box is a modeling element.


The picture sh
a
ll

consist of a Mediator that is used by: Mediator, Goal, Ontology.


Juan mentions we should d
istinguish into 4 categories: data, process, protocol,
invocation.

Delete the first sentence

of the description
, since it is incomplete:

Mediator
can link

ontology to ontology

mediator to ontology

webservice to ontology

capability to ontology

web service t
o web service

web service to goal

capability to goal

[…] here I lost track who links whom. Depends on the revisted definition of the other
components… also we shall r
efer to UPML
as it is defined there.


Parameter
importedOntologies will be dro
p
ped

Paramet
er
targetComponent will NOT be droped.

Dieter said: the reduction is the trade of between the two components, in some cases this
reduction might not exist.

If a component
uses

a mediator it becomes it
target component
. (
which is
redundant)


Web Service

Dis
cussion about the picture:
Dieter wants to delete the picture.

A web Service should follow the same modeling style then the rest, i.e. name,
textualDescription, non functional paramenters.


Capability: Should describe functionality and not INTERFACE

Shoul
d also have the same attribute then the other components: i.e. name,
textualDescription, non functional paramenters.

ImportOntology should be there. It should have the same structure then the goal.

NO import of Ontology


Also not just refer but repeat the
meaning of the properties.


Service Description

Juan made comments on the usage of particular uses of choreography languages and that
their compatibility
, this will be clarified f2f.


References.

Et al. should be “et al.”
, Names should be italic.

Never mak
e names italic

For b
ook
s
,
b
ook name is italic

For
Journal or Proceeding: name of journal or proceeding should be italic.


Deadline for rew
orked version: Monday next week 6PM the version will be called V0.03