OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [xtm-wg] For a general formalism of the semantic web - for more patient and formal work


Dear all,

reading you all, here are my thoughts :

1) people have been working for five years or more on topic maps and it is
still very difficult to find a PM that is formal and clear -> so I guess it
is time to explore new ways to formalize the PM

2) Ten years ago network and telco people had a lot of problems to
formalize, analyze and manipulate representation of telecom and computers
networks : they have been working since with graph theory people and most of
their tools comes from there (as example : see the ILOG component to
visualize network, see clustering algorithm...)

3) A PM is a way to process something, before to do that I think it is
useful to have a formalization of what we manipulate, then it will be a lot
easier to write PM

4) all specifications of the semantic web manipulates the same kind of basic
objects. Each specification has specialized some objects for their specific
need (ontology, index, complex document set...) and create their own syntax
to describe those objects - some organize the objects as tree (most of the
document DTD describes tree organization), other as non hierarchical graph
(RDF, XTM)...

5) at the final stage of semantic web processing the XML documents that will
be manipulate for query, filtering, clustering, indexing... will be a set of
linked documents coming from various authoring tools (OIL, TM, News ML...)
It will be difficult to say to the process to stop because it reach a
document conform to a different specification than the XTM specification...

6) When we make specification for "pure" XTM authoring tools we don't have
to worry to much about this other semantic web specification and it seems
that the actual XTM specifications are clear enough to let the development
teams write authoring tools for XTM

7) When we worry about how to process the result of the authoring tool which
is large XML documents (XTM) links to other XML documents (RDF, News ML)...
(by process I mean navigate, filter, query, ....)then we have to worry about
a general network of information with semantic to organize it.

8) Execpt if we think (the XTM community) a "XTM semantic web" separated
from the "general semantic web" will exist, we have to think PM in a larger
way

9) I don't mean there is not specific issue processing a TM (as it has a
complex and rich structure) - I mean that it is important to have a basic
formalism to talk about the basic components of the semantic web, shared by
all the specifications. Starting from that common vocabulary and formalism
each spefication will  specialize this vocabulary for it own needs and then
try to explain the specific constrain about processing a document conform to
their DTD.

10) will then have a semantic web PM for any XML document and advance
features of the PM to process a RDF document or a XTM document.

11) the process may seem a little to long to some of us but I think it is
worth doing it and that a project as ambitious and great as the semantic web
is worth spending some more time and gathering new kind of expertise (IA,
Math, Cartography..) to get out of this complex "soup" of specification
based only on syntax.

12) I see a lot of argument against a formal description using the concept
of graph theory that say : I will not understand it, so I will  not use it,
so it is not useful.
The argument is very weak as the issue is not to know if some of us will
have difficulties to understand the formalism (today some people can
understand TM concept but don't understand DTD ) but to know if it is "the
good formalism". For my part I think most of the processing of semantic web
will be quite complex and that most of the tools will be understood only by
the specialist of different fields.


Sincery

jean delahousse
www.mondeca.com



-----Message d'origine-----
De : Murray.Altheim@eng.sun.com [mailto:Murray.Altheim@eng.sun.com]De la
part de Murray Altheim
Envoye : jeu. 22 mars 2001 20:14
A : xtm-wg@yahoogroups.com
Objet : Re: [xtm-wg] Simplified requirements


Sam Hunting wrote:
>
> Here is a list of requirements for the PM that I believe meets Lars
> desires, and is also readable by all XTMers (implementors, designers,
> users)
>
> 1.  The PM shall be formal and concise.
> 2.  The PM should be prepared quickly.
> 3.  The PM shall support a wide variety of applications.
> 4.  The implementor shall find it easy to write programs that
>     conform to the PM.
> 5.  The number of optional features in the PM should be kept
>     to the absolute minimum, ideally zero.
> 6.  PM documentation should be clear.
> 7.  The design of the PM shall consider interoperabilty of XTM
> documents
>     of paramount importance.
>
> I honestly don't understand the controversy on "formal and concise."
> This is right out of XML 1.0. Can anyone argue that the productions in
> XML 1.0 are not useful -- particularly for ensuring interoperability?

My feeling (after having written my own com.sun.xml.xtm package) is that
the existing implementations I've seen (or discussed) stay close to the
syntax. Mine does too. The big problem I have is similar to Lars Marius'
complaint: where does one store <resourceData>? how does one keep track
of the complex structure without losing it in a graph? how does one
decompose back to XTM?

I can think of others. But I too while hope to see a formal processing
model, have had at least as much difficulty as anyone understanding
how to implement it. I'm no genius programmer, but then there aren't
that many of them. The published PM needs to be accessible to people
like me (here I am acting as guinea pig again). I'm not saying that
you're barking up the wrong tree, but I like others need to be first
able to comprehend and then convinced that it works and is not an
enormously more difficult task than what we've already done. And if
it's impossible to implement a topic map engine without a very specific
graph structure that few can understand, then we've all participating
in generating business for a few individuals and nothing more. I
refuse to believe that.

I'm all for "simplified requirements" and "simplified models."

Murray

..........................................................................
Murray Altheim                            <mailto:altheim&#x40;eng.sun.com>
XML Technology Center
Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., Menlo Park, CA 94025

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu


To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




------------------------ Yahoo! Groups Sponsor ---------------------~-~>
Secure your servers with 128-bit SSL encryption!
Grab your copy of VeriSign's FREE Guide,
"Securing Your Web site for Business." Get it now!
http://us.click.yahoo.com/KVNB7A/e.WCAA/bT0EAA/2n6YlB/TM
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC