Latest CGIF specification

[Vikas Kumar-11]

Hello,

I am looking for the latest Conceptual Graph Interchange Format
specification on the web.

The latest version I see is from 2001 at this link :
http://www.jfsowa.com/cg/cgstand.htm

Is there a newer version or an ISO certified version, if at all ?

Your help will be appreciated.

Thanks & Regards
Vikas

---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[Harry Delugach]

Please go to http://common-logic.org/ You will find links to the current ISO standard.

On Aug 11, 2009, at 6:17 PM, Vikas N Kumar wrote:

Hello,

I am looking for the latest Conceptual Graph Interchange Format
specification on the web.

The latest version I see is from 2001 at this link :
http://www.jfsowa.com/cg/cgstand.htm

Is there a newer version or an ISO certified version, if at all ?

Your help will be appreciated.

Thanks & Regards
Vikas

---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

--

Harry S. Delugach

-------------------

Associate Professor

Computer Science Dept., Technology Hall N-351

University Of Alabama In Huntsville                

Huntsville AL 35899 U.S.A.      

voice: +1 256.824.6614   fax: [phone]

delugach(at)cs.uah.edu

http://www.cs.uah.edu/~delugach

[Vikas Kumar-11]

On Tue, Aug 11, 2009 at 7:35 PM, Harry Delugach<delugach@...> wrote:
> Please go to http://common-logic.org/ You will find links to the current ISO
> standard.

Thanks.

---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[John F. Sowa]

Vikas, Harry, et al.,

I forgot to mention that there's a very short and simple grammar
for CGIF on my web site:

    http://www.jfsowa.com/cg/cgif.htm

As Harry said, the ISO 24707 standard for Common Logic is the official
document for conceptual graph syntax and semantics:

http://standards.iso.org/ittf/PubliclyAvailableStandards/c039175_ISO_IEC_24707_2007(E).zip

However, the rules for CGIF published in Annex B of that document
are more complex because they combine both the CGIF syntax and the
translation to the CL abstract syntax in the same rules.  That makes
them look more complex.

That short summary extracts just the CGIF grammar, which is actually
quite simple and easy to implement.

The official ISO standard is not a good place to start for anybody who
wants a quick introduction to CGs.  I recommend the following summary,
which was published in the _Handbook for Knowledge Representation_:

    http://www.jfsowa.com/cg/cg_hbook.pdf

The editors very conveniently negotiated with the publisher to allow
the authors to put their contributions on their web sites.  Therefore,
you can cite this URL with the full reference for the article:

    Sowa, John F. (2008) "Conceptual Graphs," in _Handbook of Knowledge
    Representation_, ed. by F. van Harmelen, V. Lifschitz, and B. Porter,
    Elsevier, 2008, pp. 213-237.  http://www.jfsowa.com/cg/cg_hbook.pdf

Since this article is more accessible than the 1984 book, I recommend
that anybody who publishes articles on CGs should cite this summary
with this URL together with the official ISO standard (URL above).

John


---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[Vikas Kumar-11]

On Fri, Aug 21, 2009 at 10:35 AM, John F. Sowa<sowa@...> wrote:
> I forgot to mention that there's a very short and simple grammar
> for CGIF on my web site:
>   http://www.jfsowa.com/cg/cgif.htm

Hi John,
Thanks for this. I am working on implementing a CGIF compiler for a
product for my company that I am building, and am contemplating the
licensing of the compiler itself. I want the compiler to be embeddable
in software, so I might license it with LGPL
(http://www.gnu.org/licenses/lgpl.html) and I am trying to convince my
company as to the benefits of the license.  Hence I was looking for a
standard document that I can adhere to for future reference as well.
This compiler will be implemented in C so that it is portable across
architectures and can be used by all languages alike without a
performance penalty.

> However, the rules for CGIF published in Annex B of that document
> are more complex because they combine both the CGIF syntax and the
> translation to the CL abstract syntax in the same rules.  That makes
> them look more complex.

Actually, Annex B is a little confusing. It does not mention which is
more useful -- Core CGIF or Extended CGIF. Since Extended CGIF is a
superset of Core CGIF, and more readable it seems a likely candidate.
CLIF is also a likely candidate for its LISP-like nature, but is hard
to read and differentiate between concepts and relations. I find the
same problem with Core CGIF, that relations and concepts are hard to
differentiate from a human readable standpoint.

I'd appreciate any insights or queries regarding the above.

Thanks & Regards
Vikas
--
http://www.vikaskumar.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[John F. Sowa]

Vikas,

That would be very useful:

> I am working on implementing a CGIF compiler for a product
> for my company that I am building, and am contemplating the
> licensing of the compiler itself. I want the compiler to be
> embeddable in software, so I might license it with LGPL

A compiler has to be mapped to and from something.  Since CGIF
and CLIF support identical semantics, you might start by mapping
each notation to the other:

    CGIF -> CLIF

    CLIF -> CGIF

However, your company probably would like to make a profit, and
free software isn't usually a major source of revenue.  But free
software can often serve as a stepping stone toward other software
that can be a source of revenue.

In order to make a business case that your manager(s) would
find convincing, you might show them the potential for using a
translator between CGIF and CLIF as one step toward opening up
new applications for Common Logic as an integrating language
for a wide range of different semantic technologies.

Following are some slides that I presented as part of a tutorial
on Common Logic:

    http://www.jfsowa.com/talks/cl_sowa.pdf

Perhaps you might find some interesting possibilities in those
directions.  Of course, you and your colleagues would undoubtedly
have a better idea of your business opportunities.

> Annex B is a little confusing. It does not mention which is
> more useful -- Core CGIF or Extended CGIF. Since Extended CGIF
> is a superset of Core CGIF, and more readable it seems a likely
> candidate.

The primary reason for the split between Core CGIF and Extended
CGIF is to simplify the formal definition.  Core CGIF is a
simpler language that has a very direct mapping to the Common
Logic model theory.  Extended CGIF is a richer notation, which
has a more complex mapping.  Therefore, I chose the following
two-step approach in order to simplify the formal definition:

  1. Define Core CGIF semantics by mapping it to CL abstract syntax.

  2. Define Extended CGIF semantics by mapping it to Core CGIF.

I agree with you that Extended CGIF is a better notation for
knowledge representation.  However, Core CGIF has the interesting
property that it is almost exactly one-to-one with Peirce's
existential graphs.  You could even call it EGIF.  Therefore,
it is a useful dialect for historical discussions of Peirce.

John




---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[Vikas Kumar-11]

Hi John

I am confused a little bit with some aspects of Extended CGIF, viz.,
a) Iff
b) @every
c) Equiv

The below function is from your handbook on your website.

[Function: *Quotient] [Function: *Remainder]
[[@every*x1] [@every*x2] [@every*x3] [@every*x4]
[Equiv: [Iff: (IntegerDivide ?x1 ?x2 | ?x3 ?x4)]
        [Iff: (#?Quotient ?x1 ?x2 | ?x3) (#?Remainder ?x1 ?x2 | ?x4)]]]

How does one read this graph ?

Here is my interpretation:

There exists a "Function" called "Quotient". There exists a "Function"
called "Remainder".
For all "x1", "x2", "x3", "x4",  "IntegerDivide" of "x1" and "x2"
yielding "x3" and "x4" is equivalent to "Quotient" of "x1" and "x2"
yielding "x3" and "Remainder" of "x1" and "x2" yielding "x4".

I don't understand what the "Iff" concept does here. I also don't see
a "[Function: *IntegerDivide]".

Why is "*" being used before Quotient/Remainder ? Why is #? being used
before Quotient/Remainder and not used before IntegerDivide ?

These are my questions.

---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[John F. Sowa]

Vikas,

I didn't go through all the detail in that article.  The full syntax
and semantics for CGIF is specified in the Common Logic standard:

http://standards.iso.org/ittf/PubliclyAvailableStandards/c039175_ISO_IEC_24707_2007(E).zip

For a summary of just the syntax without the translation rules, see

    http://www.jfsowa.com/cg/cgif.htm

To answer your questions:

@every is the universal quantifier.  The default quantifier in
Core CGIF is the existential.  The universal is defined in terms
of an expansion to the Core CGIF.

 > Here is my interpretation:
 >
 > There exists a "Function" called "Quotient". There exists a "Function"
 > called "Remainder".
 > For all "x1", "x2", "x3", "x4",...

That part is OK, but you left out the "if and only if" expression.

For example, the four universally quantified concepts in the following

[Function: *Quotient] [Function: *Remainder]
[[@every*x1] [@every*x2] [@every*x3] [@every*x4]
[Equiv: [Iff: (IntegerDivide ?x1 ?x2 | ?x3 ?x4)]
         [Iff: (#?Quotient ?x1 ?x2 | ?x3) (#?Remainder ?x1 ?x2 | ?x4)]]]

are expanded to existentially quantified concepts in

[Function: *Quotient] [Function: *Remainder]
[If: [*x1] [*x2] [*x3] [x4]
[Then: [Equiv: [Iff: (IntegerDivide ?x1 ?x2 | ?x3 ?x4)]
        [Iff: (#?Quotient ?x1 ?x2 | ?x3) (#?Remainder ?x1 ?x2 | ?x4)]]]]

 > Why is "*" being used before Quotient/Remainder ? Why is #? being used
 > before Quotient/Remainder and not used before IntegerDivide ?

The asterisk * specifies a defining label.  The concept [*x1] may be
read "There exists something x1", and the concept [Function: *Quotient]
may be read "There exists a function Quotient".  If you look at the
corresponding CLIF statements, you can see those names x1 and Quotient
being used as variables that are introduced by a quantifier "exists".

But the name IntegerDivide is the name of a type (an actor type).
It is not introduced by a quantifier in CLIF, and it is not a
coreference label in CGIF.  Therefore, there is no special marker
in front of IntegerDivide.

When a bound label is used in the argument position of a relation,
it is prefixed with "?".  But when it is used in the position of a
type label, it is prefixed with "#?".  Those are the conventions
for allowing quantifiers to range over relations.

CLIF has a syntax that does not make a distinction between names of
variables and names of constants.  It does not use any prefix on
any names; the absence of a quantifier for a name means that it
is a constant.

Because CGIF requires a distinction between type labels and
coreference labels, it uses the prefixes "*" for defining labels,
"?" for bound labels, and "#?" for bound labels used to represent
types.

The labels Equiv and Iff are defined by the translation rules to
generate a pair of If-Then constructions to express "if and only if".
Following is the next step of the expansion:

[Function: *Quotient] [Function: *Remainder]
[If: [*x1] [*x2] [*x3] [x4]
   Then:
     [If: (IntegerDivide ?x1 ?x2 | ?x3 ?x4)]
          [Then: (#?Quotient ?x1 ?x2 | ?x3) (#?Remainder ?x1 ?x2 | ?x4)]]
     [If: (#?Quotient ?x1 ?x2 | ?x3) (#?Remainder ?x1 ?x2 | ?x4)]]
          [Then: (IntegerDivide ?x1 ?x2 | ?x3 ?x4)]] ]]

Your questions have helped me to see that I should add more examples
and explanation to the CGIF.htm article.  I'm sure that other people
may have similar questions.

John Sowa



---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[Vikas Kumar-11]

On Wed, Oct 7, 2009 at 4:30 PM, John F. Sowa <sowa@...> wrote:
> The labels Equiv and Iff are defined by the translation rules to
> generate a pair of If-Then constructions to express "if and only if".
> Following is the next step of the expansion:

Hi John,

Thanks for the explanation. It was helpful.

As per the syntax link you mentioned, "Either", "Or", "If", "Then",
"Equiv", "Equivalence", "Iff" are the only visible labels.
In addition to these there is the "@every"  which is a special quantifier.

Are there any more such special reserved words ?

The "Iff" was not that clear to me though. I would assume that there
exists no corresponding "Then" statement for the "Iff" or does "Iff"
entail a different meaning from "If-Then".

Wouldn't "If-Then" really be used for something like this, where the
consequences of once concept/relation lead to another concept/relation
?

[If: [ConceptA] Then: [ConceptB]]

How would "Iff" work in such a case ? Shouldn't there be a "Then"
clause for an "Iff" clause, otherwise it just seems like an If clause
without an action ?

I apologize if my question is not clear.

Thanks
Vikas
--
http://www.vikaskumar.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[John F. Sowa]

Vikas,

 > Are there any more such special reserved words ?

We have kept the number of reserved words to an absolute minimum.
You can check the ISO standard for the full specification.  It is
available for a free download.  (Unfortunately, most other ISO
standards require a fee.)  For a shorter version of just the
syntax, see the cgif.htm file.

 > The "Iff" was not that clear to me though. I would assume that
 > there exists no corresponding "Then" statement for the "Iff"
 > or does "Iff" entail a different meaning from "If-Then".

The word 'iff' is often used as an abbreviation for 'if and
only if'.  The phrase "p iff q" would be expanded as two
implications.  (p implies q) and (q implies p).

The reason for the nesting

   [Equiv: [Iff: p] [Iff: q]]

is to constrain the scope of quantifiers.  Any quantifiers
in any context have the scope of that context and all
nested contexts.  The above nesting ensures that any
quantifiers in p do not affect anything in q and vice versa.

If you just want if-then, you would write

    [If: p [Then: q]]

This ensures that quantifiers in p have q within their scope.

John





---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[jrv]

Iff is common math jargon, and means "if and only if".  There is no place for
or need for a "then" in relation to Iff.

"A Iff B", or in symbols A <==> B means:

A => B  AND B => A.

Sometimes A => B is pronounced "B only if A", or of course "if A then B"

Best,

John Velman


On Wed, Oct 07, 2009 at 06:08:46PM -0400, Vikas N Kumar wrote:

> On Wed, Oct 7, 2009 at 4:30 PM, John F. Sowa <sowa@...> wrote:
> > The labels Equiv and Iff are defined by the translation rules to
> > generate a pair of If-Then constructions to express "if and only if".
> > Following is the next step of the expansion:
>
> Hi John,
>
> Thanks for the explanation. It was helpful.
>
> As per the syntax link you mentioned, "Either", "Or", "If", "Then",
> "Equiv", "Equivalence", "Iff" are the only visible labels.
> In addition to these there is the "@every"  which is a special quantifier.
>
> Are there any more such special reserved words ?
>
> The "Iff" was not that clear to me though. I would assume that there
> exists no corresponding "Then" statement for the "Iff" or does "Iff"
> entail a different meaning from "If-Then".
>
> Wouldn't "If-Then" really be used for something like this, where the
> consequences of once concept/relation lead to another concept/relation
> ?
>
> [If: [ConceptA] Then: [ConceptB]]
>
> How would "Iff" work in such a case ? Shouldn't there be a "Then"
> clause for an "Iff" clause, otherwise it just seems like an If clause
> without an action ?
>
> I apologize if my question is not clear.
>
> Thanks
> Vikas
> --
> http://www.vikaskumar.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cg-unsubscribe@...
> For additional commands, e-mail: cg-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[Vikas Kumar-11]

Thanks for the help.

On Wed, Oct 7, 2009 at 11:07 PM, John F. Sowa <sowa@...> wrote:

> Vikas,
>
>> Are there any more such special reserved words ?
>
> We have kept the number of reserved words to an absolute minimum.
> You can check the ISO standard for the full specification.  It is
> available for a free download.  (Unfortunately, most other ISO
> standards require a fee.)  For a shorter version of just the
> syntax, see the cgif.htm file.
>
>> The "Iff" was not that clear to me though. I would assume that
>> there exists no corresponding "Then" statement for the "Iff"
>> or does "Iff" entail a different meaning from "If-Then".
>
> The word 'iff' is often used as an abbreviation for 'if and
> only if'.  The phrase "p iff q" would be expanded as two
> implications.  (p implies q) and (q implies p).
>
> The reason for the nesting
>
>  [Equiv: [Iff: p] [Iff: q]]
>
> is to constrain the scope of quantifiers.  Any quantifiers
> in any context have the scope of that context and all
> nested contexts.  The above nesting ensures that any
> quantifiers in p do not affect anything in q and vice versa.
>
> If you just want if-then, you would write
>
>   [If: p [Then: q]]
>
> This ensures that quantifiers in p have q within their scope.
>
> John
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cg-unsubscribe@...
> For additional commands, e-mail: cg-help@...
>
>

--
http://www.vikaskumar.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[Vikas Kumar-11]

Hello again,

I am trying to find an example and also understand the EBNF form of this:

arcSequence  =  {arc}, [[comment], "?", seqname];

(from: http://www.jfsowa.com/cg/cgif.htm and the ISO doc section B.3.3)
I just wanted to confirm that ?seqname in this case would be the
reference for the arcSequence here ?

Could anyone give me an example of what an arcSequence with a seqname
would look like ?

Another confusion I have is regarding the B.2.11 "text" EBNF notation:

text  =  "[", [comment], "Proposition", ":", [CGname], CG, [endComment], "]";

Here a CG is required to follow a CGname which is optional for the
"Proposition" type ?
Is "Proposition" a concept type that is implicitly defined and assumed
to be the lowest level type like Entity ?
Is it a part of the syntactic rules like If:, Then:, Either: etc ?
In what cases would "Proposition:" be used ?

Thanks in advance for your help.

Regards
Vikas

---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[Vikas Kumar-11]

Hello again,

I am trying to find an example and also understand the EBNF form of this:

arcSequence  =  {arc}, [[comment], "?", seqname];

(from: http://www.jfsowa.com/cg/cgif.htm and the ISO doc section B.3.3)
I just wanted to confirm that ?seqname in this case would be the
reference for the arcSequence here ?

Could anyone give me an example of what an arcSequence with a seqname
would look like ?

Another confusion I have is regarding the B.2.11 "text" EBNF notation:

text  =  "[", [comment], "Proposition", ":", [CGname], CG, [endComment], "]";

Here a CG is required to follow a CGname which is optional for the
"Proposition" type ?
Is "Proposition" a concept type that is implicitly defined and assumed
to be the lowest level type like Entity ?
Is it a part of the syntactic rules like If:, Then:, Either: etc ?
In what cases would "Proposition:" be used ?

Thanks in advance for your help.

Regards
Vikas

---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[John F. Sowa]

Vikas,

I forgot to respond to the following questions:

> I am trying to find an example and also understand the EBNF
> form of this:
>
> arcSequence  =  {arc}, [[comment], "?", seqname];

A sequence name is an identifier with three dots ... in front.

The sequence names were first introduced in KIF as 'sequence variables'
to support relations and functions with a variable number of arguments.
They had not been previously available in conceptual graphs, but they
were added to the CL standard.  For completeness, they are supported
by CGIF.  Note the comment on page 18 of the CL standard:

    6.1.3 Abstract syntactic structure of dialects

    A dialect which provides only some types of the Common Logic
    expressions is said to be a syntactically partial Common Logic
    dialect, or syntactically partially conformant. In particular,
    a dialect that does not include sequence markers, but is
    otherwise fully conformant, is known as a syntactically
    compact dialect. See clause 7.1 for a description of some
    relationships between syntactic and semantic conformance.

Since most current implementations of conceptual graphs do not
yet support polyadic relations, you can omit them in an initial
implementation.

If you do implement them, you can use the following example:

Suppose that you have an actor of type Plus that takes two
numbers x and y as input and generates one number z as output:

    (Plus ?x ?y | *z)

But you want to define an actor named Sum that takes zero
or more inputs and uses Plus to generate the output.  You
could define it with the following three axioms:

    [ (Sum | [Number: 0]) ]

    [ [Number: @every *x] (Sum ?x | ?x) ]

    [ [Number: @every *x] [@every *...y]
      (Sum ?x ?...y | *z) (Sum ?...y | *w) (Plus ?x ?w | ?z) ]

Note that I put each of the axioms in brackets to prevent
the universal quantifiers on the second and third axioms
from binding anything in any other axiom.

The first axiom says that the Sum of an empty sequence is
the number 0.

The second axiom says that the sum of any number x is x.

Third axiom says that the sum of any number x and a sequence y
is the result of applying Sum to the sequence y to get w and
then applying Plus to x and w to get the final result z.

Note that the sequence markers in Common Logic don't represent
data values that require a sequence datatype in the ontology.
Instead, they are a metalevel mechanism for defining relations
and functions (or actors in CG terminology) that take a varying
number of arguments.

This approach allows the CL standard to be "ontologically neutral."
It does not make any assumptions about what exists in the domain.
You could add CL axioms to define sequences, but those would be
entities defined by whatever axioms you choose.

CL does support a type of names called 'numerals', and those
names happen to look very familiar:  0, 17, 238, 167903.
But CL does not say anything about the entities that numerals
happen to refer to.

> Another confusion I have is regarding the B.2.11 "text" EBNF notation:
>
> text  =  "[", [comment], "Proposition", ":", [CGname], CG, [endComment], "]";
>
> Here a CG is required to follow a CGname which is optional for the
> "Proposition" type ?
> Is "Proposition" a concept type that is implicitly defined and assumed
> to be the lowest level type like Entity ?
> Is it a part of the syntactic rules like If:, Then:, Either: etc ?
> In what cases would "Proposition:" be used ?

In my books and articles, I have been using the type label Proposition
for abstract entities that represent the "meaning" asserted by a
conceptual graph.  But technically, Common Logic has no built in
ontology for anything, not even propositions.  However, the IKL
extension has been proposed for adding propositions to the language
and allowing axioms to refer to propositions.

To be ontologically neutral, Common Logic cannot have propositions
as a first-class entities in the language.  But there are some plans
for a future extension (possibly IKL or something very similar),
which would have propositions.  See the following article:

    http://www.jfsowa.com/cg/cg_hbook.pdf

Sections 4 and 5 (and the references at the end) discuss such
extensions.

For the purpose of the CL standard, consider a concept such
as the following:

    [Proposition: MyFavoriteAxiom (On [Cat] [Mat])]

Without the label 'Proposition', the axiom would be asserted.
To give a name to an axiom without actually asserting it, the
string 'Proposition' blocks the assertion and just states that
that 'MyFavoriteAxiom' is a name for the nested CG.

The IKL language, however, incorporates an ontology for
propositions.  That same concept would state that
MyFavoriteAxiom is the name of the proposition stated
by that axiom.

John



---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[Vikas Kumar-11]

Thanks John for the extended explanation.

I am working on building first an Extended CGIF parser which will
parse a CGIF string and convert it into relevant data structure so
that it can be used internally in code by any user who wants to use
CGIF as an internal method of representation of complex concepts.

I hope I succeed soon enough to build it and let the community try it out.

Thanks
Vikas

---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[Polovina, Simon]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi all, FYI as a conference that is relevant to a number of members of this community and apologies for any x-posting. Cheers, Simon

 

CALL FOR PAPERS

Pervasive Informatics in the Digital Economy

12th International Conference on Informatics and Semiotics in Organisations

 

July 19-21, 2010, Reading, UK

http://www.orgsem.org/2010

 

The 12th International Conference on Informatics and Semiotics in Organisations, (ICISO 2010), previously named International Conference on Organisational Semiotics (ICOS), is the twelfth in a series of international events devoted to the latest research in informatics in organisations and organisational semiotics.

 

In the present era, information and knowledge are key to the development of the current society and economy. The digital economy is driven by the effective use of information and communication technology to help enhance the quality and transform the lives of individuals, society and business. Information is the critical resource on which humans are constantly dependent in conducting purposeful activities and achieving their objectives.

 

Pervasive Informatics, as an emergent discipline, studies how information affects humans in built environments. The built environments provide spatial contexts for business organisations, government institutions, commercial enterprises, and other business settings, as well as buildings and spaces for working and living. The majority of human activities (e.g. related to social, economic and scientific purposes) take place in a built environment. Increasingly, information is provided pervasively to the users within the built environment. With the support of appropriate technology, the users can access to the information as they need; although often they may also have to face with the information even if not wanted. A user may therefore be immersed in the field of information whether or not it is desired by the user. Such a phenomenon of pervasiveness has been bringing revolutionary impact to the human society. Pervasive Informatics helps us to understand the nature and characteristics of information from its creation, representation, processing and utilisation, embedded within the complex interactions between humans and built environments. It is concerned with approaches and methods on how information can be managed and used to enhance the effectiveness of work and quality of life.

 

Following tradition, ICISO 2010 aims to provide a focal forum for active researchers, practitioners, business and industrial professionals and academics from diversified domains of information management and information systems, and from business and engineering. They will be able to share their latest research achievements and practical experiences, to exchange in-depth findings and innovative ideas, and in particular to harness the greatest challenges in the changing era and thinking seriously into the future. The ICISO 2010 will also continue the effort of the international research community in the development of the emergent discipline of informatics and its applications. It will focus not only on theory building, but also on the practical benefits gained so far through applications of methods and techniques derived from various approaches.

 

Research papers describing original work in relevant areas are invited. Industrial and work-in-progress papers are also welcome.

 

Topics

Specific topics of interest include, but are not limited to:

·          Organisational Semiotic theory, concepts, methods and techniques, and their practical applications

·          Semiotically motivated approaches to information systems

·          Pragmatic web and context-aware approaches and applications

·          Semantic web and applications

·          Service-oriented architecture, design and implementation

·          Business and IT strategies

·          Alignment and integration of business and technical systems

·          Adaptive architecture for information systems

·          Enterprise information systems and value chain management

·          Enterprise applications for logistics, customer relationship management  and supply chain management

·          Information engineering and complex systems

·          Agent-based information systems and business intelligence in organisations

·          Collaborative systems for organisations

·          E-government, e-commerce, mobile and pervasive commerce

·          Business process and workflow modelling, analysis, integration and management

·          Digital economy: theory, methods and techniques for design and applications

·          Pervasive informatics in organisations

·          Intelligent spaces and built environments for working and living

·          Construction informatics for sustainable environment

·          Information utilisation and technology management for sustainable economy

·          Digital content management

 

 

Important dates

Full paper submission: 1 February, 2010

Notification of acceptance: 1 April 2010

Camera-ready version: 15 May 2010

Conference: 19 – 21 July 2010

 

Submission Guidelines

Authors are invited to submit original, unpublished research papers that must not be published elsewhere and not currently under review for any other publication. The manuscripts in English must be submitted in the provided format (both as Word and Adobe PDF files) and may not exceed 8 pages.

 

Publication

The papers will be selected based on a peer review by three independent members of the program committee. This review process will be anonymous in order to ensure quality and to avoid prejudice. At least one author per accepted paper is required to register and attend the conference.

 

Conference proceedings will be published by Aussino Academic Publishing House. Same as previous conferences, all accepted papers will be submitted to ISTP and EI for indexing.

 

Invitation for Proposals of Workshops and PhD Consortium

The ICISO 2010 invites proposals for workshops and PhD consortium. Please contact the Conference Secretary if anyone intends to submit a proposal.

 

It is intended to have parallel teleconference sessions in Beijing for attendance and paper presentations. More details will be soon available at the conference website.

 

Conference Co-chairs

Rene Jorna, University of Groningen, Netherlands

Kecheng Liu, University of Reading, England

 

Secretariat

Hubert Grzybek, University of Reading, England

 

Host institution

Informatics Research Center, University of Reading, England

 

Conference Contact Details

Conference website:

www.orgsem.org/2010

 

Conference email address:

ICISO@...