Re: Business Applications

Patrick Durusau <patrick-Q/[email protected]> Sun, 19 Aug 2012 11:08:12 -0400
Newsgroups gmane.text.xml.xtm.general,gmane.org.w3c.semantic-web
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--===============4441676829510765514==
Content-Type: multipart/alternative;
 boundary="------------040907030908010906070506"

This is a multi-part message in MIME format.
--------------040907030908010906070506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Quintin,

On 08/19/2012 07:10 AM, Quintin Siebers wrote:
> Hey,
>
> We've been working on such a system for a few years now, and our 
> current version is open to have a look at:
>
> http://en.mssm.nl/software/kamala-in-the-cloud/
>

Good point but Kamala requires (as any topic map application does) that 
you establish what subjects you want to talk about, their identifies, 
relationships, etc. Having said that, you can fill it with whatever 
content you like.

My objection to Sebastian's needs/features is their universal nature.

If I were writing a topic map for business expenses, it would be very 
unlikely to include the rules for receipts written in cuneiform (the 
earliest business document is a receipt for beer at an inn). Not that 
topic maps can't do that, but most clients are unlikely to be 
interested. For that matter, of the thousands of natural languages in 
existence, most clients are going to be interested in only one (1). 
Topic maps can do more but again, probably not a requirement.

You can see where this is going.

I think topic maps shine brightest meeting the semantic requirements of 
actual customers.

That someone, somewhere, off the Net most likely, is not best served by 
my topic map is quite likely.

But, I am not arrogant enough to presume to act in their best interest, 
never having asked what they want, much less their permission.

Is the "digital divide" (http://en.wikipedia.org/wiki/Digital_divide) 
the new "white man's burden? 
(http://en.wikipedia.org/wiki/White_Man%27s_Burden)"

Hope you are having a great weekend!

Patrick


> Quintin Siebers
>
> --
> [email protected] <mailto:[email protected]>
> (+31) (0)6 - 11 06 16 27
>
>
> Morpheus Kennistechnologie BV
> <URL: http://www.mssm.nl >
> postbus 69
> 3500 CD Utrecht
> KVK 30 26 04 30
>
> On 19 aug. 2012, at 13:03, Alexander Johannesen 
> <[email protected] 
> <mailto:[email protected]>> wrote:
>
>> Hola,
>>
>> On Sun, Aug 19, 2012 at 8:52 PM, adasal <[email protected] 
>> <mailto:[email protected]>> wrote:
>>> Is what you are proposing really possible from the ground up? I 
>>> wonder if
>>> even getting an architecture is possible from the ground up, i.e. 
>>> without
>>> starting with real world compromises dictated by the job in hand.
>>
>> Not sure if what's proposed is possible from the ground up, but I know
>> it's certainly possible to create an ontology-based complete system,
>> however I doubt "from the ground up" has been defined enough at this
>> point. I've worked on creating full-stack application and systems
>> delivery framework based on ontologies / Topic Maps, both in terms of
>> integration but also as a development tool, and as a way to infer
>> capabilities of services based on their entity / resource rather than
>> clumsy API's.
>>
>> I'm fairly confident that it's the way of the future, but as you
>> probably allude to as well, it's still a bit way off, mostly because
>> whomever comes up with it first or already doing it, are doing it in
>> solitary, much like the TM community watching the spectacle of RDF
>> from the side-lines.
>>
>>
>> Regards,
>>
>> Alex
>> -- 
>> Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
>> --- http://shelter.nu/blog/ 
>> ----------------------------------------------
>> ------------------ 
>> http://www.google.com/profiles/alexander.johannesen ---
>> _______________________________________________
>> topicmapmail mailing list
>> topicmapmail-Zo64W7twoUFWk0Htik3J/[email protected] <mailto:topicmapmail-Zo64W7twoUFWk0Htik3J/[email protected]>
>> http://www.infoloom.com/mailman/listinfo/topicmapmail
>
>
>
> _______________________________________________
> topicmapmail mailing list
> topicmapmail-Zo64W7twoUFWk0Htik3J/[email protected]
> http://www.infoloom.com/mailman/listinfo/topicmapmail

-- 
Patrick Durusau
patrick-Q/[email protected]
Former Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau


--------------040907030908010906070506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Quintin,<br>
    <br>
    <div class="moz-cite-prefix">On 08/19/2012 07:10 AM, Quintin Siebers
      wrote:<br>
    </div>
    <blockquote cite="mid:AD6FE4A3-1376-4AEB-A4EE-F4E8864D2006-FEL+ODTkcyY@public.gmane.org"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div>Hey,</div>
      <div><br>
      </div>
      <div>We've been working on such a system for a few years now, and
        our current version is open to have a look at:</div>
      <div><br>
      </div>
      <div><a moz-do-not-send="true"
          href="http://en.mssm.nl/software/kamala-in-the-cloud/">http://en.mssm.nl/software/kamala-in-the-cloud/</a></div>
      <br>
    </blockquote>
    <br>
    Good point but Kamala requires (as any topic map application does)
    that you establish what subjects you want to talk about, their
    identifies, relationships, etc. Having said that, you can fill it
    with whatever content you like. <br>
    <br>
    My objection to Sebastian's needs/features is their universal
    nature.<br>
    <br>
    If I were writing a topic map for business expenses, it would be
    very unlikely to include the rules for receipts written in cuneiform
    (the earliest business document is a receipt for beer at an inn).
    Not that topic maps can't do that, but most clients are unlikely to
    be interested. For that matter, of the thousands of natural
    languages in existence, most clients are going to be interested in
    only one (1). Topic maps can do more but again, probably not a
    requirement. <br>
    <br>
    You can see where this is going. <br>
    <br>
    I think topic maps shine brightest meeting the semantic requirements
    of actual customers. <br>
    <br>
    That someone, somewhere, off the Net most likely, is not best served
    by my topic map is quite likely. <br>
    <br>
    But, I am not arrogant enough to presume to act in their best
    interest, never having asked what they want, much less their
    permission. <br>
    <br>
    Is the "digital divide"
    (<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Digital_divide">http://en.wikipedia.org/wiki/Digital_divide</a>) the new "white man's
    burden? (<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/White_Man%27s_Burden">http://en.wikipedia.org/wiki/White_Man%27s_Burden</a>)" <br>
    <br>
    Hope you are having a great weekend!<br>
    <br>
    Patrick<br>
    <br>
    <br>
    <blockquote cite="mid:AD6FE4A3-1376-4AEB-A4EE-F4E8864D2006-FEL+ODTkcyY@public.gmane.org"
      type="cite">
      <div apple-content-edited="true">
        <span class="Apple-style-span" style="border-collapse: separate;
          border-spacing: 0px; "><span class="Apple-style-span"
            style="border-collapse: separate; color: rgb(0, 0, 0);
            font-family: Calibri; font-size: 13px; font-style: normal;
            font-variant: normal; font-weight: normal; letter-spacing:
            normal; line-height: normal; orphans: 2; text-indent: 0px;
            text-transform: none; white-space: normal; widows: 2;
            word-spacing: 0px; -webkit-border-horizontal-spacing: 0px;
            -webkit-border-vertical-spacing: 0px;
            -webkit-text-decorations-in-effect: none;
            -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
            0px; ">
            <div style="word-wrap: break-word; -webkit-nbsp-mode: space;
              -webkit-line-break: after-white-space; ">
              <div>Quintin Siebers</div>
              <div><br>
              </div>
              <div>--</div>
              <div><a moz-do-not-send="true"
                  href="mailto:[email protected]">[email protected]</a></div>
              <div>(+31) (0)6 - 11 06 16 27</div>
              <div><span class="Apple-style-span" style="font-size:
                  medium; "><br>
                </span></div>
            </div>
          </span>
          <div><br>
          </div>
          <div>Morpheus Kennistechnologie BV<br>
          </div>
          &lt;URL:&nbsp;<a moz-do-not-send="true" href="http://www.mssm.nl">http://www.mssm.nl</a>&nbsp;&gt;<br>
          postbus 69<br>
          3500 CD Utrecht<br>
          KVK 30 26 04 30</span>
      </div>
      <br>
      <div>
        <div>On 19 aug. 2012, at 13:03, Alexander Johannesen &lt;<a
            moz-do-not-send="true"
            href="mailto:[email protected]">[email protected]</a>&gt;
          wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">Hola,<br>
          <br>
          On Sun, Aug 19, 2012 at 8:52 PM, adasal &lt;<a
            moz-do-not-send="true" href="mailto:[email protected]">[email protected]</a>&gt;
          wrote:<br>
          <blockquote type="cite">Is what you are proposing really
            possible from the ground up? I wonder if<br>
            even getting an architecture is possible from the ground up,
            i.e. without<br>
            starting with real world compromises dictated by the job in
            hand.<br>
          </blockquote>
          <br>
          Not sure if what's proposed is possible from the ground up,
          but I know<br>
          it's certainly possible to create an ontology-based complete
          system,<br>
          however I doubt "from the ground up" has been defined enough
          at this<br>
          point. I've worked on creating full-stack application and
          systems<br>
          delivery framework based on ontologies / Topic Maps, both in
          terms of<br>
          integration but also as a development tool, and as a way to
          infer<br>
          capabilities of services based on their entity / resource
          rather than<br>
          clumsy API's.<br>
          <br>
          I'm fairly confident that it's the way of the future, but as
          you<br>
          probably allude to as well, it's still a bit way off, mostly
          because<br>
          whomever comes up with it first or already doing it, are doing
          it in<br>
          solitary, much like the TM community watching the spectacle of
          RDF<br>
          from the side-lines.<br>
          <br>
          <br>
          Regards,<br>
          <br>
          Alex<br>
          -- <br>
          Project Wrangler, SOA, Information Alchemist, UX, RESTafarian,
          Topic Maps<br>
          --- <a moz-do-not-send="true" href="http://shelter.nu/blog/">http://shelter.nu/blog/</a>
          ----------------------------------------------<br>
          ------------------ <a moz-do-not-send="true"
            href="http://www.google.com/profiles/alexander.johannesen">http://www.google.com/profiles/alexander.johannesen</a>
          ---<br>
          _______________________________________________<br>
          topicmapmail mailing list<br>
          <a moz-do-not-send="true"
            href="mailto:topicmapmail-Zo64W7twoUFWk0Htik3J/[email protected]">topicmapmail-Zo64W7twoUFWk0Htik3J/[email protected]</a><br>
          <a class="moz-txt-link-freetext" href="http://www.infoloom.com/mailman/listinfo/topicmapmail">http://www.infoloom.com/mailman/listinfo/topicmapmail</a><br>
        </blockquote>
      </div>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
topicmapmail mailing list
<a class="moz-txt-link-abbreviated" href="mailto:topicmapmail-Zo64W7twoUFWk0Htik3J/[email protected]">topicmapmail-Zo64W7twoUFWk0Htik3J/[email protected]</a>
<a class="moz-txt-link-freetext" href="http://www.infoloom.com/mailman/listinfo/topicmapmail">http://www.infoloom.com/mailman/listinfo/topicmapmail</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Patrick Durusau
<a class="moz-txt-link-abbreviated" href="mailto:patrick-Q/[email protected]">patrick-Q/[email protected]</a>
Former Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): <a class="moz-txt-link-freetext" href="http://tm.durusau.net">http://tm.durusau.net</a>
Homepage: <a class="moz-txt-link-freetext" href="http://www.durusau.net">http://www.durusau.net</a>
Twitter: patrickDurusau </pre>
  </body>
</html>

--------------040907030908010906070506--

--===============4441676829510765514==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
topicmapmail mailing list
topicmapmail-Zo64W7twoUFWk0Htik3J/[email protected]
http://www.infoloom.com/mailman/listinfo/topicmapmail

--===============4441676829510765514==--