TiddlyWiki / TiddlyWeb and semantic web

[PMario]

I started a new thread, because I think it needs one:

trigger: http://groups.google.com/group/tiddlywiki/browse_thread/thread/80f68fdb2d24b603?hl=en
=======

On Oct 11, 11:31 pm, Saverio <saverio.mavig...@gmail.com> wrote:
> I think the whole set of notions about slices, sections, fields, and
> tags needs a careful re-evaluation. The pros and cons of each of these
> alternatives should be enumerated and summarized. It may be that some
> methods should be consolidated, and perhaps other ways be made more
> robust, such as to support truly semantic tagging (see thread here
> [1]).
>
> [1]http://groups.google.com/group/tiddlywiki/browse_thread/thread/b501b9...

Hi Saverio,
Your link doesn't give any information to me, what you really want.
You point to media wikis semantic web landing page [1]. From there I
can go to the introduction page [2] and find:

"Where SMW (Semantic MediaWiki) can help" - cool - may be this gives
some info.
a) Automatically-generated lists.
b) Visual display of information
c) Improved data structure
d) Searching information
e) Inter-language consistency
f) External reuse
g) Integrate and mash-up data

This are topics, that are for sure very interesting in the tw context.
Especially for TiddlyWeb and/or TiddlySpace.

=====
Then I thought: "Ok let's look for the syntax" ... whooomm ...
It seeems "Web Ontology Language" [4] short: "OWL" is needed. W3C
Recommendation 27 October 2009 [5]

[4] Some history ... bla bla ...
!Examples
Thats nice. "human readable ????" (IMO XML is __not__ human readable)
... found:
Manchester-syntax [6] that looks very close to tiddler Slices ...
yipee :)

=====
Now let's essemble the new knowledge to a real world problem and solve
it with tw.
you wrote: [3]

>But what if I could enhance tags to
>explicitly define the relationship type. Then I could have tiddler
>"A" tagged with "isA(task)", "belongsTo(B)", "dependsOn(C)". These,
>in essence, are extended fields, but extended fields are more hidden
>and obscured than tags. I hope that a future version of TW combines
>the best of both tags and extended fields to make it a truly semantic
>product.
Assumptions:
MatchTagsPlugin [7] is installed.
A .. tagged: task B
B .. tagged: project
C .. tagged: task B

C .. A depends on C (not solved yet)

Relations for A:
isA(task) .. not needed: same as tagged: task
belongsTo(B) .. is not needed, because A is tagged:B
dependsOn(C) .. not solved yet


Questions, that can be answered: (incomplete list)
Q1: "List tiddlers that belong to project B"
A1: <<list filter [tag[B]]>>

Q2: "list all tasks"
A2: <<list filter [tag[task]]>>

Q3: "list all tiddlers in project B that are tasks"
A3.1: <<list filter "[tag[B AND task]]">>
A3.2: <<matchTags ...>>

======
Let's think about: "A (task) depends on C (task/project/wahtever)"

A contains:
|Author:| pmario |
|Description:| this is a task |
|Dependencies:| C, D |

lorem ipsum 100 times

What I would do:
*Tag A waiting
*Tag every finished task with: done
*A tagged: C
*tag mission critical tasks with "critical"

Q4: "List all tiddlers that have Dependencies, and ar tagged waiting?"
A4: I am sure, that fET or a new macro can solve this. May be some
other macros can solve it allready too.

Q5: "Which tasks are waiting"
A5: <<list filter [tag[waiting]]>>

Q6: "display waiting tasks in project B"
A6: <<list filter "[tag[B AND waiting]]">> klick the link and have a
look at the text, why it is waiting

Q7: "Which tasks are critical and waiting"
Q8: <<list filter "[tag[critical AND waiting]]">>

======
May be you don't like the sort order of a <<list>> output. Then custom
fields come into play. author, modified, created and any other custom
field you can think of.

PRO: it is metadata and allmost invisible
CON: it is metadata and allmost invisible

CON: macros are needed to nicely handle it
PRO: There are allready many plugins
PRO: As far as I can see, this is intention
CON: using plugins tw is getting bigger and bigger
...
...

======

I don't know, if the above solutions are semantic in the meaning of
OWL2 [5]. But they work :)

kind regards
Mario Pietsch


[1] http://semantic-mediawiki.org/wiki/Semantic_MediaWiki
[2] http://semantic-mediawiki.org/wiki/Help:Introduction_to_Semantic_MediaWiki
[3] http://groups.google.com/group/tiddlywiki/msg/9798ac19aa848c7b?hl=en
[4] http://en.wikipedia.org/wiki/Web_Ontology_Language
[5] http://www.w3.org/TR/owl2-overview/
[6] http://www.w3.org/TR/owl2-manchester-syntax/#Quick_Reference

[Tobias Beer]

Here's what I tried to post as a reply to Saverios older thread and
maybe it gets through today...

Hi Saverio,

Redirected from here [1], some feedback...

As for using tagging, ColoredLinksPlugin [2] might come in handy ...to
differentiate whether a tag corresponds to a project or to a task, as
those categoris might have different css styles attached to them.
Note, however, that this approach will not allow you to differentiate
between 'dependsOn' vs. 'isDependencyFor'. Tagging simply does not
provide this flexibility (today).

So, I would say, semantics are best implemented either using
fields ...or, if you must, using slices.

Maybe one day, tagging will allow you to attach a qualifier to a tag,
e.g: dependsOn->taskA or isDependencyFor->taskB ...but then, would one
of the two tiddlers be tagged? Would it have to be harmonized which
item to tag? The dependency or the dependent? The father or the child?
Preferably the child, I guess. Is this strictly a 1 to 1 or a 1 to
many relation and how would it therefore have to be established? As
always, these things are a matter of implementation and acceptance of
such implementations.

I wholeheartedly agree that 'semantic tagging' is quite
neglected ...not just in the TiddlyVerse. For trying to make use of
semantics in TiddlyWiki, again, I would say, custom fields are what
you want to use (or ask for) when it comes to implementations of
certain logics based on given semantics.

One day, there will be people and their tools to whom using general
abstractions for semantics will be commonplace and thus readily
available to be used by all kinds of plugins (or systems in general).
I mean, semantics are a real shortcomming in most anything www today.

A link should never just point somewhere, but instead qualify its
intent, its meaning, its (semantic) relation ...a relation that in an
ideal web would be subject to scrutiny and evaluation by others ...via
thumbs up or thumbs down.

In that context, a link really is a poor abstraction if it does not
point to a highly specific target ...whereas a "whole page" might be
utterly unspecific in that regard. Instead, links should point to
sections or even more precise contexts.

The most used of all browser plugins should really be something that
allows everyone to define semantic relations for any hyperlinks found
and the precise target context that one refers to ...stored in a
universally accessible database ...whereas everyone would have his or
her vote as to the meaningfulness of the relation that someone else
bothered to establish.

Such a database which one might even be able to query as to "How do
certain people qualify a given relation?", e.g. "How do (accredited?)
scientists qualify the relation of a given article('s claim) to
another one it points to?" ...as in "is proof for" or
"defies" ...'because' (involving an ability to comment), etc...

There probably should be a harminzed, global set of semantics that
people generally use to qualify relations, not just any mumbo jumbo.
Or maybe semantics could be scrutinized just as well. Meaning, people
should be able to assign little importance to a semantic relation that
reads "is the housekeeper of a tiny red dog with 3.4 inch long pubic
hair that belonging to" as opposed to simply "is part of" or "belongs
to" or "is parent of".

But even then, semantic relations probably need qualifiers on both
ends. A parent could be one in a number of possible parents, e.g a
mother, a father, an ancestor, some original entity, an embodying
entity, etc. It might make a crucial difference as to whether or not
"belongs to" involves certain legal rights or obligations or simply
expresses a certain desire of attachment ...so here we are, back, on
the plane of human, hardly-machinable interpretation.

Cheers, Tobias.

[1] http://groups.google.com/group/tiddlywiki/msg/38c150ee1b5dc95b
[2] http://coloredlinks.tiddlyspot.com/

[Saverio]

> Let's think about: "A (task) depends on C (task/project/wahtever)"
>
> A contains:
> |Author:| pmario |
> |Description:| this is a task |
> |Dependencies:| C, D |
>
> lorem ipsum 100 times
>
> What I would do:
> *Tag A waiting
> *Tag every finished task with: done
> *A tagged: C
> *tag mission critical tasks with "critical"
>
> Q4: "List all tiddlers that have Dependencies, and ar tagged waiting?"
> A4: I am sure, that fET or a new macro can solve this. May be some
> other macros can solve it allready too.
>
> Q5: "Which tasks are waiting"
> A5: <<list filter [tag[waiting]]>>
>
> Q6: "display waiting tasks in project B"
> A6: <<list filter "[tag[B AND waiting]]">> klick the link and have a
> look at the text, why it is waiting
>
> Q7: "Which tasks are critical and waiting"
> Q8: <<list filter "[tag[critical AND waiting]]">>
>

This is exactly the way I have implemented my own gtd paradigm within
TW. However, in addition to the plugins you mention, this approach
requires building a set of *processes* that essentially encode the
relationship "depends on". For example, when I click task A as being
done, I have to go and search all other tasks tagged with [task A] and
remove the [waiting] tag from them....unless they themselves are
dependent on another task that is not yet completed. If a task can
depend on more than one other task or project at a time, than this can
get very complicated very quickly. This is a lot of overhead to
simply cross off a task from your todo list, especially if you are not
a programmer.

Of course, you can always download a ready made TW application with
all of these extra functions built-in, and give up on the ability to
customize, but then you give up as well a large part of the appeal of
vanilla TW. Even then, an application for one use case is not
generalizable to other use cases - a completely different application
must be built. This goes against TW's other major attractive feature,
the ability to re-using concepts and structures over and over again
for different use cases.

In my opinion, simple tags, which imply an isA relationship, go a
*long* way, but not as far as possible with semantic tags. It would
be nice for the next version of TW to support a more powerful method
to relate tiddlers to each other.

[PMario]

That's right. But from a programmers point of view a tag dependsOn(C)
doesn't solve this problem either.
What you want here, is a mechanism that tells "the core":
*if tiddler C is tagged done
**remove all tags waiting from tiddlers tagged dependsOn(C)
*If a tiddler tagged dependsOn(xx) is tagged done
**check tiddler xx if it is tagged done, ask the user, what to do, if
not

The above is a very user (use case) specific desire and needs,
specialiced macros, that are prepared to handle it.

> Of course, you can always download a ready made TW application with
> all of these extra functions built-in, and give up on the ability to

> customize, ...
I don't think so. You only need more time, to understand, how to
customize it.
It's true, that this can be very tricky, and sometimes very
frustrating.

> .. but then you give up as well a large part of the appeal of
> vanilla TW. ..
That's right. The first thing I check if I find an interesting plugin
is: Is there a possibility to solve it with core functions. And since
the TW core is allready big (my opinion) it is very hard to convince
the devs to include something new, if it could also be done with
plugins.

> ..  Even then, an application for one use case is not

> generalizable to other use cases - a completely different application
> must be built.  

In the GTD case it seems like a new application. But it isn't. It is a
vanilla tw with plugins. Many of them but still only plugins.

> This goes against TW's other major attractive feature,
> the ability to re-using concepts and structures over and over again
> for different use cases.

see above. only plugins.

> In my opinion, simple tags, which imply an isA relationship, go a
> *long* way, but not as far as possible with semantic tags.  It would
> be nice for the next version of TW to support a more powerful method
> to relate tiddlers to each other.

I'm sorry I still don't know, what "semantic tags" means for you.

regards
Mario

[Saverio]

> I'm sorry I still don't know, what "semantic tags" means for you.
>
> regards
> Mario

Semantic tag is both the specification of the *relation* as well as of
the *value*. Here is another (made up on the fly) use case - an issue
tracker. Each issue is a tiddler, and issues need to be associated
with both the individual who initiated the issue (the "initiator") and
the individual who is responsible for resolving the issue (the
"resolver"). Each individual is its own tiddler, and an individual
may be both an initiator of one or more issues while at the same time
responsible for resolving one or more other issues. With tags alone
(ie. not slices or fields), it is impossible to distinguish whether
the individual tagged to an issue is the initiator or the resolver.
For that, you need to also specify the relationship. This *can* be
represented in TWs today with slices:

|Initiator:| individualA |
|Resolver: | individualB |

or with extended fields (using pseudocode):

tiddler.field['initiator']='[[individualA]]'
tiddler.field['resolver']='[[individualB]]'

The problem with slices is that you need to maintain the data within
the body of the tiddler, even though it is *metadata* like a tag. The
problem with fields is that they are obscure to the casual or non-
programmer user.

I am only suggesting a "simpler" method which would accomplish what
slices and fields can do, but remains as transparent and easily
understood as tags. Then, I could add tags such as
'hasInitiator(individualA)' and 'hasResolver(individualB)' as well as
traditional tags such as 'urgent' and 'resolved'. This extends (but
does not replace) the current tagging mechanism because if no
relationship is specified, the "isA" or "is" relationship is assumed.
The current methods that access and set tags would need to be extended
to deal with the new types of tags, but hopefully would remain as easy
to understand and utilize as today's methods to access and set tags.
Tobias raised some good points above about how to reason over the
reverse of a semantic tag or the cardinality of relationships, and I
am sure there are other complicating issues that would need to get
resolved.

[Tobias Beer]

Hi Saverio,

> For example, when I click task A as being done,
> I have to go and search all other tasks tagged with [task A]
> and remove the [waiting] tag from them

If that's the workflow you are using, then I think you're doing it the
wrong way around.

As I suggested before, you want to have the child tag to the father,
the task to the project, the subtask to the task, the item to the
owner, etc...

A dependent action should not tag to the action it depends on but the
other way around. Then, you would never mark a dependent action as
complete if you saw it depends on something else, something that tags
to it ...you would first have to clear the dependency. Once you're
done with that you would remove any other tags that point to actions
depending on the one you just marked done. So, in this case, marking
an action as done might come with a desire to automatically remove all
tags that point to other actions ...if one made it a convention to
only tag one action with another if it expressed a dependency.

So, what it seems to boil down to is a question of which workflows are
smooth and which aren't. For example, it makes little sense if the
next thing your system suggests to do is to take care of actions which
themselves depend on other actions ...as you first have to take care
of the latter or split the former into more action items that you can
immediately take care of.

As for tbGTD [1]... though it does come with some noticable plugin
overhead, it does not deprive you of any ability for customization, to
the contrary. The same I would guess applies to mGSD, though it does
somewhat take away the tiddler as a somwhat uniform basic
entity ...which could be either this or that. mGSD assigns rather firm
roles and templates to a tiddler ...which however can be changed using
the mGSD interface, e.g. by clicking a button to turn a task into a
project or tickler, etc...

Lastly, the more powerful, semantically exploitable methods to relate
tiddlers to each other DO EXIST today. Fields as well as splices can
contain TiddlyLinks and thus point to other tiddlers while defining a
precise relation based on a naming convention.

Cheers, Tobias.

[1] http://tbgtd.tiddlyspot.com

[Tobias Beer]

> The problem with slices is that you need to maintain the data within
> the body of the tiddler, even though it is *metadata* like a tag. The
> problem with fields is that they are obscure to the casual or non-
> programmer user.

I would disagree... those are not problems, those are conventions, if
not features. Again, waht PMario also seems to suggest is a focus
maybe on a new plugin that allows you to setup semantics based on
either slices or fields or both and to construct certain simple logics
or rather workflows around it.

Example 1) If an item get's marked done (whereas maybe only only those
tagged "action" can be), show me which other actions semantically
declared as "dependent" should now be resolved ...by default, mark all
dependencies as "to be removed" and once I click "ok" remove the
dependencies. Otherwise, if I had unticked a dependency from the
"remove dependency" process ...iit would remove the ticked
dependencies, yet let me revisit that item to reevaluate it's done
status.

Example 2) Issues. Once I (as the resolver) mark an issue as resolved,
show me its initiator and possibly an action to open the corresponding
tiddler ...and thus maybe information or gui elements that allow me to
inform the user about the issue being resolved.

So it boils down to defining "workflows" / "wizards" or "automated
processes" around tiddlers for which certain slice:value or
field:value pairs match given criteria.

Cheers, Tobias.

[Måns]

Hi

> Example 1) If an item get's marked done (whereas maybe only only those
> tagged "action" can be), show me which other actions semantically
> declared as "dependent" should now be resolved ...by default, mark all
> dependencies as "to be removed" and once I click "ok" remove the
> dependencies. Otherwise, if I had unticked a dependency from the
> "remove dependency" process ...iit would remove the ticked
> dependencies, yet let me revisit that item to reevaluate it's done
> status.

Maybe we need a new RenameTags plugin which can rename or delete a
tag, which doesn't exist as a tiddler??

Cheers Måns Mårtensson

[Tobias Beer]

Hi Måns,

As suggested before - when it comes to mapping semantic relations to
TiddlyWiki elements - I would focus on using fields or slices in order
to make us of them in given adaptations ...one of which one might call
"WorkflowPlugin".

However, RenameTagsPlugin is a good example for the kind of automation
that one might wish to apply to working with semantic relations.

To not only have this discussion but maybe leave some information in a
more condensed form for the rest of the us, I have created the
following space and already added you Måns and PMario as members...

http://semantic.tiddlyspace.com

Whoever is interested in participating, please leave a note or contact
me here...

http://tobibeer.tiddlyspace.com/#Contact

If you wish to join in, you should be past the point of asking
questions like...

What is semantics?
Why use the term?
What's the big deal? Isn't that just flields, tags and slices?

...but rather help clarify such information for visitors of that space
the way you would want it presented.

Cheers, Tobias.

[Jeremy Ruston]

> Semantic tag is both the specification of the *relation* as well as of
> the *value*.  Here is another (made up on the fly) use case - an issue
> tracker.  Each issue is a tiddler, and issues need to be associated
> with both the individual who initiated the issue (the "initiator") and
> the individual who is responsible for resolving the issue (the
> "resolver").  Each individual is its own tiddler, and an individual
> may be both an initiator of one or more issues while at the same time
> responsible for resolving one or more other issues.  With tags alone
> (ie. not slices or fields), it is impossible to distinguish whether
> the individual tagged to an issue is the initiator or the resolver.
> For that, you need to also specify the relationship.  This *can* be
> represented in TWs today with slices:

Another way that this can be done is to use "compound tags", such as
"resolver:Jermolene" or "raiser:PMario".

Cheers

Jeremy

--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com

[Tobias Beer]

Never looked at it that way... but doing a query against the store for
such tags would be rather straightforward... provided one knew what to
look for.

Mapping...

store.getTaggedTiddlers(resolver+':'+user)

...to some output list- or table-view seems rather simple.

Not so simple would be to get all tiddlers with any resolver assigned.
But then the author of such a system would probably know which
tiddlers potentially are those that (might) have a 'resolver'
attached, e.g. 'issues' ...and that the specified entity would be one
of 'users'. However, one could always search for
indexOf('resolver:')==0 in all tags of all tiddlers (or maybe just a
preselected few that have a certain tag).

However, I would still much prefer fields or slices for such a
usecase. I would also presume that searching for a field (or slice)
called "resolver" and the corresponding value for all tiddlers would
be much quicker than looking through all tags of all tiddlers to find
out which ones have a prefix of 'resolver:'.

Usually, assigning resolvers to issues would probably not come with a
standard Edit- or ViewTemplate. In such a case, dedicated templates
seem much more appropriate. Thus, certain dedicated fields were no
longer difficult to access or edit.

Tobias.

[Måns]

Hi Tobias

I've added VUE in the ShowCase tiddler - hope it's relevant..

Cheers Måns Mårtensson

[Saverio]

Yes! A set of functions for resolving relation and tag value would be
a great start. A cached table of declared relationships in a shaddow
tiddler, updating it whenever tiddlers are saved or tags are edited,
might help address the performance concern. Would continuing this
discussion, perhaps on http://semantic.tiddlyspace.com, to flesh out a
set of functional/technical requirements be a good next step?

[Tobias Beer]

> Would continuing this discussion,
> perhaps on http://semantic.tiddlyspace.com, to flesh out a
> set of functional/technical requirements be a good next step?

Whatever brings you forward! Though, when it comes to discussing
details - and for lack of a better forum - I think the groups are the
way to go.

[Tobias Beer]

That's really interesting and fit's there very nicely, indeed. So,
thanks for sharing! It's exactly stuff of that quality, along with
more TiddlyWiki centered content, that I hope will be found in spaces
like this 'semantic' space... maybe with a few condensed lines of
background information, though. ;o)

[Måns]

> maybe with a few condensed lines of background information, though. ;o)

Done.

Cheers