W3C home > Mailing lists > Public > semantic-web@w3.org > September 2011

RE: New semantic web related project - Finndesign Liitin

From: Jukka Tuominen <jukka.tuominen@finndesign.fi>
Date: Fri, 16 Sep 2011 17:56:20 +0300
To: "Adam Saltiel" <adam.saltiel@gmail.com>
Cc: <semantic-web@w3.org>
Message-ID: <IDEKILMNNCEAPIAMCIAOKEHNNCAA.jukka.tuominen@finndesign.fi>

Hi Adam,

there's a lot to say, but I try to keep it shortish...

> -----Original Message-----
> From: semantic-web-request@w3.org [mailto:semantic-web-request@w3.org]On
> Behalf Of Adam Saltiel
> Sent: 16 September 2011 15:03
> To: Jukka Tuominen
> Cc: <semantic-web@w3.org>
> Subject: Re: New semantic web related project - Finndesign Liitin
>
>
> Hi
> Thanks for your notes.
> About your application.
> 1. How is it different from Nepomuk the semantic desktop which
> Saurman et al have evolved into Refinder?
> 2. There is also Kiwi the semantic wiki project that is in
> similar problem domain.
> Interesting tid bit.

I know very little about these projects, so I'm on a very thin ice here, but
my initial impression was:
- Liitin is far more fundamential enforcing compatibility time-wise and
between users, which I didn't see in these projects. These are at the mercy
of operating system changes. Java VM (unfortunately) is no different, it's
just floating horizontally. I understood that Nepomuk project has ended, and
the outcome is doomed to fade away without constant manual re-porting.
- Liitin is far more fundamential enforcing persistence which I didn't see
in these projects. It is already a built-in 'service' so there's no need to
create a new platforms and data storage schemes.
- Liitin is domain independent. Eventhough Liitin has naturally a semantic
nature, you could use it for very different purposes and yet producing
automatically semantic content; same (base) format, manipulable with the
same tools, in principle. I mentioned earlier (in another message) about
saving "atomic data". Just to elaborate it briefly; in a matter of seconds
after logging into Liitin, you could save a new Liitin object just by giving
it a name, say userx:a-number and  content "123". There. No cryptic markup
format, no special database operations, no special submitting procedure to
have it published. Anybody/everybody can see the new object immediately, you
can refer to it with automated tools without a fear it may disappear some
day. Or, instead of a static "123", you could supply a Scheme procedure to
produce the number, have it read from a device, etc.

So in all, I would think that the mentioned projects/tools could comfortably
sit on top of Liitin, having both the tools and the data stored and
distibuted through built-in services. The development does not need to stop
either but have it done within Liitin.


> Reading your email google suggested a link to Jane Street. They
> are a trading house. I urge you to look them up if you are
> interested in the future of and application of functional programming.

I've also seen it popping up often when reading Scheme-related documents.
I'm not a programmer, however. Merely use it to make things possible,
automate things, and test new ideas. That should say something about how
accessible it is for the beginners :)

> Still I find myself very unsure what is being proposed when you
> say Protege may be wrapped in the interface or some other
> program. I find it difficult to get my head round this in the
> context of a human life span. Something that worked in Protege
> time t1 will work at t2 because the very complete application
> version including all configuration is made available? Or is
> Protege an example of a helper program that enables Liitin?

Protege was just an example for two things.
1) You can build and store GUI apps in Liitin and have them treated as any
other Liitin objects (persistency, compatibility, distribution, access to
source code, modify easily...)
2) The content that is stored in Liitin needs domain specific tools. You
could have image editors for images just as well. However, due to semantic
nature of Liitin, you could use semantic tools to search, infer, and
manipulate any content really, no matter how and why they were originally
created.

>In
> which case there is the other side of the same question.
> In short how big or small are we thinking?
> If we think on a smaller scale then the fluctuations that happen
> across a life time will undo us. If we think large scale then we
> are swamped by the size of something only distributed computing
> power and storage can deal with.

In short: big _and_ small.

Not so short: Liitin originated as a personal user interface (hardware and
software) that would make daily computer and computer-operated device use
less frustrating, optimise it for your own personal preferences, and even
augment in many occasions. (see the project site for more details). So, if
somebody just uses Liitin for personal purposes, and never publishes
anything during life-time, then that's perfectly fine. It still improves
current situation, and common contribution may take other forms, if you can
better concentrate on "essentials". You are likely to utilise public
knowledge and methods, however.

If you do contribute, then all that will be available to others even after
you're gone. The big difference, however is that you could access is far
easier. Not just knowledge, but also methods! How cool is that!? For very
few people, the enabling technology is of importance. The knowledge and
methods, however, last easily decades, centuries, even milleniums. Big
enough?

When it comes to Liitin limits in terms of storage size and computing power,
I would say that it is always limited yet ever-expanding. Mr Moore can
present more precise figures.

> Or, again, we may assume the distributed framework and seek to
> establish a set of conventions through metadata tagging as to
> what passes my way I consider mine and what not mine.
> I'm sure I've misunderstood all along but if this is the picture
> 1. Why would I do this?
> 2. How to prevent claiming everything as mine well at least in
> the domain of knowledge where claims of prior art and originality
> are important?
> Perhaps the impulse not to share would be no greater than today, though.
>

I'm very much with you here. As mentioned above, privacy is very important
and you won't see Liitin going through your personal data and monitize on
it, eventhough popular already now. How to accomplish this so that people
(including me) can really trust it, is a big issue. Then again, even today
you spread your information into countless computers, mobile devices,
Internet, physical objects, and so on. In many places Liitin would actually
improve the situation if done right!

br, jukka

>
> Sent from my iPhone
>
> On 15 Sep 2011, at 14:08, "Jukka Tuominen"
> <jukka.tuominen@finndesign.fi> wrote:
>
> >
> > Hi Adam,
> >
> > interesting thoughts and indeed difficult to have answered
> 'correctly'. They
> > will eventually need to be answered, and are even likely to
> change during
> > time and also geographically (culturally). Propably there will
> need to be
> > global rules eventually, even lasting time.
> >
> > We have thought about these issues quite a lot (regarding
> Liitin). Below are
> > some preliminary thoughts, feel free to comment on them to either
> > consolidate or to return for reconsideration.
> >
> > - Each Liitin user (= namespace owner) can store either private
> or public
> > data. Organisations may also have (pseudo) namespaces, behaving
> identically
> > but just more identifiable namespace name. You cannot interfere
> with other
> > namespaces other than view/execute/'import' to your own
> namespace in case
> > they are made public (= simple save operation)
> > - Format for Liitin object name is:  namespace:object-name
> >
> > A) Private data. This is considered as the user's private
> property. It does
> > have all the same persistency properties as well, and the data
> (and methods
> > among them) is supposed to follow you the whole life time. In
> this sense, it
> > starts to resemble more personal memory rather than mere personal home
> > directory. This data could/should have strong protection (even personal
> > encryption hidden from any system administration), and once you die it
> > remains protected (or erased) unless you have specifically exported
> > information. BTW, private data was considered before public
> data as part of
> > "Personal User Interface".
> >
> > B) Public data (= not private to anybody) needs to be free and not
> > copyrighted once stored to Liitin (currently LGPL v3
> considered). This is
> > extremely important, since there is not really a ownership concept in
> > Liitin. You may be the originator, or a contributor, and
> similar things, but
> > in practise when you make any changes to public objects, you always save
> > them to your own namespace. Therefore, the connection between
> the namespace
> > and the object is very loose and should not be associated with
> ownership.
> > Say, you correct a spelling mistake and save the change. Eventhough all
> > public objects should be 'common property', there will be cases that
> > copyrights are violated or confidential information placed public by
> > mistake. There are in-built methods to deal with these
> occasions. Naturally,
> > they may (intentionally) break persistency if these objects are
> referred to
> > after this point of time.
> >
> > Generally, there's a pretty good analogy to publishing information in
> > newspaper, or carving information on pyramid walls.  It is public
> > information thereafter - it is very difficult to undo it
> afterwards. "What
> > happends in Internet stays in Internet" :)
> >
> > br, jukka
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Adam Saltiel [mailto:adam.saltiel@gmail.com]
> >> Sent: 15 September 2011 14:47
> >> To: Jukka Tuominen
> >> Cc: <semantic-web@w3.org>
> >> Subject: Re: New semantic web related project - Finndesign Liitin
> >>
> >>
> >> All my data. The issue is two fold. Who am I. What data is mine.
> >> Although I don't pretend to have an answer to the former I think
> >> that most people would agree
> >> 1. An answer to the later has bearing on the former.
> >> 2. The answer to the former in so far as it is manifest in
> >> behaviour has bearing on the later.
> >>
> >> This is
> >> 1. A loop
> >> 2. A subtle conundrum. If one influences the other what are the
> >> possibilities that control and therefore influence will be that
> >> of an agent not myself? But I said subtle. We shouldn't assume
> >> that is undesirable. I drive down the street where all the other
> >> vehicles ...
> >> 3. Raises the obvious issue of data ownership. What with Omniture
> >> and Google analytics and so. Even the raw legal issues are
> >> unclear, at least to me. For instance one might think that a web
> >> site displayed in your browser belongs to the web site
> >> owner/publisher. It does. And that the data you enter into a form
> >> belongs to? That is more complex.
> >> But one thing. Anonymised data conclusions drawn at a time which
> >> we don't have access to, may be the very thing we need for a
> >> coherent picture of where we were or are now w.r.t. our
> intended activity.
> >> Personally I am very unhappy about the data matrix of social
> >> media but happier when I consider an intelligent environment.
> >> There are some complex issues here.
> >> Considering the huge amount of data and it's disparate origins I
> >> take it that your task is to mediate between sets. But note how a
> >> perfect memory or a memory of surprising detail (the past may be
> >> reinterpreted in the light of hitherto hidden information) holds
> >> it's own perils for human mortals. Not least that the aim of
> >> coherence and identity through longevity may be undermined by the
> >> mechanisms that attempt to establish this.
> >>
> >>
> >> Best
> >>
> >> Adam
> >>
> >>
> >> Sent from my iPhone
> >>
> >> On 13 Sep 2011, at 12:44, "Jukka Tuominen"
> >> <jukka.tuominen@finndesign.fi> wrote:
> >>
> >>> Hi all!
> >>>
> >>> I'd like to introduce you to a project that you may find
> interesting. It
> >>> didn't start as specifically semantic web related, but perhaps
> >> that's one of
> >>> the reasons that it may bring a new perspective to it.
> >>>
> >>> There are many aspects to the project, but related to semantic
> >> web I'd like
> >>> to bring forward a few characteristics that you may find of particular
> >>> interest.
> >>>
> >>> - Whereas software and hardware platforms come and go frequently, the
> >>> essence of knowledge and methods may last from generations to
> >> generations.
> >>>
> >>> - To be able/willing to build on top of somebody else's work,
> >> you need to
> >>> trust its future existance and predictable behaviour.
> >>>
> >>> - There are lots of great free software and utils out there
> >> even today, but
> >>> due to incompatibilities and overall complexity to setup a working
> >>> environment, they are often out of the reach of most of us. Or
> >> it's just not
> >>> worth the trouble. You'd rather contribute to your own field of
> >> expertise.
> >>>
> >>> Our project Finndesign Liitin is addressing these issues in a
> >> new way, yet
> >>> trying to keep it very simple to the user. You pretty much
> just walk/log
> >>> into a ready-made environment, and will have access to all
> personal and
> >>> public data and methods in a compatible and persistent manner.
> >>>
> >>> Please, have a look at the project page for details at
> >>> http://liitin.finndesign.fi
> >>>
> >>> Eventhough I'm very interested in things that semantic web is
> >> addressing, my
> >>> primary field of expertise is in user interface design
> >> (industrial design
> >>> education). Therefore I'd be very interested in your
> >> professional opinion on
> >>> how Liitin might be suitable for your needs, or how it may need to be
> >>> tweaked in order to suit it better.
> >>>
> >>> The project page may not cover all details, so I'd be glad answer any
> >>> questions.
> >>>
> >>>
> >>> Best regards,
> >>> Jukka Tuominen, Finndesign
> >>>
> >>>
> >>>
> >>>
> >
>
Received on Friday, 16 September 2011 14:56:50 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:41:29 UTC