Tagging Infrastructure

[Simon Harper]

Hi everyone,

I wonder if anyone can point me to a good discussion of the tagging infrastructure? I'm particularly interested in changing colours, adding a symbol (like the 'Done' tick) and I was also wonder if hierarchies are possible? Is all this available through the Browser Interface or are these command-line via node.js? 

Finally, I wonder if there is any work under-way on tag semantics - so that creating a tag of 'Fred Bloggs' can have semantics of 'Work Colleague' associated with it when tagging say 'Jane Right'. So it is creating n-triples (sort of) similar to N3 http://en.wikipedia.org/wiki/Notation3 ?

Cheers  

[PMario]

Hi Simon,
Are you talking about TiddlyWiki-classic [1] or TW5[2]?
-m

[1] http://tiddlywiki.com
[2] http://five.tiddlywiki.com

[Simon Harper]

Hi, I'm using TW5 at present.

Cheers

[PMario]

On Friday, August 16, 2013 8:27:47 PM UTC+2, Simon Harper wrote:

I wonder if anyone can point me to a good discussion of the tagging infrastructure? I'm particularly interested in changing colours, adding a symbol (like the 'Done' tick)

If you open the "Done" tiddler, which can be used as a tag, you can open the "(i)nfo" button. There is a tab "Fields". You'll see the field name: "color" ... This one defines the color of a tiddler.

Have a look at: "TiddlerFields" tiddler

There isn't much more info atm (at least I don't know it :) -> Jeremy ??
 

and I was also wonder if hierarchies are possible?

Tag hierarchies are possible but you need to do them "by hand". With TWc there was a "NewHere" button, that created a new tiddler tagged with the "parent" tiddler that created it. ...
 

Is all this available through the Browser Interface or are these command-line via node.js? 

The whole system works as a single page application in the browser.

node.js is there as a "development and testing system".
 

Finally, I wonder if there is any work under-way on tag semantics - so that creating a tag of 'Fred Bloggs' can have semantics of 'Work Colleague' associated with it when tagging say 'Jane Right'. So it is creating n-triples (sort of) similar to N3 http://en.wikipedia.org/wiki/Notation3 ?

 Jeremy can you jump in here?

have fun!
mario

[Jeremy Ruston]

Hi Simon

 

I wonder if anyone can point me to a good discussion of the tagging infrastructure? I'm particularly interested in changing colours, adding a symbol (like the 'Done' tick) and I was also wonder if hierarchies are possible? Is all this available through the Browser Interface or are these command-line via node.js? 

TiddlyWiki5's data model is very simple: a wiki consists of a bag of tiddlers, each of which consists of a bundle of name:value pairs called fields. The field "title" is used as the title of a tiddler, and "text" is the body text.

To set a color for a tiddler, add a "color" field set to a CSS color value (eg "#fef", or "red")

To set an icon for a tiddler, add an "icon" field set to the title of an image tiddler

The "tags" field is a list of tiddler titles that are acting as tags. Hierarchies can be constructed by applying tags to other tags.

As Mario suggests, have a look at the TiddlerFields tiddler for a summary of the default fields used with TiddlyWiki.

All of this is available both in the browser and under node.js.

Finally, I wonder if there is any work under-way on tag semantics - so that creating a tag of 'Fred Bloggs' can have semantics of 'Work Colleague' associated with it when tagging say 'Jane Right'. So it is creating n-triples (sort of) similar to N3 http://en.wikipedia.org/wiki/Notation3 ?

Do you mean being able to tag the tiddler "FredBloggs" with a compound tag like "WorkColleague:JaneRight"? If so, no, tags are (currently) single valued relationships.

Best wishes

Jeremy 

Cheers  

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/groups/opt_out.

--
Jeremy Ruston
mailto:jeremy...@gmail.com

[Simon Harper]

Hi Mario,

thanks for this - really useful!

Cheers

Si

[Simon Harper]

Thanks Jeremy!

I'm going to have a look at the code for the tagging to see how much work it would be to modify the tags to accept dual 'fields' of relationship and context.

Cheers

Si

[Tobias Beer]

Hi Jeremy,

> Finally, I wonder if there is any work under-way on tag semantics - so that creating a tag of 'Fred Bloggs' can have semantics of 'Work Colleague' associated with it when tagging say 'Jane Right'. So it is creating n-triples (sort of) similar to N3 http://en.wikipedia.org/wiki/Notation3 ?

This is an idea I am sure I have been trying to communicate a while back, too.

Semantically it is quite relevant to be a able to qualify a tag (not just in terms of polymorphism). It's a bit like a "compound tag", one that is actually two or more, yet somehow TW would know that the parts are semantic entities by themselves, too.

A bit in the direction of what NameSpacePlugin does, I guess, only just in terms of tagging, rather than tiddler titles.
http://namespace.tiddlyspace.com

For example, John could be the son of Jack. So instead of merely tagging John with [[Jack]], it would semantically be more meaningful to have a qualifier that allows to specify this tagging relation as...

John <tagged> [[Jack]](is parent)

...and then later be able to leverage a qualifier like this further down the road. Ideally, [[is parent]] would as well, optionally, be a tiddler explaining the qualifier and how to use it.

A tag could perhaps have multiple qualifiers, e.g.

[[tag]](qualifier1|qualifier2)

Qualifiers couls be semantic relations in the form of...

* has value

* is assiged to

* is child of

* is dependency for
* is created by

* is initiated by

* is located at

* is owned by

* is part of
* etc...

It could even make sense to standardise the most vital of these semantic qualifiers in the core to have people adopt consistent use cases... makes communication a whole lot easier.

Cheers, Tobias.

[Tobias Beer]

Addendum,

As for semantics, somewhat relevant may be...
http://semantic.tiddlyspace.com

Also, there could at some point be a UI that allows to define a "semantic tag" by chosing the tag target from a given set, e.g. by TW knowing that potential "parents" are [[John]] and [[Jane]] and then offering them first for tagging in terms of a "child of" tagging relation... all other tiddlers being listed subsequently.

For example, if the semantic qualifier [[parent]] were a tiddler and all members of it would tag to it, then it would be easy for TW to figure out the existing options, e.g.

* semantic qualifier = [[parent]]
* [[Jane]], [[John]] <tag to> [[parent]]

I want to define the a semantic tag for [[Billy]] in terms of assigning both [[Jane]](parent) [[John]](parent).

Eventually [[Jane]] could also tag to a generic [[mother]] and John to a generic [[father]] if one wanted so and then assign Billy as follows:

* [[Billy]] <tagged> [[Jane]](mother) [[John]](father)

There could even fancy stuff like custom css, e.g. color coding for a given semantic qualifier, e.g. male blue and femal pink, as we all know. ^_^

Cheers, Tobias.

[Jeremy Ruston]

Hi Tobias

That's a good summary of how qualified tagging could work. I'm not sure about the best syntax, the simpler tag:qualifier still seems attractive

A somewhat similar effect can be achieved at the moment with TW5 by putting each qualifier in a separate field. For example:

{title: "John", qualifier-parents: ["Jack"], qualifier-next-of-kin: ["Jack", "Jill"], text: "..."}

In effect, each of the qualifier-xxx fields is a separate "tags" field with an implied qualifier.

Best wishes

Jeremy

[PMario]

On Tuesday, August 20, 2013 10:01:09 AM UTC+2, Jeremy Ruston wrote:

A somewhat similar effect can be achieved at the moment with TW5 by putting each qualifier in a separate field. For example:

{title: "John", qualifier-parents: ["Jack"], qualifier-next-of-kin: ["Jack", "Jill"], text: "..."}

In effect, each of the qualifier-xxx fields is a separate "tags" field with an implied qualifier.

I like the idea, of exposing custom fields to the user. With TWc we saw, that the only "field" that could be easily used was the tags field.  To work with other custom fields, you had to go the "programmers route" which is to cumbersome for most users.

On the other hand, I think accessing parts of the "tiddler.text" should be easier than working with custom fields, since they are hidden behind the (i)nfo button. The text is always visible. I'm talking about "sections" and "slices" but I don't want to hijack this thread, that's why I did create a new one about sections and slices [1]

have fun!
mario
[1] https://groups.google.com/forum/?fromgroups#!topic/tiddlywiki/-NuEwuqjUCs

[Tobias Beer]

Hi Jeremy,

Yes, sure, fields have always been possible for such use, also in classic TW.

The power of such semantics would however lie in how it would provide a standard for semantic modeling, something that isn't intrinsically clear with fields, e.g. basic methods that allow to leverage the power of such qualified tags, in fact, even "tag fields" or "tag slices" that work equivalently.

Now what do I mean by that?

Obvious, the first and most simple usecase were to make use of it in the list macro, e.g. something like...

<<list [tag[task]] [by[owner]]>>
<<list [by[parent]]>>

Which could result in a grouped output of tasks by owner or children by parents.

Another example would be some sort of list query, e.g...

<<list [tag[task]] [where[owner=John]]>>
<<list [where[parent=John]]>>

And further tools that would allow to change semantic tags between equivalent members of a qualified set, e.g.

Change [[John]](owner) to [[Jane]](owner)... while constraining the *initially* available options to all those that are...

-- either explicitly tagged as [[owner]]
-- or implicitly already used as [[Jane]](owner) or [[John]](owner) throughout the wiki

...but, of course, also giving a generic selection that would hence turn any other tiddler into a semantically qualified "owner", explicitly or implicitly.

These were a few quick examples of the top of my head of how working with such semantic qualifiers would signitficantly enhance modeling abilities and most importantly, reveal implicit relationships for programatic exploration that don't require the code to know that a "parents" field actually defines a relationship.

So, the overall reason for enhancing tags this way would be that tags today are, perhaps for good reasons, too dumb.

~

However, of course, this could definetely be modeled via fields as well. An approach might be to turn a generic field into "semantic field", i.e. one defining a relationship at any tiddler in terms of a bracketedList ...upon which to build further functionality.

This could somewhat easilby be achieved by having a SemanticFieldList tiddler or setting which defines all fields that are to be interpreted as both semantic qualifiers and tiddlers and, most importantly, would yield in *displaying* the field and it's information equally as prominent as tags.

For example, if I defined [[SemanticFieldList]] as a simple breacketedList of...

[[parent]]
[[owner]]

Then UI would then automatically...
* display such semantic data values at given tiddler more prominently in a "semantic fields" block
* make the semantic field names clickable, linking to tiddlers that detail their function
* provide standard lists below such semantic field-tiddlers with qualified members
* allow for managing the values of semantic relations in the way described before
* correct any existing semantic relations upon changing tiddler names (!)

Come to think of it, the field-approach seems a lot more elegant and extensible than perhaps to enhance tags. All in all, the goal would be to make establishing and managing semantic relations much easier than it is today in terms of general methods to introspect and change such relations.

Perhaps such a [[SemanticFieldList]] tiddler should rather be in the form of (pseudo) JSON, e.g...

parent : {

max: 2,
info: "a parent of a person"

}

member : {

info: "a member to a group"

}

owner : {
max: 1,

info: "the owner of a task"
for: [tag[task]]
selection: [tag[member]]

}

date-of-birth: {
type: date
}

In this way, the capabilities could be enhanced little by little, e.g. looking at the above owner definition the UI (or field validation) would only allow one owner to any tiddler, display the info "the owner of a task" as a tooltip or otherwise to that smenatic field being displayed, would perhaps only display this field as a semantic field *for* tiddlers tagged [[task]] and only allow those tiddlers for selection as owners that are tagged [[member]].

All of this starts to very much resemble something I had been pondering a while back yet never got to it...
http://xfieldsdev.tiddlyspace.com

Cheers, Tobias.

[Tobias Beer]

Hi Mario,

As I said in my last reply, if qualified as "semantic fields" these fields would *not be* hard to access but rather have a simple access & management ui to them, e.g. a "semantic fields" block actually showing type-dependent edit controls, e.g. searchbox for bracketed lists, checkbox for boolean, date-picker for dates, etc... either in edit mode or even in view-mode, e.g. as a kind of "inline editing" (step 2).

I am no fan of having semantic data within the tiddler body, unless relevant to the actual context. Why? Because it makes it so much harder to programatically do anything with your document and surely makes the processing power needed magnitudes larger. So, hidden sections or slices seem much less appealing for me, especially as it would be genuinely hard to create any enhanced ui around (hidden) in-text information.

Cheers, Tobias.

[PMario]

On Tuesday, August 20, 2013 12:05:33 PM UTC+2, Tobias Beer wrote:

I am no fan of having semantic data within the tiddler body, unless relevant to the actual context. Why? Because it makes it so much harder to programatically do anything with your document and surely makes the processing power needed magnitudes larger. So, hidden sections or slices seem much less appealing for me, especially as it would be genuinely hard to create any enhanced ui around (hidden) in-text information.

I'm not talking about _hidden_ sections and slices. Many TW documents / tiddlers create an "intrinsic structure" after some time of refactoring, that is part of the tiddler content. eg: http://geneology.tiddlyspot.com/
or
http://www.strm.us/tw/cigars: If you click "New cigar" you'll see it. This structure is created by the user, not the programmer and users should be able to create this stuff. (with the help of some plugins, done by programmers :)

-m

[Tobias Beer]

Hi Mario,

Sure, we all understand the basic need, I believe. ^_^

However, the differences arise when it comes to finding the most meaningful basic implementation.

I believe the disadvantages to doing this in the tiddler body are enormous, not only because it makes it sooo much harder to change things later on / programatically but also in terms of being consistent and not accidentally changing things.

To have consistent "enhanced" fields seems much more manageable.

So, what you would define instead of a tiddler template were a number of SemanticBlockViewTemplate / SemanticBlockEditTemplate conditionally displayed when a tiddler matches a filter criteria, e.g. "is tagged xyz". Those templates would define which fields to display and where.

However, these templates would only define the contents of the semantic block, *not* the entire View- or EditTemplate! Instead, the View- or EditTemplate would only define a placeholder for where to render semantic blocks, perhaps with attributes that allow to define the order in which to render them, if needed, i.e. for tiddlers that match the criteria of more than one semantic block.

You could even skip *all* those extra templates and have the core render a generic semantic fields block depending on any semantic fields defined in some [[SemanticFieldsList]] or [[SemanticFieldsConfig]].

Cheers, Tobias.

[Simon HARPER]

Yes this makes sense - I'd probably have just one type of semantic
relationship to start with - and if these semantic-tags worked in a
similar way to current tags you could also add a field called
'reciprocal' so that in the case of is-parent the reciprocal could be
is-child with the concept changing based on which side of the
relationship was being investigated.


John <tagged> [[Jack]](is parent) would therefore automatically imply

Jack <tagged> [[John]](is child)

On 20/08/2013 02:55, Tobias Beer wrote:
> Hi Jeremy,
>
> > Finally, I wonder if there is any work under-way on tag semantics -
> so that creating a tag of 'Fred Bloggs' can have semantics of 'Work
> Colleague' associated with it when tagging say 'Jane Right'. So it is
> creating n-triples (sort of) similar to
> N3 http://en.wikipedia.org/wiki/Notation3
> <http://en.wikipedia.org/wiki/Notation3> ?
>
> This is an idea I am sure I have been trying to communicate a while
> back, too.
>
> Semantically it is quite relevant to be a able to qualify a tag (not
> just in terms of polymorphism). It's a bit like a "compound tag", one
> that is actually two or more, yet somehow TW would know that the parts
> are semantic entities by themselves, too.
>
> A bit in the direction of what NameSpacePlugin does, I guess, only
> just in terms of tagging, rather than tiddler titles.

> http://namespace.tiddlyspace.com <http://namespace.tiddlyspace.com/>

>
> For example, John could be the son of Jack. So instead of merely
> tagging John with [[Jack]], it would semantically be more meaningful
> to have a qualifier that allows to specify this tagging relation as...
>
> John <tagged> [[Jack]](is parent)
>
> ...and then later be able to leverage a qualifier like this further
> down the road. Ideally, [[is parent]] would as well, optionally, be a
> tiddler explaining the qualifier and how to use it.
>
> A tag could perhaps have multiple qualifiers, e.g.
>
> [[tag]](qualifier1|qualifier2)
>
> Qualifiers couls be semantic relations in the form of...
>
> * has value
> * is assiged to
> * is child of
> * is dependency for
> * is created by
> * is initiated by
> * is located at
> * is owned by
> * is part of
> * etc...
>
> It could even make sense to standardise the most vital of these
> semantic qualifiers in the core to have people adopt consistent use
> cases... makes communication a whole lot easier.
>
> Cheers, Tobias.

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "TiddlyWiki" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/tiddlywiki/MJFg7qGxzzI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> tiddlywiki+...@googlegroups.com.
> To post to this group, send email to tiddl...@googlegroups.com.
> Visit this group at http://groups.google.com/group/tiddlywiki.
> For more options, visit https://groups.google.com/groups/opt_out.

--

Si.

PS I check my email at 08:00 and 17:00 GMT. If you require a faster
response please include the word 'fast' in the subject line.

------------------------------------------------------------------------

*I'll be away*:

Vacation No Comms 21 Sept 2013 to 29 Sept 2013
ACM SGB Limited Comms 30 Sept 2013 to 05 Oct 2013
ACM ASSETS Limited Comms 21 Oct 2013 to 25 Oct 2013

------------------------------------------------------------------------

Simon Harper
My Business Card <http://simon.harper.name/about/card/>
Schedule a Meeting <http://doodle.com/simon.harper.name>
OpenID <https://sharpic.myopenid.com/>

University of Manchester (UK)
Web Ergonomics Lab <http://wel.cs.manchester.ac.uk>
Information Management Group

------------------------------------------------------------------------
Find me on:

* OpenID (sharpic) <https://sharpic.myopenid.com/>
* Bitbucket (sharpic) <https://bitbucket.org/sharpic>
* GitHub (sharpic) <https://github.com/sharpic>