Nabble - w3.org - www-zig

Re: Z39.50 proposal "Requesting XML Records (Revised 2009)" please comment by July 27

2009-08-31T08:03:11Z

The proposal "Requesting XML Records (Revised 2009)" has been approved as a
Z39.50 Implementors Agreement.
http://www.loc.gov/z3950/agency/proposals/resolution/request-xml-revised-2009.html

It replaces August 2003 Implementors Agreement: Requesting XML Records.

--Ray

----- Original Message -----
From: "Ray Denenberg, Library of Congress" <rden@...>
To: <www-zig@...>
Sent: Monday, July 13, 2009 5:46 PM
Subject: Z39.50 proposal "Requesting XML Records (Revised 2009)" please
comment by July 27

> Please comment on the proposal "Requesting XML Records (Revised 2009)"
> http://www.loc.gov/z3950/agency/proposals/request-xml-revised-2009.html
>
> If there are no comments by July 27, this will be adopted as an
> implementor agreement.
>
> --Ray
>

Re: Z39.50 proposal "Requesting XML Records (Revised 2009)" please comment by July 27

2009-07-14T09:51:38Z

From: "LeVan,Ralph" <levan@...>
> We currently have an OID for identifying XML records. We are
> introducing a new OID for XML records whose schema can be identified by
> an accompanying ElementSetName.

Look at the proposal and note that it is a proposed replacement to the 2003 agreement: http://www.loc.gov/z3950/agency/agree/request-xml.html

It was then that 1.2.840.10003.5.112 was introduced for XML records whose schema can be identified by an accompanying ElementSetName.

> As I remember, ElementSetName is only used in requests. If that is the
> case, then requests for the new OID should be responded to with
> responses with the old OID as there is no accompanying ElementSetName.
> (That's a request for even more clarification.)

This seems to me a bit frivolous, does the client really care whether the server says the record is 110 (xml) or 112 (xml)?

The purpose of this (current) proposal is twofold: (1) to codify current practice (and in fact, practice that has been in place for several years) and (2) to put in place a policy regarding the assignment of identifiers for future schemas used by Z39.50.

With respect to the first, what is the current practice?

--Ray

RE: Z39.50 proposal "Requesting XML Records (Revised 2009)" please comment by July 27

2009-07-14T06:51:26Z

I think some clarification is called for.

We currently have an OID for identifying XML records. We are
introducing a new OID for XML records whose schema can be identified by
an accompanying ElementSetName. (That's the clarification.)

As I remember, ElementSetName is only used in requests. If that is the
case, then requests for the new OID should be responded to with
responses with the old OID as there is no accompanying ElementSetName.
(That's a request for even more clarification.)

Ralph

> -----Original Message-----
> From: www-zig-request@... [mailto:www-zig-request@...] On Behalf
Of
> Ray Denenberg, Library of Congress
> Sent: Monday, July 13, 2009 5:46 PM
> To: www-zig@...
> Subject: Z39.50 proposal "Requesting XML Records (Revised 2009)"
please
> comment by July 27
>
> Please comment on the proposal "Requesting XML Records (Revised
2009)"
>
http://www.loc.gov/z3950/agency/proposals/request-xml-revised-2009.html
>
> If there are no comments by July 27, this will be adopted as an
implementor
> agreement.
>
> --Ray
>
>

Z39.50 proposal "Requesting XML Records (Revised 2009)" please comment by July 27

2009-07-13T14:46:24Z

Please comment on the proposal "Requesting XML Records (Revised 2009)"
http://www.loc.gov/z3950/agency/proposals/request-xml-revised-2009.html

If there are no comments by July 27, this will be adopted as an implementor
agreement.

--Ray

SV: Requesting XML records via Z39.50

2009-06-15T05:21:37Z

Maybe it would have been more accurate if I said:
This gives (as an option) a well defined way to specify schemas and sub schemas. This option is:
OID (object identifier) 1.2.840.10003.5.112 and schema identifier a URI listed in the table of schemas used by SRU.

Best regards
Tommy
-----Oprindelig meddelelse-----
Fra: Tommy Schomacker
Sendt: 15. juni 2009 14:06
Til: 'Ray Denenberg'; www-zig@...
Emne: SV: Requesting XML records via Z39.50

Ray - thanks! I am very satisfied with this text. This gives a well defined way to specify schemas and sub schemas.
/Tommy
-----Oprindelig meddelelse-----
Fra: Ray Denenberg [mailto:raydenenberg@...]
Sendt: 11. juni 2009 22:34
Til: Tommy Schomacker; www-zig@...
Emne: Re: Requesting XML records via Z39.50

Tommy - See
http://www.loc.gov/z3950/agency/proposals/request-xml-revised-2009.html

Let me know if this covers it suffficiently.

--Ray

----- Original Message -----
From: "Tommy Schomacker" <TS@...>
To: "Ray Denenberg" <raydenenberg@...>; <www-zig@...>
Sent: Tuesday, May 19, 2009 9:39 AM
Subject: SV: Requesting XML records via Z39.50

Hello Ray et al,

It seems like this topic got into a dead end. I still think we need a
revision of the implementor agreement "Requesting XML Records" from August
2003. The scope of the agreement should be, not to exclude any of the
existing ways, but to describe the various ways used to specify the schema,
and to draw the relation between Z39.50 and SRU - as you have already done
in mails.

The future will bring a lot of XML schemas to be handled by Z39.50 and SRU,
and it would be nice if the same schema identifier could be used in both
protocols. The method using the common OID 1.2.840.10003.5.112 (XML-b), as
the record syntax, and supply a globally unambiguous identifier of the
desired XML definition as the element set name (e.g. an URI) will serve this
purpose. Defining an OID for each schema and subschema is foolish.

I hope you agree.

Best regards
Tommy Schomacker
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Tommy Schomacker
Sendt: 9. marts 2009 15:16
Til: Ray Denenberg; www-zig@...
Emne: SV: Requesting XML records via Z39.50

I suggest we document the 112-method in an implementer's agreement :-)
/Tommy
-----Oprindelig meddelelse-----
Fra: Tommy Schomacker
Sendt: 9. marts 2009 13:26
Til: 'Ray Denenberg'; www-zig@...
Emne: SV: Requesting XML records via Z39.50

We use compSpec in one of our applications, but we will be able to a single
URI-based form for future applications.
/Tommy
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Ray Denenberg
Sendt: 30. januar 2009 00:11
Til: www-zig@...
Emne: Re: Requesting XML records via Z39.50

I agree that using a single form of the schema identifier is preferable, and
that it should be the URI form as used in SRU.

If there is anyone who objects?

If we do that then I would want to cease registering OIDs for new schemas.
We can do that only if nobody is using copmSpec.

So ... is anyone out there using compspec?

--Ray

----- Original Message -----
From: "Tommy Schomacker" <TS@...>
To: "Adam Dickmeiss" <adam@...>; "Ray Denenberg"
<raydenenberg@...>
Cc: <www-zig@...>
Sent: Thursday, January 29, 2009 4:01 AM
Subject: SV: Requesting XML records via Z39.50

Thanks to Ray for the excellent description of the problem and for trying to
find a solution.

First and most important. We need a clear specification on how to deal with
xml schemas and subschemas in Z39.50 and ind SRU. I think Rays proposal
meets this goal.

Second and also important. It would be nice if the schema identifiers
registered for Z39.50 could be valid for SRU too - and vice versa. I think
Rays proposal also will meet this goal if we use URI instead of OID.

Do we need to take compspec into consideration? As I understand it, this is
not used very much and it has no counterpart in SRU.

Best regards
Tommy Schomacker, Danish Bibliographic Centre
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Adam Dickmeiss
Sendt: 29. januar 2009 09:10
Til: Ray Denenberg
Cc: www-zig@...
Emne: Re: Requesting XML records via Z39.50

Ray Denenberg wrote:

> From: Adam Dickmeiss [mailto:adam@...]
>
>> It's also been our assumption that it would be practical to use same
>> schema
>>
> identifiers for both SRU and Z39.50. Why have two registries?
>
>
> Well the problem is that you have to use the OID form if you are supplying
> the schema identifier in the schema field in compspec.

Well. the way I read amendment 5, the schema OID became optional.
http://www.loc.gov/z3950/agency/amend/am5.html
A string , member uri, may be given instead.

The CompSpec has recordSyntax in it and that is required. But that's
not a schema.. So using Amendment 5 we have a way to specify a string
based schema.. Now all this is probably not of interest to many since
it's not widely used, AFAIK.

The element set way.. Page
http://www.loc.gov/z3950/agency/agree/request-xml.html
mentions schema identifiers.. This page even has link to the SRU record
schema identifers.. Although the link no longer works.

My only hope was both that both SRU and Z39.50 would use the same schema
identifiers for XML. Z39.50 has OID based syntax and of course SRU has
recordPacking (but that doesn't affect the schema identifiers).

> You don't have any
> choice there because it's typed as asn.1 OBJECT IDENTIFIER. True, you
> could
> (technically) use the URI form when supplying it within the element set
> name
> parameter (because it has no such restriction). So one way or the other
> you
> end up with two different identfiers: either (a) different for SRU and
> Z39.50, or (b) different for the two ways within Z39.50. And in the second
> case, one of the two will be inconsistent with SRU. So (a) would be the
> lesser of the evils, wouldn't it?
>
> (Or are you suggesting that we use OIDs instead or URIs in SRU. I hope
> not.)
>

Of course not.

/ Adam
> --Ray
>
>
>
>
>
>

SV: Requesting XML records via Z39.50

2009-06-15T05:05:35Z

Ray - thanks! I am very satisfied with this text. This gives a well defined way to specify schemas and sub schemas.
/Tommy
-----Oprindelig meddelelse-----
Fra: Ray Denenberg [mailto:raydenenberg@...]
Sendt: 11. juni 2009 22:34
Til: Tommy Schomacker; www-zig@...
Emne: Re: Requesting XML records via Z39.50

Tommy - See
http://www.loc.gov/z3950/agency/proposals/request-xml-revised-2009.html

Let me know if this covers it suffficiently.

--Ray

----- Original Message -----
From: "Tommy Schomacker" <TS@...>
To: "Ray Denenberg" <raydenenberg@...>; <www-zig@...>
Sent: Tuesday, May 19, 2009 9:39 AM
Subject: SV: Requesting XML records via Z39.50

Hello Ray et al,

It seems like this topic got into a dead end. I still think we need a
revision of the implementor agreement "Requesting XML Records" from August
2003. The scope of the agreement should be, not to exclude any of the
existing ways, but to describe the various ways used to specify the schema,
and to draw the relation between Z39.50 and SRU - as you have already done
in mails.

The future will bring a lot of XML schemas to be handled by Z39.50 and SRU,
and it would be nice if the same schema identifier could be used in both
protocols. The method using the common OID 1.2.840.10003.5.112 (XML-b), as
the record syntax, and supply a globally unambiguous identifier of the
desired XML definition as the element set name (e.g. an URI) will serve this
purpose. Defining an OID for each schema and subschema is foolish.

I hope you agree.

Best regards
Tommy Schomacker
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Tommy Schomacker
Sendt: 9. marts 2009 15:16
Til: Ray Denenberg; www-zig@...
Emne: SV: Requesting XML records via Z39.50

I suggest we document the 112-method in an implementer's agreement :-)
/Tommy
-----Oprindelig meddelelse-----
Fra: Tommy Schomacker
Sendt: 9. marts 2009 13:26
Til: 'Ray Denenberg'; www-zig@...
Emne: SV: Requesting XML records via Z39.50

We use compSpec in one of our applications, but we will be able to a single
URI-based form for future applications.
/Tommy
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Ray Denenberg
Sendt: 30. januar 2009 00:11
Til: www-zig@...
Emne: Re: Requesting XML records via Z39.50

I agree that using a single form of the schema identifier is preferable, and
that it should be the URI form as used in SRU.

If there is anyone who objects?

If we do that then I would want to cease registering OIDs for new schemas.
We can do that only if nobody is using copmSpec.

So ... is anyone out there using compspec?

--Ray

----- Original Message -----
From: "Tommy Schomacker" <TS@...>
To: "Adam Dickmeiss" <adam@...>; "Ray Denenberg"
<raydenenberg@...>
Cc: <www-zig@...>
Sent: Thursday, January 29, 2009 4:01 AM
Subject: SV: Requesting XML records via Z39.50

Thanks to Ray for the excellent description of the problem and for trying to
find a solution.

First and most important. We need a clear specification on how to deal with
xml schemas and subschemas in Z39.50 and ind SRU. I think Rays proposal
meets this goal.

Second and also important. It would be nice if the schema identifiers
registered for Z39.50 could be valid for SRU too - and vice versa. I think
Rays proposal also will meet this goal if we use URI instead of OID.

Do we need to take compspec into consideration? As I understand it, this is
not used very much and it has no counterpart in SRU.

Best regards
Tommy Schomacker, Danish Bibliographic Centre
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Adam Dickmeiss
Sendt: 29. januar 2009 09:10
Til: Ray Denenberg
Cc: www-zig@...
Emne: Re: Requesting XML records via Z39.50

Ray Denenberg wrote:

Of course not.

/ Adam
> --Ray
>
>
>
>
>
>

Re: Requesting XML records via Z39.50

2009-06-11T13:34:00Z

Tommy - See
http://www.loc.gov/z3950/agency/proposals/request-xml-revised-2009.html

Let me know if this covers it suffficiently.

--Ray

----- Original Message -----
From: "Tommy Schomacker" <TS@...>
To: "Ray Denenberg" <raydenenberg@...>; <www-zig@...>
Sent: Tuesday, May 19, 2009 9:39 AM
Subject: SV: Requesting XML records via Z39.50

Hello Ray et al,

It seems like this topic got into a dead end. I still think we need a
revision of the implementor agreement "Requesting XML Records" from August
2003. The scope of the agreement should be, not to exclude any of the
existing ways, but to describe the various ways used to specify the schema,
and to draw the relation between Z39.50 and SRU - as you have already done
in mails.

The future will bring a lot of XML schemas to be handled by Z39.50 and SRU,
and it would be nice if the same schema identifier could be used in both
protocols. The method using the common OID 1.2.840.10003.5.112 (XML-b), as
the record syntax, and supply a globally unambiguous identifier of the
desired XML definition as the element set name (e.g. an URI) will serve this
purpose. Defining an OID for each schema and subschema is foolish.

I hope you agree.

Best regards
Tommy Schomacker
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Tommy Schomacker
Sendt: 9. marts 2009 15:16
Til: Ray Denenberg; www-zig@...
Emne: SV: Requesting XML records via Z39.50

I suggest we document the 112-method in an implementer's agreement :-)
/Tommy
-----Oprindelig meddelelse-----
Fra: Tommy Schomacker
Sendt: 9. marts 2009 13:26
Til: 'Ray Denenberg'; www-zig@...
Emne: SV: Requesting XML records via Z39.50

We use compSpec in one of our applications, but we will be able to a single
URI-based form for future applications.
/Tommy
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Ray Denenberg
Sendt: 30. januar 2009 00:11
Til: www-zig@...
Emne: Re: Requesting XML records via Z39.50

I agree that using a single form of the schema identifier is preferable, and
that it should be the URI form as used in SRU.

If there is anyone who objects?

If we do that then I would want to cease registering OIDs for new schemas.
We can do that only if nobody is using copmSpec.

So ... is anyone out there using compspec?

--Ray

----- Original Message -----
From: "Tommy Schomacker" <TS@...>
To: "Adam Dickmeiss" <adam@...>; "Ray Denenberg"
<raydenenberg@...>
Cc: <www-zig@...>
Sent: Thursday, January 29, 2009 4:01 AM
Subject: SV: Requesting XML records via Z39.50

Thanks to Ray for the excellent description of the problem and for trying to
find a solution.

First and most important. We need a clear specification on how to deal with
xml schemas and subschemas in Z39.50 and ind SRU. I think Rays proposal
meets this goal.

Second and also important. It would be nice if the schema identifiers
registered for Z39.50 could be valid for SRU too - and vice versa. I think
Rays proposal also will meet this goal if we use URI instead of OID.

Do we need to take compspec into consideration? As I understand it, this is
not used very much and it has no counterpart in SRU.

Best regards
Tommy Schomacker, Danish Bibliographic Centre
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Adam Dickmeiss
Sendt: 29. januar 2009 09:10
Til: Ray Denenberg
Cc: www-zig@...
Emne: Re: Requesting XML records via Z39.50

Ray Denenberg wrote:

Of course not.

/ Adam
> --Ray
>
>
>
>
>
>

Re: Requesting XML records via Z39.50

2009-05-19T13:30:27Z

Tommy - Yes, I agree completely. Sorry this has slipped and thank you for
bringing it back up. I just spent some time reviewing the entire discussion
on this.

I agree that we do not need to continue to assign OIDs for every schema, and
that in the typical case the schema identifier used for SRU should also be
used for Z39.50. There may still be cases where OIDs need to be used and we
can treat them as special cases.

The remaining question is what will SRU use for schema identifiers, as there
is currently discussion about aligning SRU andOpenURL identifiers. But I
expect that discussion to be resolved quickly.

In any case, we can revise the agreement to reflect this.

--Ray

----- Original Message -----
From: "Tommy Schomacker" <TS@...>
To: "Ray Denenberg" <raydenenberg@...>; <www-zig@...>
Sent: Tuesday, May 19, 2009 9:39 AM
Subject: SV: Requesting XML records via Z39.50

Hello Ray et al,

It seems like this topic got into a dead end. I still think we need a
revision of the implementor agreement "Requesting XML Records" from August
2003. The scope of the agreement should be, not to exclude any of the
existing ways, but to describe the various ways used to specify the schema,
and to draw the relation between Z39.50 and SRU - as you have already done
in mails.

The future will bring a lot of XML schemas to be handled by Z39.50 and SRU,
and it would be nice if the same schema identifier could be used in both
protocols. The method using the common OID 1.2.840.10003.5.112 (XML-b), as
the record syntax, and supply a globally unambiguous identifier of the
desired XML definition as the element set name (e.g. an URI) will serve this
purpose. Defining an OID for each schema and subschema is foolish.

I hope you agree.

Best regards
Tommy Schomacker
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Tommy Schomacker
Sendt: 9. marts 2009 15:16
Til: Ray Denenberg; www-zig@...
Emne: SV: Requesting XML records via Z39.50

I suggest we document the 112-method in an implementer's agreement :-)
/Tommy
-----Oprindelig meddelelse-----
Fra: Tommy Schomacker
Sendt: 9. marts 2009 13:26
Til: 'Ray Denenberg'; www-zig@...
Emne: SV: Requesting XML records via Z39.50

We use compSpec in one of our applications, but we will be able to a single
URI-based form for future applications.
/Tommy
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Ray Denenberg
Sendt: 30. januar 2009 00:11
Til: www-zig@...
Emne: Re: Requesting XML records via Z39.50

I agree that using a single form of the schema identifier is preferable, and
that it should be the URI form as used in SRU.

If there is anyone who objects?

If we do that then I would want to cease registering OIDs for new schemas.
We can do that only if nobody is using copmSpec.

So ... is anyone out there using compspec?

--Ray

----- Original Message -----
From: "Tommy Schomacker" <TS@...>
To: "Adam Dickmeiss" <adam@...>; "Ray Denenberg"
<raydenenberg@...>
Cc: <www-zig@...>
Sent: Thursday, January 29, 2009 4:01 AM
Subject: SV: Requesting XML records via Z39.50

Thanks to Ray for the excellent description of the problem and for trying to
find a solution.

First and most important. We need a clear specification on how to deal with
xml schemas and subschemas in Z39.50 and ind SRU. I think Rays proposal
meets this goal.

Second and also important. It would be nice if the schema identifiers
registered for Z39.50 could be valid for SRU too - and vice versa. I think
Rays proposal also will meet this goal if we use URI instead of OID.

Do we need to take compspec into consideration? As I understand it, this is
not used very much and it has no counterpart in SRU.

Best regards
Tommy Schomacker, Danish Bibliographic Centre
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Adam Dickmeiss
Sendt: 29. januar 2009 09:10
Til: Ray Denenberg
Cc: www-zig@...
Emne: Re: Requesting XML records via Z39.50

Ray Denenberg wrote:

Of course not.

/ Adam
> --Ray
>
>
>
>
>
>

SV: Requesting XML records via Z39.50

2009-05-19T06:39:32Z

Hello Ray et al,

It seems like this topic got into a dead end. I still think we need a revision of the implementor agreement "Requesting XML Records" from August 2003. The scope of the agreement should be, not to exclude any of the existing ways, but to describe the various ways used to specify the schema, and to draw the relation between Z39.50 and SRU - as you have already done in mails.

The future will bring a lot of XML schemas to be handled by Z39.50 and SRU, and it would be nice if the same schema identifier could be used in both protocols. The method using the common OID 1.2.840.10003.5.112 (XML-b), as the record syntax, and supply a globally unambiguous identifier of the desired XML definition as the element set name (e.g. an URI) will serve this purpose. Defining an OID for each schema and subschema is foolish.

I hope you agree.

Best regards
Tommy Schomacker
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Tommy Schomacker
Sendt: 9. marts 2009 15:16
Til: Ray Denenberg; www-zig@...
Emne: SV: Requesting XML records via Z39.50

I suggest we document the 112-method in an implementer's agreement :-)
/Tommy
-----Oprindelig meddelelse-----
Fra: Tommy Schomacker
Sendt: 9. marts 2009 13:26
Til: 'Ray Denenberg'; www-zig@...
Emne: SV: Requesting XML records via Z39.50

We use compSpec in one of our applications, but we will be able to a single URI-based form for future applications.
/Tommy
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Ray Denenberg
Sendt: 30. januar 2009 00:11
Til: www-zig@...
Emne: Re: Requesting XML records via Z39.50

I agree that using a single form of the schema identifier is preferable, and
that it should be the URI form as used in SRU.

If there is anyone who objects?

If we do that then I would want to cease registering OIDs for new schemas.
We can do that only if nobody is using copmSpec.

So ... is anyone out there using compspec?

--Ray

----- Original Message -----
From: "Tommy Schomacker" <TS@...>
To: "Adam Dickmeiss" <adam@...>; "Ray Denenberg"
<raydenenberg@...>
Cc: <www-zig@...>
Sent: Thursday, January 29, 2009 4:01 AM
Subject: SV: Requesting XML records via Z39.50

Thanks to Ray for the excellent description of the problem and for trying to
find a solution.

First and most important. We need a clear specification on how to deal with
xml schemas and subschemas in Z39.50 and ind SRU. I think Rays proposal
meets this goal.

Second and also important. It would be nice if the schema identifiers
registered for Z39.50 could be valid for SRU too - and vice versa. I think
Rays proposal also will meet this goal if we use URI instead of OID.

Do we need to take compspec into consideration? As I understand it, this is
not used very much and it has no counterpart in SRU.

Best regards
Tommy Schomacker, Danish Bibliographic Centre
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Adam Dickmeiss
Sendt: 29. januar 2009 09:10
Til: Ray Denenberg
Cc: www-zig@...
Emne: Re: Requesting XML records via Z39.50

Ray Denenberg wrote:

Of course not.

/ Adam
> --Ray
>
>
>
>
>
>

NWeSP 2009 - Call for Papers

2009-05-11T12:09:31Z

-----------------------------------------------------------------
NWESP 2009 -- CALL FOR PAPERS

Deadline is extended until June 5.
-----------------------------------------------------------------

5th International Conference on Next Generation Web Services Practices
September 9-11, 2009
Prague, Czech Republic

http://arg.vsb.cz/NWeSP09/Default.aspx

Publication by: IEEE Computer Society (indexed by EI)
Past proceedings:
http://csdl2.computer.org/persagen/DLPublication.jsp?pubtype=p&acronym=NWESP

International Conference on Next Generation Web Services Practices
(NWeSP'09) is a forum which brings together researchers and
practitioners specializing on different aspects of Web based
information systems.

The conference will bring together the world's most respected
authorities on semantic web, Web based services, Web applications, Web
enhanced business information systems, e-education specialists,
Information security, and other Web related technologies. The aim of
NWeSP'08 is to serve as a forum to present current and future work as
well as to exchange research ideas in this field.

NWeSP'09 invites authors to submit their original and unpublished work
that demonstrate current research in all areas of Web based
information systems and their applications in science, technology,
business and commerce. The aim of the conference is to provide a
platform to the researchers and practitioners
from both academia as well as industry to meet and share cutting-edge
development in the field.

-----------------------------------------------------------------
TOPICS
-----------------------------------------------------------------

Topics of interest include all areas of Web Services and Web Applications.
Poster session, workshops, and cultural events are planned.

We solicit original research and technical papers not published elsewhere.
The papers can be theoretical, practical and application oriented on
the following themes (but not limited to):

* Web Services Architecture, Modeling and Design
* Internet and Web-based Applications and Services
* Semantic Web, Ontologies (creation , merging, linking and reconciliation)
* Database Technologies for Web Services
* Web Services Security
* Quality of Service, Scalability and Performance
* User Interfaces, Visualization and modeling
* Customization, Reusability, Enhancements
* Web Services Standards
* Web Services Applications
* Web Based Applications
* Information Retrieval
* Semantic Query & Search
* Web Services Intellectual Property
* Knowledge sharing in the Web
* Semantic interoperability approaches
* Ontology-based interoperability
* Social and Legal Aspect of Internet Computing
* XML technologies
* Composition approaches for Web services
* Business process modeling, integration, and collaboration

-----------------------------------------------------------------
WE INVITE YOU TO SUBMIT A:
-----------------------------------------------------------------

- Full Paper(Upto 6 pages): Oral Presentation is required
- Short Paper(Upto 4 pages): Poster Presentation

-----------------------------------------------------------------
PAPERS FORMATTING
-----------------------------------------------------------------

The paper must be prepared according to IEEE CS style format. Please
download the templates from the following link: Templates
Authors may find additional information from the following link:
ftp://pubftp.computer.org/Press/Outgoing/proceedings/

-----------------------------------------------------------------
JOURNAL PUBLICATION OPPORTUNITIES
-----------------------------------------------------------------

Endorsed by the IEEE Computer Society
NWeSP 2005-2008 proceedings:
http://csdl2.computer.org/persagen/DLPublication.jsp?pubtype=p&acronym=NWESP
Publication: IEEE Computer Society, USA (indexed by EI)
Additional Publication: Selected papers will be invited to IJWSP and a
few other journals.

-----------------------------------------------------------------
IMPORTANT DATES
-----------------------------------------------------------------

Paper Submission (Extended Deadline): June 5, 2009
Notification of acceptance: June 20, 2009
Camera-ready of accepted papers: June 30, 2009
Registration: June 30, 2009
Conference: September 9-11, 2009

-----------------------------------------------------------------
GENERAL CO-CHAIRS
-----------------------------------------------------------------

Vaclav Snasel, VSB-Technical University of Ostrava, Czech Republic
Dusan Husek, Institute of Computer Science, Academy of Science, Czech Republic
Sang Yong Han, Chung-Ang University, Korea

****************************************************************

SV: Requesting XML records via Z39.50

2009-03-09T07:15:50Z

I suggest we document the 112-method in an implementer's agreement :-)
/Tommy
-----Oprindelig meddelelse-----
Fra: Tommy Schomacker
Sendt: 9. marts 2009 13:26
Til: 'Ray Denenberg'; www-zig@...
Emne: SV: Requesting XML records via Z39.50

We use compSpec in one of our applications, but we will be able to a single URI-based form for future applications.
/Tommy
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Ray Denenberg
Sendt: 30. januar 2009 00:11
Til: www-zig@...
Emne: Re: Requesting XML records via Z39.50

I agree that using a single form of the schema identifier is preferable, and
that it should be the URI form as used in SRU.

If there is anyone who objects?

If we do that then I would want to cease registering OIDs for new schemas.
We can do that only if nobody is using copmSpec.

So ... is anyone out there using compspec?

--Ray

----- Original Message -----
From: "Tommy Schomacker" <TS@...>
To: "Adam Dickmeiss" <adam@...>; "Ray Denenberg"
<raydenenberg@...>
Cc: <www-zig@...>
Sent: Thursday, January 29, 2009 4:01 AM
Subject: SV: Requesting XML records via Z39.50

Thanks to Ray for the excellent description of the problem and for trying to
find a solution.

First and most important. We need a clear specification on how to deal with
xml schemas and subschemas in Z39.50 and ind SRU. I think Rays proposal
meets this goal.

Second and also important. It would be nice if the schema identifiers
registered for Z39.50 could be valid for SRU too - and vice versa. I think
Rays proposal also will meet this goal if we use URI instead of OID.

Do we need to take compspec into consideration? As I understand it, this is
not used very much and it has no counterpart in SRU.

Best regards
Tommy Schomacker, Danish Bibliographic Centre
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Adam Dickmeiss
Sendt: 29. januar 2009 09:10
Til: Ray Denenberg
Cc: www-zig@...
Emne: Re: Requesting XML records via Z39.50

Ray Denenberg wrote:

Of course not.

/ Adam
> --Ray
>
>
>
>
>
>

SV: Requesting XML records via Z39.50

2009-03-09T05:26:17Z

We use compSpec in one of our applications, but we will be able to a single URI-based form for future applications.
/Tommy
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Ray Denenberg
Sendt: 30. januar 2009 00:11
Til: www-zig@...
Emne: Re: Requesting XML records via Z39.50

I agree that using a single form of the schema identifier is preferable, and
that it should be the URI form as used in SRU.

If there is anyone who objects?

If we do that then I would want to cease registering OIDs for new schemas.
We can do that only if nobody is using copmSpec.

So ... is anyone out there using compspec?

--Ray

----- Original Message -----
From: "Tommy Schomacker" <TS@...>
To: "Adam Dickmeiss" <adam@...>; "Ray Denenberg"
<raydenenberg@...>
Cc: <www-zig@...>
Sent: Thursday, January 29, 2009 4:01 AM
Subject: SV: Requesting XML records via Z39.50

Thanks to Ray for the excellent description of the problem and for trying to
find a solution.

First and most important. We need a clear specification on how to deal with
xml schemas and subschemas in Z39.50 and ind SRU. I think Rays proposal
meets this goal.

Second and also important. It would be nice if the schema identifiers
registered for Z39.50 could be valid for SRU too - and vice versa. I think
Rays proposal also will meet this goal if we use URI instead of OID.

Do we need to take compspec into consideration? As I understand it, this is
not used very much and it has no counterpart in SRU.

Best regards
Tommy Schomacker, Danish Bibliographic Centre
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Adam Dickmeiss
Sendt: 29. januar 2009 09:10
Til: Ray Denenberg
Cc: www-zig@...
Emne: Re: Requesting XML records via Z39.50

Ray Denenberg wrote:

Of course not.

/ Adam
> --Ray
>
>
>
>
>
>

Re: Requesting XML records via Z39.50

2009-01-29T15:10:33Z

I agree that using a single form of the schema identifier is preferable, and
that it should be the URI form as used in SRU.

If there is anyone who objects?

If we do that then I would want to cease registering OIDs for new schemas.
We can do that only if nobody is using copmSpec.

So ... is anyone out there using compspec?

--Ray

----- Original Message -----
From: "Tommy Schomacker" <TS@...>
To: "Adam Dickmeiss" <adam@...>; "Ray Denenberg"
<raydenenberg@...>
Cc: <www-zig@...>
Sent: Thursday, January 29, 2009 4:01 AM
Subject: SV: Requesting XML records via Z39.50

Thanks to Ray for the excellent description of the problem and for trying to
find a solution.

First and most important. We need a clear specification on how to deal with
xml schemas and subschemas in Z39.50 and ind SRU. I think Rays proposal
meets this goal.

Second and also important. It would be nice if the schema identifiers
registered for Z39.50 could be valid for SRU too - and vice versa. I think
Rays proposal also will meet this goal if we use URI instead of OID.

Do we need to take compspec into consideration? As I understand it, this is
not used very much and it has no counterpart in SRU.

Best regards
Tommy Schomacker, Danish Bibliographic Centre
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Adam Dickmeiss
Sendt: 29. januar 2009 09:10
Til: Ray Denenberg
Cc: www-zig@...
Emne: Re: Requesting XML records via Z39.50

Ray Denenberg wrote:

Of course not.

/ Adam
> --Ray
>
>
>
>
>
>

SV: Requesting XML records via Z39.50

2009-01-29T01:01:04Z

Thanks to Ray for the excellent description of the problem and for trying to find a solution.

First and most important. We need a clear specification on how to deal with xml schemas and subschemas in Z39.50 and ind SRU. I think Rays proposal meets this goal.

Second and also important. It would be nice if the schema identifiers registered for Z39.50 could be valid for SRU too - and vice versa. I think Rays proposal also will meet this goal if we use URI instead of OID.

Do we need to take compspec into consideration? As I understand it, this is not used very much and it has no counterpart in SRU.

Best regards
Tommy Schomacker, Danish Bibliographic Centre
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Adam Dickmeiss
Sendt: 29. januar 2009 09:10
Til: Ray Denenberg
Cc: www-zig@...
Emne: Re: Requesting XML records via Z39.50

Ray Denenberg wrote:
> From: Adam Dickmeiss [mailto:adam@...]
>
>> It's also been our assumption that it would be practical to use same schema
>>
> identifiers for both SRU and Z39.50. Why have two registries?
>
>
> Well the problem is that you have to use the OID form if you are supplying
> the schema identifier in the schema field in compspec.
Well. the way I read amendment 5, the schema OID became optional.
http://www.loc.gov/z3950/agency/amend/am5.html
A string , member uri, may be given instead.

The CompSpec has recordSyntax in it and that is required. But that's
not a schema.. So using Amendment 5 we have a way to specify a string
based schema.. Now all this is probably not of interest to many since
it's not widely used, AFAIK.

The element set way.. Page
http://www.loc.gov/z3950/agency/agree/request-xml.html
mentions schema identifiers.. This page even has link to the SRU record
schema identifers.. Although the link no longer works.

My only hope was both that both SRU and Z39.50 would use the same schema
identifiers for XML. Z39.50 has OID based syntax and of course SRU has
recordPacking (but that doesn't affect the schema identifiers).

> You don't have any
> choice there because it's typed as asn.1 OBJECT IDENTIFIER. True, you could
> (technically) use the URI form when supplying it within the element set name
> parameter (because it has no such restriction). So one way or the other you
> end up with two different identfiers: either (a) different for SRU and
> Z39.50, or (b) different for the two ways within Z39.50. And in the second
> case, one of the two will be inconsistent with SRU. So (a) would be the
> lesser of the evils, wouldn't it?
>
> (Or are you suggesting that we use OIDs instead or URIs in SRU. I hope not.)
>

Of course not.

/ Adam
> --Ray
>
>
>
>
>
>

Re: Requesting XML records via Z39.50

2009-01-29T00:10:23Z

Ray Denenberg wrote:
> From: Adam Dickmeiss [mailto:adam@...]
>
>> It's also been our assumption that it would be practical to use same schema
>>
> identifiers for both SRU and Z39.50. Why have two registries?
>
>
> Well the problem is that you have to use the OID form if you are supplying
> the schema identifier in the schema field in compspec.
Well. the way I read amendment 5, the schema OID became optional.
http://www.loc.gov/z3950/agency/amend/am5.html
A string , member uri, may be given instead.

The CompSpec has recordSyntax in it and that is required. But that's
not a schema.. So using Amendment 5 we have a way to specify a string
based schema.. Now all this is probably not of interest to many since
it's not widely used, AFAIK.

The element set way.. Page
http://www.loc.gov/z3950/agency/agree/request-xml.html
mentions schema identifiers.. This page even has link to the SRU record
schema identifers.. Although the link no longer works.

My only hope was both that both SRU and Z39.50 would use the same schema
identifiers for XML. Z39.50 has OID based syntax and of course SRU has
recordPacking (but that doesn't affect the schema identifiers).

Of course not.

/ Adam
> --Ray
>
>
>
>
>
>

RE: Requesting XML records via Z39.50

2009-01-28T15:49:04Z

From: Adam Dickmeiss [mailto:adam@...]
>It's also been our assumption that it would be practical to use same schema
identifiers for both SRU and Z39.50. Why have two registries?

Well the problem is that you have to use the OID form if you are supplying
the schema identifier in the schema field in compspec. You don't have any
choice there because it's typed as asn.1 OBJECT IDENTIFIER. True, you could
(technically) use the URI form when supplying it within the element set name
parameter (because it has no such restriction). So one way or the other you
end up with two different identfiers: either (a) different for SRU and
Z39.50, or (b) different for the two ways within Z39.50. And in the second
case, one of the two will be inconsistent with SRU. So (a) would be the
lesser of the evils, wouldn't it?

(Or are you suggesting that we use OIDs instead or URIs in SRU. I hope not.)

--Ray

Re: Requesting XML records via Z39.50

2009-01-28T02:12:02Z

Ray Denenberg writes:
> So, we registered 1.2.840.10003.5.109.10 as the record syntax for
> XML, for use as just described. Then someone asked "XML version
> 1.0 or 1.1"? So we registered 1.2.840.10003.5.109.10.1.0 and
> 1.2.840.10003.5.109.10.1.1 for these versions and designated
> 1.2.840.10003.5.109.10 as "no specific version". Why did we
> register these version specific identifiers? Because we thought we
> had to; we didn't know any better at the time.
>
> Three things in particular led to the implementor agreement, to use
> 112 and put the schema in the element set name parameter.

... and let's not even get into Index Data's misappropriation of
1.2.840.10003.5.109.11 to represent application/xml as opposed to
text/xml :-)

_/|_ ___________________________________________________________________
/o ) \/ Mike Taylor <mike@...> http://www.miketaylor.org.uk
)_v__/\ "Cold-hearted orb that rules the night // Removes the colors from
our sight // Red is gray, and yellow white // But we decide which
is right // And which is a quantization error" -- ppmtopgm(1)
manual entry.

Re: Requesting XML records via Z39.50

2009-01-28T00:30:03Z

Ray Denenberg wrote:

>
> If I may, please indulge me as I review some of the history behind all
> these object identifiers, etc. and I hope this may provide some
> historical perspective.
>
> When we began to talk about XML for Z39.50 (roughly, ten years ago),
> we viewed it (correctly) as a record syntax analogous to GRS-1. If
> you don't remember GRS-1, it is sufficient to say that it was the
> pre-XML functional equivalent of XML - a generic syntax, meaningful
> only when used in conjunction with a schema and namespace (which
> Z39.50 called a tagset). This is in contrast to record syntaxes like
> the various marcs, which had built-in schemas and tagsets.
>
> Thus: GRS-1 was a record syntax; XML was a record syntax. GRS-1
> worked with Z39.50 schemas and tagsets; XML worked with XML schemas
> and namespaces.
>
> It is also necessary (though painful) to point out that GRS-1 worked
> also with "dynamic element specifications", for which there is no
> real XML analogy. These dynamic element specifications were
> generalizations of the more "static" element set names; you may recall
> the specification eSpec-1. It is necessary to mention this because of
> the compSpec story: compSpec was provided in Z39.50-1995 as a complex
> alternative to using just a record syntax and element set name-
> "marc" with "brief", for example. Compspec assumed that you would
> use grs-1 as the record syntax, and also specify a schema. And in
> addition, perhaps an eSpec specification. Then XML came along at
> which point compSpec assumed you would use either GRS-1 or XML as the
> record syntax, and correspondingly a GRS-1 or XML schema (and if
> GRS-1, perhaps also an eSpec specification).
>
> This is boring I know, but it gets a bit more interesting now (or at
> least more relevant).
>
> So, we registered 1.2.840.10003.5.109.10 as the record syntax for XML,
> for use as just described. Then someone asked "XML version 1.0 or
> 1.1"? So we registered 1.2.840.10003.5.109.10.1.0 and
> 1.2.840.10003.5.109.10.1.1 for these versions and designated
> 1.2.840.10003.5.109.10 as "no specific version". Why did we register
> these version specific identifiers? Because we thought we had to; we
> didn't know any better at the time.
>
> Three things in particular led to the implementor agreement, to use
> 112 and put the schema in the element set name parameter.
>
> 1. Very few if any implementors wanted to implement compSpec. There
> was a popular cry to be able to simply specify the record syntax as
> XML and some way to indicate the XML schema, but without using
> compSpec. Of course the purists (me included) pointed out that this
> was what compSpec was invented for! Not using it would be a cludge!
> The counter argument was, no, compSpec was invented for dynamic
> element specification and nobody is going to implement it. (The truth
> was somewhere in between. It was invented for both purposes.) And
> compSpec was too complicated.
>
> 2. After much debate and discussion, the ZIG decided that an element
> set in the XML environment is a schema. (A subschema, perhaps, but a
> schema nevertheless).
>
> 3. There needed to be a clean break from the confusing XML OIDS,
> 109.10, 109.10.1.0, and 109.10.1.1 which were all supposed to be used
> with compSpec anyway. So we decided to register a completely new OID,
> 112, to represent XML for use as described in the agreement.
>
> I hope this helps some.

I fully to make the implementors agreement for using element set as
schema. I just never understood the reasons to make a new OID. Clients
either use Comspec and use the string arm (Amendment 5) or they use
element set and put schema there.. For our software in both cases we
retained the original OID. The servers, in turn, would see syntax==XML
and look for schema in either the complex spec or element set name..
Semantics thereafter were exactly the same.

As for XML 1.1 or XML 1.0.. 1.0 prevail and I have yet to see servers
that can deliver both types for some schema.

It's also been our assumption that it would be practical to use same
schema identifiers for both SRU and Z39.50. Why have two registries?
Z39.50 is just another carrier for XML.. albeit a much more efficient one:-)

/ Adam

>
> --Ray
>
> ----- Original Message ----- From: "Tommy Schomacker" <TS@...>
> To: "Adam Dickmeiss" <adam@...>; <www-zig@...>
> Cc: <www-zig@...>
> Sent: Tuesday, January 27, 2009 4:16 AM
> Subject: SV: Requesting XML records via Z39.50
>
>
>
> Hi Adam,
>
> What OID is "the original one"? I have found these OID for XML record
> syntaxes in the registry:
> 1.2.840.10003.5.109.10 xml (no specific version)
> 1.2.840.10003.5.109.10.1.0 xml version 1.0
> 1.2.840.10003.5.109.10.1.1 xml version 1.1
> 1.2.840.10003.5.110 Z39.50 mime types
> 1.2.840.10003.5.112 xml-b XML record according to the schema or
> definition identified by the element set name.
>
> Best regards
> Tommy
>
>
>

Re: Requesting XML records via Z39.50

2009-01-27T14:43:11Z

If I may, please indulge me as I review some of the history behind all these
object identifiers, etc. and I hope this may provide some historical
perspective.

When we began to talk about XML for Z39.50 (roughly, ten years ago), we
viewed it (correctly) as a record syntax analogous to GRS-1. If you don't
remember GRS-1, it is sufficient to say that it was the pre-XML functional
equivalent of XML - a generic syntax, meaningful only when used in
conjunction with a schema and namespace (which Z39.50 called a tagset). This
is in contrast to record syntaxes like the various marcs, which had built-in
schemas and tagsets.

Thus: GRS-1 was a record syntax; XML was a record syntax. GRS-1 worked with
Z39.50 schemas and tagsets; XML worked with XML schemas and namespaces.

It is also necessary (though painful) to point out that GRS-1 worked also
with "dynamic element specifications", for which there is no real XML
analogy. These dynamic element specifications were generalizations of the
more "static" element set names; you may recall the specification eSpec-1.
It is necessary to mention this because of the compSpec story: compSpec was
provided in Z39.50-1995 as a complex alternative to using just a record
syntax and element set name- "marc" with "brief", for example. Compspec
assumed that you would use grs-1 as the record syntax, and also specify a
schema. And in addition, perhaps an eSpec specification. Then XML came
along at which point compSpec assumed you would use either GRS-1 or XML as
the record syntax, and correspondingly a GRS-1 or XML schema (and if GRS-1,
perhaps also an eSpec specification).

This is boring I know, but it gets a bit more interesting now (or at least
more relevant).

So, we registered 1.2.840.10003.5.109.10 as the record syntax for XML, for
use as just described. Then someone asked "XML version 1.0 or 1.1"? So we
registered 1.2.840.10003.5.109.10.1.0 and 1.2.840.10003.5.109.10.1.1 for
these versions and designated 1.2.840.10003.5.109.10 as "no specific
version". Why did we register these version specific identifiers? Because we
thought we had to; we didn't know any better at the time.

Three things in particular led to the implementor agreement, to use 112 and
put the schema in the element set name parameter.

1. Very few if any implementors wanted to implement compSpec. There was a
popular cry to be able to simply specify the record syntax as XML and some
way to indicate the XML schema, but without using compSpec. Of course the
purists (me included) pointed out that this was what compSpec was invented
for! Not using it would be a cludge! The counter argument was, no, compSpec
was invented for dynamic element specification and nobody is going to
implement it. (The truth was somewhere in between. It was invented for both
purposes.) And compSpec was too complicated.

2. After much debate and discussion, the ZIG decided that an element set in
the XML environment is a schema. (A subschema, perhaps, but a schema
nevertheless).

3. There needed to be a clean break from the confusing XML OIDS, 109.10,
109.10.1.0, and 109.10.1.1 which were all supposed to be used with compSpec
anyway. So we decided to register a completely new OID, 112, to represent
XML for use as described in the agreement.

I hope this helps some.

--Ray

----- Original Message -----
From: "Tommy Schomacker" <TS@...>
To: "Adam Dickmeiss" <adam@...>; <www-zig@...>
Cc: <www-zig@...>
Sent: Tuesday, January 27, 2009 4:16 AM
Subject: SV: Requesting XML records via Z39.50

Hi Adam,

What OID is "the original one"? I have found these OID for XML record
syntaxes in the registry:
1.2.840.10003.5.109.10 xml (no specific version)
1.2.840.10003.5.109.10.1.0 xml version 1.0
1.2.840.10003.5.109.10.1.1 xml version 1.1
1.2.840.10003.5.110 Z39.50 mime types
1.2.840.10003.5.112 xml-b XML record according to the schema or definition
identified by the element set name.

Best regards
Tommy

Re: Requesting XML records via Z39.50

2009-01-27T04:38:51Z

On Mon, 26 Jan 2009 14:24:24 -0500, Archie Warnock wrote

Given that we have a lot of common genes to Isite/Isearch--- just
heavily mutated over the years into a new species-- I've been using these
as well..
{sgmlRecordSyntax, "1.2.840.10003.5.109.9"},
{XmlRecordSyntax, "1.2.840.10003.5.109.10"},
{applicationXMLRecordSyntax, "1.2.840.10003.5.109.11"},

> only XML we know about - ie, the record we ingested. This works reasonably

I, however, don't just deliver the record as ingested unless, of course, the
record ingested was XML or SGML but, if possible, I try to on-the-fly create
a XML "representation"--- or whatever Record Syntax was requested---- of the
record content as "stored" (which, in turns, depends upon how it was
"ingested"). The XML schema/DTDs are, of course, only what they have
wired in. For conversions to other Schemas/DTD--- or even other formats
or variations from those whose Record Syntaxes we handle--- we have a design
that allows for external methods/programs/functions to be specified. This has
gotten a lot of use for HTML within workflow solutions but I don't think
anyone has bothered to use it to get a record based upon a different XML
Schema/DTD from the one normally returned. My wired in XML for eMail is
different from MarkLogic's but in typical use I don't think it matters to
anyone other than us (and them). I don't quite see the business case for
search-time arbitrary schema conversion requests by users--- and nobody has
ever asked for it and we've had some pretty wild (and ill thought out)
requests over the years :-)

The element set name in our case is the element set (or path to a fragment)
and NOT the schema identifier. In projects were we have needed multiple
schema we have deployed private OIDs like 1.2.840.10003.5.1000.34.3,
1.2.840.10003.5.1000.34.4.1, 1.2.840.10003.5.1000.34.4.2,
1.2.840.10003.5.1000.34.4.3 ...

Paths/Fragments etc. are important to us since we don't always work with
records as the unit of recall but either user specified (directions or paths)
or heuristically (search time) determined paths.

> well since the schema is usually either known or agreed to a priori
> or included in the XML anyway, in which case the returned XML is
> self-documenting and it's up to the requesting client what to do
> with it.
As the original intent :-)

--

Edward C. Zimmermann, NONMONOTONIC LAB
Basis Systeme netzwerk, Munich Ges. des buergerl. Rechts
Office Leo (R&D):
Leopoldstrasse 53-55, D-80802 Munich,
Federal Republic of Germany
http://www.nonmonotonic.net
Umsatz-St-ID: DE130492967

Re: SV: Requesting XML records via Z39.50

2009-01-27T02:34:55Z

Tommy Schomacker wrote:
> Hi Adam,
>
> What OID is "the original one"? I have found these OID for XML record syntaxes in the registry:
> 1.2.840.10003.5.109.10 xml (no specific version)
>
This one:

1.2.840.10003.5.109.10

/ Adam

> 1.2.840.10003.5.109.10.1.0 xml version 1.0
> 1.2.840.10003.5.109.10.1.1 xml version 1.1
> 1.2.840.10003.5.110 Z39.50 mime types
> 1.2.840.10003.5.112 xml-b XML record according to the schema or definition identified by the element set name.
>
> Best regards
> Tommy
> -----Oprindelig meddelelse-----
> Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
> Adam Dickmeiss
> Sendt: 26. januar 2009 21:58
> Til: www-zig@...
> Cc: www-zig@...
> Emne: Re: Requesting XML records via Z39.50
>
>
>
> Ray Denenberg, Library of Congress wrote:
>
>> Archie, I don't want anyone to change their implementation behavior
>> based on the existing or a revised agreement. So this is useful
>> feedback, thanks. I would like to incorporate existing implementation
>> practice into the revised procedure.
>>
>> I think that the 110 record syntax was first registered with the idea
>> that the XML schema was known by private agreement. (Subseqently we
>> registered 112 to use in the case when you want to also specify the
>> schema.) It sounds like what you are doing is consisitent with what
>> we had in mind. I'll write this into the revised agreement.
>>
> We're pretty much in the same wagon as Archie. AFAIK, we have never used
> any other OID for XML than the original one. Most often the element set
> name further specifies the requested schema. In other words, like the
> (xml-b) implementor's agreement but using the original OID.
>
> / Adam
>
>> Any other feedback on this is also welcome.
>>
>> --Ray
>>
>> ----- Original Message ----- From: "Archie Warnock" <warnock@...>
>> To: "Ray Denenberg, Library of Congress" <rden@...>
>> Cc: <www-zig@...>
>> Sent: Monday, January 26, 2009 2:24 PM
>> Subject: Re: Requesting XML records via Z39.50
>>
>>
>>
>>> Ray Denenberg, Library of Congress wrote:
>>>
>>>> I would like to revisit the implementor agreement on "Requesting XML
>>>> Records", http://www.loc.gov/z3950/agency/agree/request-xml.html,
>>>> as it
>>>> has been many years since it we've discussed it, and it does seem to
>>>> warrant some clarification.
>>>>
>>> And note that the link in that page
>>> (http://www.loc.gov/z3950/agency/zing/srw/records.html) is no longer
>>> valid.
>>>
>>>
>>>> Briefly, to retrieve records according to a specific XML schema using
>>>> Z39.50 (if you DON'T want to use compSpec):
>>>> 1. XML is specified as the record syntax, specifically 'xml-b':
>>>> 1.2.840.10003.5.112.
>>>> 2. The schema identifier is specified as the element set name.
>>>>
>>> Somehow I missed the original Implementor's Agreement and Isite has been
>>> happily chugging along without it. We don't use compSpec in Isite but
>>> the majority of uses are homogeneous enough that we haven't had to (nor
>>> been asked to) rely on the agreement. The old XML OID (we've been using
>>> 1.2.840.10003.5.109.10) is sufficient for us - I just return the only
>>> XML we know about - ie, the record we ingested. This works reasonably
>>> well since the schema is usually either known or agreed to a priori or
>>> included in the XML anyway, in which case the returned XML is
>>> self-documenting and it's up to the requesting client what to do with
>>> it.
>>>
>>> I have no objection to implementing the convention, provided there's no
>>> implied agreement to _transform_ records into the requested schema. My
>>> inclination would be to return either the record, if we know and can
>>> provide the particular schema or to return an error if we don't (ie, it
>>> would be treated like an unsupported element set).
>>>
>>> --
>>>
>>> Archie
>>>
>>> -- Archie Warnock warnock@...
>>> -- A/WWW Enterprises www.awcubed.com
>>> -- As a matter of fact, I _do_ speak for my employer.
>>>
>>
>>
>
>
>
>
>
>
>

SV: Requesting XML records via Z39.50

2009-01-27T01:16:10Z

Hi Adam,

What OID is "the original one"? I have found these OID for XML record syntaxes in the registry:
1.2.840.10003.5.109.10 xml (no specific version)
1.2.840.10003.5.109.10.1.0 xml version 1.0
1.2.840.10003.5.109.10.1.1 xml version 1.1
1.2.840.10003.5.110 Z39.50 mime types
1.2.840.10003.5.112 xml-b XML record according to the schema or definition identified by the element set name.

Best regards
Tommy
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Adam Dickmeiss
Sendt: 26. januar 2009 21:58
Til: www-zig@...
Cc: www-zig@...
Emne: Re: Requesting XML records via Z39.50

Ray Denenberg, Library of Congress wrote:

>
> Archie, I don't want anyone to change their implementation behavior
> based on the existing or a revised agreement. So this is useful
> feedback, thanks. I would like to incorporate existing implementation
> practice into the revised procedure.
>
> I think that the 110 record syntax was first registered with the idea
> that the XML schema was known by private agreement. (Subseqently we
> registered 112 to use in the case when you want to also specify the
> schema.) It sounds like what you are doing is consisitent with what
> we had in mind. I'll write this into the revised agreement.

We're pretty much in the same wagon as Archie. AFAIK, we have never used
any other OID for XML than the original one. Most often the element set
name further specifies the requested schema. In other words, like the
(xml-b) implementor's agreement but using the original OID.

/ Adam

>
> Any other feedback on this is also welcome.
>
> --Ray
>
> ----- Original Message ----- From: "Archie Warnock" <warnock@...>
> To: "Ray Denenberg, Library of Congress" <rden@...>
> Cc: <www-zig@...>
> Sent: Monday, January 26, 2009 2:24 PM
> Subject: Re: Requesting XML records via Z39.50
>
>
>> Ray Denenberg, Library of Congress wrote:
>>> I would like to revisit the implementor agreement on "Requesting XML
>>> Records", http://www.loc.gov/z3950/agency/agree/request-xml.html,
>>> as it
>>> has been many years since it we've discussed it, and it does seem to
>>> warrant some clarification.
>>
>> And note that the link in that page
>> (http://www.loc.gov/z3950/agency/zing/srw/records.html) is no longer
>> valid.
>>
>>> Briefly, to retrieve records according to a specific XML schema using
>>> Z39.50 (if you DON'T want to use compSpec):
>>> 1. XML is specified as the record syntax, specifically 'xml-b':
>>> 1.2.840.10003.5.112.
>>> 2. The schema identifier is specified as the element set name.
>>
>> Somehow I missed the original Implementor's Agreement and Isite has been
>> happily chugging along without it. We don't use compSpec in Isite but
>> the majority of uses are homogeneous enough that we haven't had to (nor
>> been asked to) rely on the agreement. The old XML OID (we've been using
>> 1.2.840.10003.5.109.10) is sufficient for us - I just return the only
>> XML we know about - ie, the record we ingested. This works reasonably
>> well since the schema is usually either known or agreed to a priori or
>> included in the XML anyway, in which case the returned XML is
>> self-documenting and it's up to the requesting client what to do with
>> it.
>>
>> I have no objection to implementing the convention, provided there's no
>> implied agreement to _transform_ records into the requested schema. My
>> inclination would be to return either the record, if we know and can
>> provide the particular schema or to return an error if we don't (ie, it
>> would be treated like an unsupported element set).
>>
>> --
>>
>> Archie
>>
>> -- Archie Warnock warnock@...
>> -- A/WWW Enterprises www.awcubed.com
>> -- As a matter of fact, I _do_ speak for my employer.
>
>
>

Re: Requesting XML records via Z39.50

2009-01-26T12:58:05Z

Ray Denenberg, Library of Congress wrote:

Re: Requesting XML records via Z39.50

2009-01-26T12:45:49Z

Ray Denenberg, Library of Congress wrote:

> Archie, I don't want anyone to change their implementation behavior
> based on the existing or a revised agreement. So this is useful
> feedback, thanks. I would like to incorporate existing implementation
> practice into the revised procedure.
>
> I think that the 110 record syntax was first registered with the idea
> that the XML schema was known by private agreement. (Subseqently we
> registered 112 to use in the case when you want to also specify the
> schema.) It sounds like what you are doing is consisitent with what we
> had in mind. I'll write this into the revised agreement.
>
> Any other feedback on this is also welcome.

Well, it's more a matter of being ready for any requests that come in.
It's not exactly at the top of my development priority list, but it's
something that Isite ought to handle in accord with the agreement.

--

Archie

-- Archie Warnock warnock@...
-- A/WWW Enterprises www.awcubed.com
-- As a matter of fact, I _do_ speak for my employer.

Re: Requesting XML records via Z39.50

2009-01-26T12:05:35Z

Archie, I don't want anyone to change their implementation behavior based on
the existing or a revised agreement. So this is useful feedback, thanks.
I would like to incorporate existing implementation practice into the
revised procedure.

I think that the 110 record syntax was first registered with the idea that
the XML schema was known by private agreement. (Subseqently we registered
112 to use in the case when you want to also specify the schema.) It sounds
like what you are doing is consisitent with what we had in mind. I'll write
this into the revised agreement.

Any other feedback on this is also welcome.

--Ray

----- Original Message -----
From: "Archie Warnock" <warnock@...>
To: "Ray Denenberg, Library of Congress" <rden@...>
Cc: <www-zig@...>
Sent: Monday, January 26, 2009 2:24 PM
Subject: Re: Requesting XML records via Z39.50

> Ray Denenberg, Library of Congress wrote:
>> I would like to revisit the implementor agreement on "Requesting XML
>> Records", http://www.loc.gov/z3950/agency/agree/request-xml.html, as it
>> has been many years since it we've discussed it, and it does seem to
>> warrant some clarification.
>
> And note that the link in that page
> (http://www.loc.gov/z3950/agency/zing/srw/records.html) is no longer
> valid.
>
>> Briefly, to retrieve records according to a specific XML schema using
>> Z39.50 (if you DON'T want to use compSpec):
>> 1. XML is specified as the record syntax, specifically 'xml-b':
>> 1.2.840.10003.5.112.
>> 2. The schema identifier is specified as the element set name.
>
> Somehow I missed the original Implementor's Agreement and Isite has been
> happily chugging along without it. We don't use compSpec in Isite but
> the majority of uses are homogeneous enough that we haven't had to (nor
> been asked to) rely on the agreement. The old XML OID (we've been using
> 1.2.840.10003.5.109.10) is sufficient for us - I just return the only
> XML we know about - ie, the record we ingested. This works reasonably
> well since the schema is usually either known or agreed to a priori or
> included in the XML anyway, in which case the returned XML is
> self-documenting and it's up to the requesting client what to do with it.
>
> I have no objection to implementing the convention, provided there's no
> implied agreement to _transform_ records into the requested schema. My
> inclination would be to return either the record, if we know and can
> provide the particular schema or to return an error if we don't (ie, it
> would be treated like an unsupported element set).
>
> --
>
> Archie
>
> -- Archie Warnock warnock@...
> -- A/WWW Enterprises www.awcubed.com
> -- As a matter of fact, I _do_ speak for my employer.

Re: Requesting XML records via Z39.50

2009-01-26T11:24:24Z

Ray Denenberg, Library of Congress wrote:
> I would like to revisit the implementor agreement on "Requesting XML
> Records", http://www.loc.gov/z3950/agency/agree/request-xml.html, as it
> has been many years since it we've discussed it, and it does seem to
> warrant some clarification.

And note that the link in that page
(http://www.loc.gov/z3950/agency/zing/srw/records.html) is no longer valid.

> Briefly, to retrieve records according to a specific XML schema using
> Z39.50 (if you DON'T want to use compSpec):
> 1. XML is specified as the record syntax, specifically 'xml-b':
> 1.2.840.10003.5.112.
> 2. The schema identifier is specified as the element set name.

Somehow I missed the original Implementor's Agreement and Isite has been
happily chugging along without it. We don't use compSpec in Isite but
the majority of uses are homogeneous enough that we haven't had to (nor
been asked to) rely on the agreement. The old XML OID (we've been using
1.2.840.10003.5.109.10) is sufficient for us - I just return the only
XML we know about - ie, the record we ingested. This works reasonably
well since the schema is usually either known or agreed to a priori or
included in the XML anyway, in which case the returned XML is
self-documenting and it's up to the requesting client what to do with it.

I have no objection to implementing the convention, provided there's no
implied agreement to _transform_ records into the requested schema. My
inclination would be to return either the record, if we know and can
provide the particular schema or to return an error if we don't (ie, it
would be treated like an unsupported element set).

--

Archie

-- Archie Warnock warnock@...
-- A/WWW Enterprises www.awcubed.com
-- As a matter of fact, I _do_ speak for my employer.

Requesting XML records via Z39.50

2009-01-26T07:55:04Z

I would like to revisit the implementor agreement on "Requesting XML
Records", http://www.loc.gov/z3950/agency/agree/request-xml.html, as it has
been many years since it we've discussed it, and it does seem to warrant
some clarification.

Briefly, to retrieve records according to a specific XML schema using
Z39.50 (if you DON'T want to use compSpec):
1. XML is specified as the record syntax, specifically 'xml-b':
1.2.840.10003.5.112.
2. The schema identifier is specified as the element set name.

This has come up in discussion with a few implementers, some who want to
retrieve holdings records (ISO 20775), others marcXchange records (ISO
25577), as well as subschemas of these two schemas.

As a result of that discussion I have registered the following:

1.2.840.10003.13.11 ISO 20775 Schema for holdings
http://www.loc.gov/standards/iso20775/

1.2.840.10003.13.11.1 the holdingsHistory subschema (element set) of ISO
20775 Holdings Schema

1.2.840.10003.13.12 'MarcXchange' ISO 25577 XML schema for MARC formatted
records
http://www.loc.gov/standards/iso25577/

1.2.840.10003.13.12.1 danMARC2 subschema of MarcXchange

1.2.840.10003.13.12.2 MarcXML subschema of MarcXchange
http://www.loc.gov/standards/marcxml/

Please comment, particularly implementors who retrieve XML records but don't
do it this way.

If there is no discsussion on this (say, by February 9), I will re-write
the implementor agreement with appropriate clarification.

--Ray

OASIS Search Web Services TC Releases Committee Drafts

2008-07-28T08:50:05Z

The OASIS Search Web Services Technical Committee, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=search-ws, is pleased to announce the release of five Committee Drafts.

(1) Search Web Services - searchRetrieve Operation: Abstract Protocol Definition Version 1.0 - Committee Draft 01 30 June 2008

(2) Search Web Services - searchRetrieve Operation: Binding for SRU 1.2 Version 1.0 - Committee Draft 01 30 June 2008

(3) Search Web Services - searchRetrieve Operation - Binding for SRU 1.2: Auxiliary Binding for HTTP GET- Version 1.0 - Committee Draft 01 30 June 2008

(4) Search Web Services - CQL 1.2: The Contextual Query Language Version 1.0 - Committee Draft 01 30 June 2008

(5) Search Web Services - searchRetrieve Operation: Binding for OpenSearch Version 1.0 - Committee Draft 01 30 June 2008

Links to these documents are at the bottom of this message.

Informally (and more succinctly), the five documents are:

(1) Abstract Protocol Definition (APD)
(2) Binding for SRU 1.2
(3) Auxiliary Binding for HTTP GET
(4) CQL 1.2
(5) Binding for OpenSearch

The Abstract Protocol Definition (1) provides the framework for the definition of "Application Protocol Bindings", including SRU 1.2 (2) , SRU 2.0 (see Annex A of SRU 1.2 Binding), and openSearch (5).

A binding may be "static" or "dynamic". A static binding is a human-readable document, essentially a profile. A dynamic binding is a machine-readable description of a server, written in a description language that the Committee is also developing (see Annex B of APD).

The premise behind dynamic bindings is that any search engine, even one that existed prior to development of the standard, need only to provide a dynamic binding - a self-description. It need make no other changes in order to be accessible. A client will be able to access any search engine that provides a description, if only it implements the capability to read and interpret the description and use it to formulate a request (including a query) and interpret the response.

SRU (1.2 and 2.0) are static bindings. openSearch is a dynamic binding.

notes:
- The SRU 1.2 binding, together with the Auxiliary Binding for HTTP GET, is intended to be fully compatible with the current SRU 1.2 specification at http://www.loc.gov/sru/.
- The CQL 1.2 Spec is intended to be fully compatible with the current CQL 1.2 specification at http://www.loc.gov/standards/sru/specs/cql.html.
- The openSearch binding is intended to be fully compatible with http://www.opensearch.org/Specifications/OpenSearch/1.1/Draft_3.

CALL FOR PARTICIPATION

The next phase of work for the TC will be the development of SRU/CQL 2.0 (as mentioned in Annex A of the SRU 1.2 Binding), and the Description Language (as mentioned in Annex B of the Abstract Protocol Definition).

The Committee hopes to involve the SRU Implementors Group in this next phase of work to develop SRU/CQL 2.0 and the Description Language. You can participate either by joining the committee, or if you are unable to join, via discussion over this list. Please contact me directly (rden@...) to discuss how to join the committee.

The lead committee member for SRU/CQL 2.0 will be Rob Sanderson (azaroth@...). The lead committee members for the description language will be Ashley Sanders (a.sanders@...) and Ralph LeVan (levan@...).

Links.
(1) Search Web Services - searchRetrieve Operation: Abstract Protocol Definition Version 1.0 - Committee Draft 01 30 June 2008
http://docs.oasis-open.org/search-ws/v1.0/apd-V1.0.doc
http://docs.oasis-open.org/search-ws/v1.0/apd-V1.0.pdf
http://docs.oasis-open.org/search-ws/v1.0/apd-V1.0.html

(2) Search Web Services - searchRetrieve Operation: Binding for SRU 1.2 Version 1.0 - Committee Draft 01 30 June 2008
http://docs.oasis-open.org/search-ws/v1.0/sru-1-2-V1.0.doc
http://docs.oasis-open.org/search-ws/v1.0/sru-1-2-V1.0.pdf
http://docs.oasis-open.org/search-ws/v1.0/sru-1-2-V1.0.html

(3) Search Web Services - searchRetrieve Operation - Binding for SRU 1.2: Auxiliary Binding for HTTP GET- Version 1.0 - Committee Draft 01 30 June 2008
http://docs.oasis-open.org/search-ws/v1.0/binding-for-get-V1.0.doc
http://docs.oasis-open.org/search-ws/v1.0/binding-for-get-V1.0.pdf
http://docs.oasis-open.org/search-ws/v1.0/binding-for-get-V1.0.html

(4) Search Web Services - CQL 1.2: The Contextual Query Language Version 1.0 - Committee Draft 01 30 June 2008
http://docs.oasis-open.org/search-ws/v1.0/cql-1-2-V1.0.doc
http://docs.oasis-open.org/search-ws/v1.0/cql-1-2-V1.0.pdf
http://docs.oasis-open.org/search-ws/v1.0/cql-1-2-v1.0.html

(5) Search Web Services - searchRetrieve Operation: Binding for OpenSearch Version 1.0 - Committee Draft 01 30 June 2008
http://docs.oasis-open.org/search-ws/v1.0/opensearch-V1.0.doc
http://docs.oasis-open.org/search-ws/v1.0/opensearch-V1.0.pdf
http://docs.oasis-open.org/search-ws/v1.0/opensearch-v1.0.html

CQL searching for IP ranges

2008-07-14T08:17:54Z

We have a CQL application that needs to search records by IP range:
for example, if we have a record with an ip-ranges field:
213.150.43.10-213.150.43.20
then we need to be able to search for:
net.ipRanges encloses/net.ipAddress 213.150.43.11
and have the server understand from that query that we're looking for
the term to be interpreted as a dotted address, with ordering defined
appropriately.

We therefore ask for the following elements to be added to the Network
Context Set as defined at:
http://srw.cheshire3.org/contextSets/net/

index: ipRanges
relation modifier: ipAddress

(We can't just use the existing net.host index, since this querty
explicitly needs an IP address, with its ordering rules, rather than a
symbolic name.)

_/|_ ___________________________________________________________________
/o ) \/ Mike Taylor <mike@...> http://www.miketaylor.org.uk
)_v__/\ "I was being tongue-in-cheek, but did feel your little mock
assault was a tad opportunistic, in a cuddly sort of way" --
Sebastian Hammer.

CSTST 2008 : Submission deadline on June 15th 2008

2008-06-02T07:02:15Z

****************************************************************************************************************

The Fifth International Conference on Soft Computing as Transdisciplinary
Science and Technology (CSTST'08)
October 27-31, 2008
Cergy-Pontoise/Paris, FRANCE
Hosted by the "University of Cergy Pontoise"
http://sigappfr.acm.org/cstst08/

****************************************************************************************************************

Sponsorships:
IEEE Systems, Man, and Cybernetics Society (Technically Co-sponsored)
IEEE France (Technically Co-sponsored)
ACM SIGAPP.fr (In Cooperation with)
European Neural Network Society (ENNS)
European Society for Fuzzy Logic and Technology (EUSFLAT)

Description
**********************

The International Conference on Soft Computing as Transdisciplinary Science and
Technology (CSTST'08) brings together international soft computational
intelligence researchers, developers, practitioners, and users.
The aim of CSTST (previously called WSTST) is to serve as a forum to present
current and future work as well as to exchange research ideas in this field.
CSTST'08 invites authors to submit their original and unpublished work that
demonstrates current research in all areas of soft computing, as well as
proposals
for workshops, industrial presentations, demonstrations, and tutorials.

This edition is dedicated to commemorate the memory of Prof. Yasuhiko Dote,
Founding Chair of WSTST series of meetings.

Topics
**********************
We solicit original research and technical papers not published elsewhere.
The papers can be theoretical, practical and application oriented on the
following themes (but not limited to):

* Information and Data Management
* Intelligent Hybrid Systems
* Fusion of Soft and Hard Computing
* Data and Web Mining
* Decision Support Systems
* Natural Language Processing
* Intelligent Agent-based Systems, Cognitive and Reactive Distributed AI Systems
* Internet Modeling
* Multimedia Information Systems
* Information Retrieval
* Human-Computer Interface
* XML-based Languages
* Security and Access Control
* Information Content Security
* Mobile, Ad Hoc and Sensor Network Management
* Applications
o E-Learning, eCommerce, eBusiness and eGovernment
o Image and speech signal processing, prediction, and control
o Robotics
o Biology and medicine
o Business and management
o Artificial societies
o Chemicals, pharmaceuticals and materials
o Environment engineering

Paper submission
*******************

Submissions must be in an electronic form as PDF files and should be uploaded
using the conference website (http://sigappfr.acm.org/cstst08/).
Full paper submissions should be in ACM format with a limit of 6 pages.
Papers that fail to comply with length limit will be rejected.
Submissions will be peer-reviewed by at least 2 independent reviewers of the PC.

Selection criteria will include: relevance, significance, impact, originality,
technical soundness, and quality of presentation.
Preference will be given to submissions that take strong or challenging
positions on important emergent topics.
At least one author should attend the conference to present the paper.

The conference Proceedings will be indexed by ACM Digital Libraries and
published with an ISBN.

Awards
*******

- To commemorate the memory of Prof. Yasuhiko Dote, the Founder and General
Chair of the WSTST series of meetings, the Board Chairs of CSTST 2008 are
honoured to establish the Professor Yasuhiko Dote Award for the distinguished
best paper.

Information about the winner will be posted on the conference web site. This
Award will include a commemorative plate and a waiver of the registration fees
for the following CSTST edition.

- "Best student paper" will be awarded of 400 euros.

Important Dates
**********************

Full Paper Submissions: June 15, 2008
Notification of Paper Acceptance: August 15, 2008
Camera Ready Papers Due: September 17, 2008
Author Registration: September 17, 2008
Conference Dates: October 27-31, 2008

Journal Publication
**********************

Extended versions of the selected papers will be published in one of the
following reviewed journals (to be completed).

1. Journal of Information Assurance and Security (JIAS) (ISSN 1554-1010)
2. International Journal of Computational Intelligence Research (ISSN 0973-1873)

Committees
**********************
**********************

Honorary Chair
**********************

Lotfi A. Zadeh, University of California, U.S.A

General Co-Chairs
**********************

Youakim Badr, INSA-Lyon, France
Ajith Abraham, Norwegian University of Science and Technology, Norway
Yukio Ohsawa, Tokyo Institute of Technology, Japan

Program Co-Chairs
**********************

Richard Chbeir, University of Bourgogne, France
Fernando Ferri, IRPPS-CNR, Italy
Mario Koeppen, Kyushu Institute of Technology, Japan
Dominique Laurent, University of Cergy-Pontoise, France

International Co-Chairs
**********************

Sepo Ovaska, Helsinki University of Technology, Finland
Yukinori Suzuki, Muroran Institute of Technology, Japan
Frederic Andres, National Institute of Informatics, Japan
Charles A. Shoniregun, University of East London, UK

Workshops Co-Chairs
**********************

Hiroshi Ishikawa, Shizuoka University, Japan
Yinghua Ma, Shanghai JiaoTong University, China

International Advisory Board
*****************************

James Keller, University of Missouri-Columbia, USA
Cihan H. Dagli, University of Missouri-Rolla, USA
Hidenori Kimura, University of Tokyo, Japan
Fumio Harashima, Tokyo Denki University, Japan
Lakhmi Jain, University of South Australia, Australia
Janusz Kacprzyk, Polish Academy of Science, Poland
Takeshi Furuhashi, Nagoya University, Japan
Azuma Ohuchi, Hokkaido University, Japan
Hideyuki Takagi, Kyushu University, Japan
Toru Yamaguchi, Tokyo Metropolitan Institute of Technology, Japan
Kensuke Kawai, Toshiba Co., Japan

Local Arrangement Co-Chairs
**********************

Jean Luc Bourdon, University of Cergy-Pontoise, France
Virginie Sans, University of Cergy-Pontoise, France

Local Arrangement Committee
***************************

Sonia Katchadourian, University of Cergy-Pontoise, France
Clémence Driol, University of Cergy-Pontoise, France

International Programme Committee
************************************

(Full list is provided on the conference web site)

####################################################
# Richard CHBEIR, Ph.D. in Computer Science #
# Associate Professor #
# Laboratoire LE2I (UMR - CNRS) #
# Bourgogne University #
# Aile de l'Ingénieur #
# Office GS 16 #
# BP 47870 #
# 21078 Dijon CEDEX France #
# Tel.: +333 80 39 36 55 #
# Fax: +333 80 39 68 69 #
# Email: richard.chbeir@... #
# Web: http://www.le2I.com #
####################################################

Computational Social Networks Workshop - WI 2008 - Sydney, Australia

2008-05-19T13:30:29Z

-- Call for Papers --

International Workshop on Computational Social Networks (IWCSN 2008)

http://www.softcomputing.net/~csn/

December 9, 2008, Sydney, Australia

This workshop is organized in conjunction with the
2008 IEEE/WIC/ACM International Conference on Web Intelligence (WI-08)
http://datamining.it.uts.edu.au/wi08/html/wi/

Honorary Chair

Miroslav Fiedler
Institute of Computer Science
Academy of Sciences of the Czech Republic
Pod vodarenskou vezi 2
182 07 Prague 8,Czech Republic
e-mail: fiedler@...

Workshop Co-Chairs (Organizers)

Vaclav Snasel
Department of Computer Science,
VSB-Technical University of Ostrava,
Czech Republic
http://www.cs.vsb.cz/snasel
Email: vaclav.snasel@...

Ajith Abraham
Norwegian Center of Excellence
Center of Excellence for Quantifiable Quality of Service
Norwegian University of Science and Technology,
O.S. Bragstads plass 2E,
N-7491 Trondheim, Norway
email: ajith.abraham@...

Aboul Ella Hassanien
Faculty of Computer and Information,
Information Technology Department,
Cairo University,
5 Ahmed Zewal St., Orman, Giza, Egypt
http://www.cba.edu.kw/abo/
E-mail: aboitcaio@...

James Peters
Department of Electrical and Computer Engineering
University of Manitoba
75A Chancellor's Circle
Winnipeg, MB R3T 5V6 Canada
E-mail: jfpeters@...

Gerald Schaefer
Schoool of Engineering and Applied Science,
Aston University
Birmingham, United Kingdom
Email: g.schaefer@...

Workshop Objective

Social networks provide a powerful abstraction of the structure and
dynamics of diverse kinds of people or people-to-technology
interaction. Web 2.0 has enabled a new generation of Web-based
communities, social networks, and folksonomies to facilitate
collaboration among different communities. Social network analysis is
a rapidly growing field within the Web intelligence domain. The recent
developments in Web 2.0 have provided more opportunities to
investigate the dynamics and structure of Web-based social networks.
Recent trends also indicate the usage of social networks as a key
feature for next generation usage and exploitation of the Web. This
international workshop on "Computational Social Networks' is focused
on the foundations of social networks as well as case studies,
empirical, and other methodological works related to the computational
tools for the automatic discovery of Web-based social networks. This
workshop provides an opportunity to compare and contrast the
ethological approach to social behavior in animals (including the
study of animal tracks and learning by members of the same species)
with web-based evidence of social interaction, perceptual learning,
information granulation, the behavior of humans and affinities between
web-based social networks. The main topics cover the design and use
of various computational intelligence tools and software, simulations
of social networks, representation and analysis of social networks,
use of semantic networks in the design and community-based research
issues such as knowledge discovery, privacy and protection, and
visualization.

Recommended topics include but are not limited to the following:

o Automatic discovery and analysis of Web based social networks.
o Intelligent Visualization of Social Network Analysis
o Intelligent social network
o Social Network Mining
o Social Networks and Social Intelligence
o Web Site Clustering
o Link Topology and Site Hierarchy
o Theories of Small-World Web
o Virtual and Web Communities
o Security, privacy and trust
o Computational Analysis of Social and Organizational Systems
o Web-Based Cooperative Work
o Knowledge Community Formation and Support
o Ubiquitous Computing
o Intelligent Wireless Web
o Ubiquitous Learning Systems
o Social network analysis of communities of practice
o Network evolution and growth mechanisms
o Information diffusion in social networks
o Affiliation networks
o Epidemics and rumors in networks
o Geographical clusters, networks, and innovation
o Effects of network structure and dynamics on knowledge transfer
and sharing
o Intra- and inter-organizational networks
o Social capital, structural holes and Simmelian ties
o Online communities and computer networks
o Computational models and agent-based simulations of networks
o Infrastructure and Tools for e-Social network
o Interdisciplinary Research and e-Social network
o International Collaborations in e-Social network

Note that IWCSN 2008 will accept ONLY on-line submissions, containing
PDF versions. Please use the Submission Form on the WI'08 website to
submit your paper.
http://datamining.it.uts.edu.au/wi08/html/wi/?index=submission

Accepted papers will be published in the conference proceedings by the
IEEE Computer Society Press that are indexed by EI. Final camera
ready papers will be allocated only 4 pages (one extra page allowed)
in the proceedings.

Important Dates

Workshop paper submission: July 30, 2008
Notification of paper acceptance: September 3, 2008
Camera-ready of accepted papers: September 30, 2008
Workshop: December 9, 2008

About WI-08

The 2008 IEEE/WIC/ACM International Conference on Web Intelligence
(WI-08) will be jointly held with the 2008 IEEE/WIC/ACM International
Conference on Intelligent Agent Technology (IAT-08). The IEEE/WIC/ACM
2008 joint conferences are organized by University of Technology,
Sydney, Australia, and sponsored by IEEE Computer Society Technical
Committee on Intelligent Informatics (TCII), Web Intelligence
Consortium (WIC), and ACM-SIGART. Following the great successes of
WI'01 held in Maebashi City, Japan , WI'03 held in Halifax, Canada,
WI'04 held in Beijing, China, WI-05 in Compiegne University of
Technology, France, WI-06 held in Hong Kong Convention and Exhibition
Centre, China, WI-07 held in Silicon Valley, California, USA. WI 2008
provides a leading international forum for researchers and
practitioners (1) to present the state-of-the-art of WI technologies;
(2) to examine performance characteristics of various approaches in
Web-based intelligent information technology; and (3) to
cross-fertilize ideas on the development of Web-based intelligent
information systems among different domains. By idea-sharing and
discussions on the underlying foundations and the enabling
technologies of Web intelligence, WI 2008 will capture current
important developments of new models, new methodologies and new tools
for building a variety of embodiments of Web-based intelligent
information systems.

International Program Committee

TBA

For further information:

Please email: ajith.abraham@...

Springer Book on Emergent Web Intelligence: Extended Submission Deadline ...

2008-04-24T00:33:50Z

(Submission Deadline has been Extended till: May 15, 2008)

########################### Call for Book Chapters ###########################

Book Title: Emergent Web Intelligence

To be published by Springer Verlag

in the series "Studies in Computational Intelligence"
http://www.u-bourgogne.fr/DBconf/Springer/
###############################################################################

Description
------------

The current Internet changes our daily life by redefining the
meanings and processes of business, commerce, marketing, finance,
publishing, education, research, etc. and by revolutionizing the way we
produce, store, process, retrieve and use information. Although
individual Web-based information systems are regularly being deployed,
new efficient techniques and approaches for developing and for
benefiting from collective Web intelligence are required more than ever
to help users avoid irrelevant web search results (pages, links, etc.),
fraud e-business transactions, non-personalized web information, even
wrong web decisions, etc.

The novel intelligent web theory exploits advanced information
technology and IA to explore the next generation of web-empowered
systems, services, and environments, and to design and provide hybrid
web systems that serve wired and wireless users more efficiently.

In this book, we aim at gathering the latest advances of various
topics in web intelligence and reporting how organizations can gain
competitive advantages by applying the different emergent techniques in
the real-world scenarios. Papers and studies which couple the
intelligence techniques and theories with specific web technology
problems are cordially invited. Survey articles that emphasize the
research and application of web intelligence in a particular domain are
greatly welcome.

Volumes & Topics
-----------------

This book will include several volumes related to the following topics (but are
not limited to):

* Web Information Retrieval
* Information Management and Data Representation
* Web Mining
* Web Farming
* Web Security
* Information Filtering and Access Control Models
* Semantics and Ontologies
* Web services and Semantic Web
* Social Networks and Intelligence Design
* Web-based Support Systems
* Human-Web Interaction
* E-Applications and Systems
* Web Technologies and Protocols

* Wisdom Web

* Web Agents and Agent-based Systems
* Agent self-organization, learning, and adaptation

* Agent-based knowledge discovery

* Agent-mediated markets

* Knowledge Grid and Grid intelligence

* Knowledge management, networks, and communities
* Web 3.0

Submission Guidelines
----------------------

Authors are kindly invited to upload their submissions at:
http://www.u-bourgogne.fr/DBconf/Springer/Submission/

All submitted chapters will be reviewed by at least three reviewers.

Careful preparation of the manuscripts will help keep production time
short and ensure satisfactory appearance of the finished book. Please
prepare the manuscript as follows:

* Please centralize all tables and figures with appropriate legends.

* Please carefully check for typos inside the figures/legends etc.

* All equations must be numbered and please try to use standard fonts.

* Produce a LaTeX version of your chapter using the template provided
(see Author Guidelines at
http://www.softcomputing.net/cec06/author-kit.zip)

Original artwork and a signed copyright release forms will be required
for all accepted chapters.

Important Dates
----------------

Deadline for full chapters (Extended): May 15, 2008
Notification of acceptance/rejection of chapters: June 30, 2008
Deadline for submission of final chapters: July 15, 2008
Publication of book "Emergent Web Intelligence": Second half of 2008

Volume Editors
--------------

- Richard CHBEIR (Main Contact)
Laboratoire LE2I (UMR - CNRS)
Bourgogne University, Aile de l'Ingénieur
21078 Dijon CEDEX France
Tel.: +333 80 39 36 55
Email: richard.chbeir@...
URL: http://www.le2I.com

- Aboul-Ella Hassanien
Kuwait University
College of Business Administration, Quantitative Methods and IS Department
P.O. Box 5486 Safat, 13055 Kuwait
Tel: +965-4839364
Email: Abo@...
URL: http://www.cba.edu.kw/abo

- Ajith Abraham
Center for Quantifiable Quality of Service in Communication Systems
Norwegian University of Science & Technology,
Trondheim, Norway
Email: ajith.abraham@...
URL: http://www.softcomputing.net

- Youakim Badr
INSA de Lyon, Batiment Blaise Pascal
7 Avenue Jean Capelle
69621 Villeurbanne Cedex, France
Tel: +334 72 43 62 73
Email: youakim.badr@...
URL: http://www.insa-lyon.fr/liesp

About the series "Studies in Computational Intelligence"
---------------------------------------------------------

The series "Studies in Computational Intelligence" (SCI) publishes new
developments and advances in the various areas of computational
intelligence. The intent is to cover the theory, applications, and design
methods of computational intelligence, as embedded in the fields of engineering,
computer science, physics and life science, as well as the methodologies behind
them. The series contains monographs, lecture notes and edited volumes
in computational intelligence spanning the areas of neural networks,
connectionist systems, genetic algorithms, evolutionary computation,
artificial intelligence, cellular automata, self-organizing systems,
soft computing, fuzzy systems, and hybrid intelligent systems. Critical
to both contributors and readers are the short publication time and
world-wide distribution - this permits a rapid and broad dissemination
of research results. For more details, go through
http://www.springer.com/series/7092.

The Third CSTST'08 CALL FOR WORKSHOP PROPOSALS

2008-04-14T03:05:45Z

We apologies if you received this message twice.

=====================================================

IEEE/ACM CSTST'08 CALL FOR WORKSHOP PROPOSALS

The CSTST 2008 (The International Conference on Soft Computing as
Transdisciplinary Science and Technology) will be held in Paris
(Cergy Pontoise), France from Sunday 26th Octobor to Thursday 30th
Octobor, 2008. CSTST'08 brings together international soft
computational intelligence researchers, developers, practitioners,
and users. The aim of CSTST (previously called WSTST) is to serve
as a forum to present current and future work as well as to exchange
research ideas in this field.

Proposals for workshops are invited for consideration in CSTST 2008.
The purpose of these workshops is to provide a platform for presenting
novel ideas in a less formal and possibly more focused way than the
conferences themselves. As such, they also offer a good opportunity
for young researchers to present their work and to obtain feedback
from an interested community. The format of each workshop is to be
determined by the organizers, but it is expected that they contain
ample time for general discussion. The preference is for one-day
workshops, but other schedules will also be considered.

Researchers and practitioners are invited to submit workshop proposals
to the CSTST 2008 Workshop co-chair, Yinghua Ma (ma-yinghua@...),
NO LATER THAN April 15, 2008. Submission can be made in
Postscript, PDF, or ASCII with "CSTST08 Workshop Submission"
in the subject header. Proposals must be about 2--5 pages long and include:
* Name of workshop;
* Summary;
* Topics;
* Organizers (attach short CVs, limit of 2 pages each);
* The expected number of attendees and the planned length of the workshop.
* The names of potential participants, such as program committee members.
* Expected submission and acceptance rate (workshops only);
* Type (academic and/or industrial) and number of expected participants;
* Significance in relation to topics of the main conference and details
    of previous workshops.
* The URL of the workshop web site.

Workshop proposals are reviewed based on the quality of the
proposal, its relation to the main conference topics, and the likelihood
to attract enough participants. Notification of acceptance will be made
by April 30, 2008.

Topics of CSTST 2008(not limited to):
* Information and Data Management
* Intelligent Hybrid Systems
* Fusion of Soft and Hard Computing
* Data and Web Mining
* Decision Support Systems
* Natural Language Processing
* Intelligent Agent-based Systems, Cognitive and Reactive Distributed AI Systems
* Internet Modeling
* Multimedia Information Systems
* Information Retrieval
* Human-Computer Interface
* XML-based Languages
* Security and Access Control
* Information Content Security
* Mobile, Ad Hoc and Sensor Network Management
* Applications
    o E-Learning, eCommerce, eBusiness and eGovernment
    o Image and speech signal processing, prediction, and control
    o Robotics
    o Biology and medicine
    o Business and management
    o Artificial societies
    o Chemicals, pharmaceuticals and materials
    o Environment engineering

Proceedings of all CSTST'08 workshops are to be published as a single
volume to be distributed at the conference. All the workshop papers
should be limited to 6 pages in ACM format. Extended versions of the
selected papers will be published in one of the following reviewed
journals(Journal of Information Assurance and Security (JIAS) or
International Journal of Computational Intelligence Research).

Any further information needed for preparing a workshop proposal can
be obtained by sending email to one of the workshops co-chairs:
Yinghua MA (ma-yinghua@...) and/or Hiroshi Ishikawa
(ishikawa@...).

Important Dates
---------------
Proposals for Workshops: April 15, 2008
Notification of Workshop Acceptance: April 30, 2008
Full Paper Submissions: June 15, 2008
Notification of Paper Acceptance: August 15, 2008
Camera Ready Papers Due: September 17, 2008
Author Registration: September 17, 2008
Conference & Workshop Dates: October 26-30, 2008

Committees
-----------

Honorary Chair
--------------
Lotfi A. Zadeh, University of California, U.S.A

General Co-Chairs
-----------------
Youakim Badr, INSA-Lyon, France
Ajith Abraham, Norwegian University of Science and Technology, Norway
Yukio Ohsawa, Tokyo Institute of Technology, Japan

Program Co-Chairs
-----------------
Richard Chbeir, University of Bourgogne, France
Fernando Ferri, IRPPS-CNR, Italy
Mario Koeppen, Kyushu Institute of Technology, Japan

International Co-Chairs
-----------------------
Sepo Ovaska, Helsinki University of Technology, Finland
Yukinori Suzuki, Muroran Institute of Technology, Japan
Frederic Andres, National Institute of Informatics, Japan
Charles A. Shoniregun, University of East London, UK

Workshops Co-chairs
----------------------
Hiroshi Ishikawa, Shizuoka University, Japan
Yinghua Ma, Shanghai JiaoTong University, China

International Advisory Board
----------------------------
James Keller, University of Missouri-Columbia, USA
Cihan H. Dagli, University of Missouri-Rolla, USA
Hidenori Kimura, University of Tokyo, Japan
Fumio Harashima, Tokyo Denki University, Japan
Lakhmi Jain, University of South Australia, Australia
Janusz Kacprzyk, Polish Academy of Science, Poland
Takeshi Furuhashi, Nagoya University, Japan
Azuma Ohuchi, Hokkaido University, Japan
Hideyuki Takagi, Kyushu University, Japan
Toru Yamaguchi, Tokyo Metropolitan Institute of Technology, Japan
Kensuke Kawai, Toshiba Co., Japan

Local Arrangement Co-Chairs
----------------------------
Dominique Laurent, University of Cergy-Pontoise, France
Jean Luc Bourdon, University of Cergy-Pontoise, France

Local Arrangement Secretary
----------------------------
Virginie Sans, University of Cergy-Pontoise, France

Local Arrangement committee
----------------------------
Sonia Katchadourian, University of Cergy-Pontoise, France
Climence Driol, University of Cergy-Pontoise, France

Last Call for Springer Book Chapter Proposals on Emergent Web Intelligence

2008-04-11T09:00:24Z

---------------------------------------
Submission deadline: 28 April 2008
---------------------------------------

############################## Call for Book Chapters
##############################

Book Title: Emergent Web Intelligence

To be published by Springer Verlag

in the series "Studies in Computational Intelligence"
http://www.u-bourgogne.fr/DBconf/Springer/
####################################################################################

Description
------------

The current Internet changes our daily life by redefining the
meanings and processes of business, commerce, marketing, finance,
publishing, education, research, etc. and by revolutionizing the way we
produce, store, process, retrieve and use information. Although
individual Web-based information systems are regularly being deployed,
new efficient techniques and approaches for developing and for
benefiting from collective Web intelligence are required more than ever
to help users avoid irrelevant web search results (pages, links, etc.),
fraud e-business transactions, non-personalized web information, even
wrong web decisions, etc.

The novel intelligent web theory exploits advanced information
technology and IA to explore the next generation of web-empowered
systems, services, and environments, and to design and provide hybrid
web systems that serve wired and wireless users more efficiently.

In this book, we aim at gathering the latest advances of various
topics in web intelligence and reporting how organizations can gain
competitive advantages by applying the different emergent techniques in
the real-world scenarios. Papers and studies which couple the
intelligence techniques and theories with specific web technology
problems are cordially invited. Survey articles that emphasize the
research and application of web intelligence in a particular domain are
greatly welcome.

Volumes & Topics
-----------------

This book will include several volumes related to the following topics (but are
not limited to):

* Web Information Retrieval
* Information Management and Data Representation
* Web Mining
* Web Farming
* Web Security
* Information Filtering and Access Control Models
* Semantics and Ontologies
* Web services and Semantic Web
* Social Networks and Intelligence Design
* Web-based Support Systems
* Human-Web Interaction
* E-Applications and Systems
* Web Technologies and Protocols

* Wisdom Web

* Web Agents and Agent-based Systems
* Agent self-organization, learning, and adaptation

* Agent-based knowledge discovery

* Agent-mediated markets

* Knowledge Grid and Grid intelligence

* Knowledge management, networks, and communities
* Web 3.0

Submission Guidelines
----------------------

Authors are kindly invited to upload their submissions at:
http://www.u-bourgogne.fr/DBconf/Springer/Submission/

Chapter proposals (title and abstract) are to be uploaded before March 25th
2008.
This will facilitate the planning of the review process.
All chapter proposals will be peer reviewed.
Full chapters will be expected by April 28th 2008.
All submitted chapters will be reviewed by at least three reviewers.

Careful preparation of the manuscripts will help keep production time
short and ensure satisfactory appearance of the finished book. Please
prepare the manuscript as follows:

* Please centralize all tables and figures with appropriate legends.

* Please carefully check for typos inside the figures/legends etc.

* All equations must be numbered and please try to use standard fonts.

* Produce a LaTeX version of your chapter using the template provided
(see Author Guidelines at
http://www.softcomputing.net/cec06/author-kit.zip)

Original artwork and a signed copyright release forms will be required
for all accepted chapters.

Important Dates
----------------

Deadline for full chapters: April 28, 2008
Notification of acceptance/rejection of chapters: June 30, 2008
Deadline for submission of final chapters: July 15, 2008
Publication of book "Emergent Web Intelligence": Second half of 2008

Volume Editors
--------------

- Richard CHBEIR (Main Contact)
Laboratoire LE2I (UMR - CNRS)
Bourgogne University, Aile de l'Ingénieur
21078 Dijon CEDEX France
Tel.: +333 80 39 36 55
Email: richard.chbeir@...
URL: http://www.le2I.com

- Aboul-Ella Hassanien
Kuwait University
College of Business Administration, Quantitative Methods and IS Department
P.O. Box 5486 Safat, 13055 Kuwait
Tel: +965-4839364
Email: Abo@...
URL: http://www.cba.edu.kw/abo

- Ajith Abraham
Center for Quantifiable Quality of Service in Communication Systems
Norwegian University of Science & Technology,
Trondheim, Norway
Email: ajith.abraham@...
URL: http://www.softcomputing.net

- Youakim Badr
INSA de Lyon, Batiment Blaise Pascal
7 Avenue Jean Capelle
69621 Villeurbanne Cedex, France
Tel: +334 72 43 62 73
Email: youakim.badr@...
URL: http://www.insa-lyon.fr/liesp

About the series "Studies in Computational Intelligence"
---------------------------------------------------------

The series "Studies in Computational Intelligence" (SCI) publishes new
developments and advances in the various areas of computational
intelligence. The intent is to cover the theory, applications, and design
methods of computational intelligence, as embedded in the fields of engineering,
computer science, physics and life science, as well as the methodologies behind
them. The series contains monographs, lecture notes and edited volumes
in computational intelligence spanning the areas of neural networks,
connectionist systems, genetic algorithms, evolutionary computation,
artificial intelligence, cellular automata, self-organizing systems,
soft computing, fuzzy systems, and hybrid intelligent systems. Critical
to both contributors and readers are the short publication time and
world-wide distribution - this permits a rapid and broad dissemination
of research results. For more details, go through
http://www.springer.com/series/7092.

####################################################
# Richard CHBEIR, Ph.D. in Computer Science #
# Associate Professor #
# Laboratoire LE2I (UMR - CNRS) #
# Bourgogne University #
# Aile de l'Ingénieur #
# Office GS 16 #
# BP 47870 #
# 21078 Dijon CEDEX France #
# Tel.: +333 80 39 36 55 #
# Fax: +333 80 39 68 69 #
# Email: richard.chbeir@... #
# Web: http://www.le2I.com #
####################################################

WI/IAT 2008 - Call for Tutorials

2008-02-07T03:21:18Z

-- Call for Tutorials --

2008 IEEE/WIC/ACM International Joint Conference on Web Intelligence
and Intelligent Agent Technology (WI-IAT'08)

http://datamining.it.uts.edu.au/wi08/html/

The 2008 IEEE/WIC/ACM International Joint Conference on Web
Intelligence (WI'08) and Intelligent Agent Technology (IAT'08) takes
place on December 9-12, 2008, in Sydney,Australia. The IEEE/WIC/ACM
2008 joint conferences are organized by University of Technology
Sydney, Australia, and sponsored by IEEE Computer Society Technical
Committee on Intelligent Informatics (TCII), Web Intelligence
Consortium (WIC), and ACM-SIGART.

WI 2008 and IAT 2008 will include tutorials providing in-depth
background on subjects that are of broad interest to both the Web
intelligence community and the intelligent agent community. Both short
(2 hours) and long (half day) tutorials will be considered. Tutorial
topics will be determined later.

Note: we will not have a separate tutorials registration fee this year
(i.e., only one conference registration covers everything).

Tutorial Topics

The following is a non-exclusive list of preferred topic areas for
tutorial proposals:

Web Intelligence
− Intelligent/Semantic Web Services
− Intelligent Wireless Web and Ubiquitous Computing
− Rules and Inference Engines for the Web
− Semantic Web Concepts and Techniques for Security and Trust
− Service-Oriented Computing
− Social Networks and Social Intelligence
− e-learning and e-science
− Web Intelligence and Education

Intelligent Agent Technology
− Agent-Based Modeling and Simulation
− Agent Technologies in e-Business Systems
− Agent-Mediated Knowledge Management
− Peer-to-Peer Models for Multi-Agent Systems
− Agent-Based Grid Computing

Proposals related to these areas will receive special consideration.

Submission Details
Proposals for tutorials should consist of an outline and background
information on the presenter(s). The tutorial outline should be
limited to 2 pages and contain the following information:

Title and abstract of the tutorial
Proposed duration: 2 hours or half-day
Intended audience: to whom is the tutorial of interest
Prerequisite knowledge: what the attendees should already know
Detailed outline
The background information on the presenter(s) should be limited to
1-2 pages and contain:

Names, affiliations, homepages and contact details
Short biographies
Information about previous tutorials given by the same presenters
(title, location, number of attendees, etc.)
Tutorial materials such as handouts and slides should be included if
already available, but are not required for submission.

Please send your proposal to the tutorial chair, Ajith Abraham -->>
ajith.abraham@....

Important Dates

Tutorial submissions: July 15, 2008
Acceptance notices: July 30, 2008
Camera-ready copy of tutorial handouts: November 10, 2008
WI-IAT'08 Conference December 9-12, 2008