[tw] [TW5] Fields versus Tags ? (now and tomorrow)

[Jean-Charles]

I'd like to know if some of you have "good practices" regarding their use
of *tags *and *fields*.

My current perception is that *tags *are very simple to use, accessible,
searchable, customizable, and used by several extensions. That is a lot,
and they are definitely worth using. However, I'm afraid that after a
while, they are too much of them to make a personal tiddlywiki
maintainable. Think about journal entries using tags to refer to tiddlers,
etc...
On the other hand, *fields *are neat but somewhat more hidden to the user.
They are also used by TW5 internally, so there is a risk of collision as
there is not such *$field* convention like the one used on tiddler naming.
But they convey more information as they provide both a type/property and
its value. However, they seem to be less integrated (no field-based TOC, no
field backlinks, etc)

I have two use-cases in mind, and the choice may apply to both :

- "project" field/tag. What I call "project" is very broad, and I have
up to 30 or 40 to manage/follow. So basically I can use a tag per project,
and tag these tags with a "project" tag to avoid a complete mess. As
projects come and go, I'll probably have lots of them after a while. A
little bit scary in my opinion.
- "organization" field/tag. I'd like to put all my contacts in TW5, and
they all belong to one or more organization. Having tiddlers for each and
every organization is ok, but having tags for each and every of them may
end up having tons of them after a while. I'd prefer to use fields for each
contact that refers to their organization(s)

Maybe I'm reluctant because I'm ignorant of some practices or ways to
organize TW5 tiddlers. Maybe having hundreds of tags is by no way an issue.
But working with open "properties/fields" is something really great to
organize stuff, so I tend to stick on this schema (I am a semantic
mediawiki, for example).

So, to sum it up :

1. Do you have any experience regarding tags vs. fields TW5 organization
? What were your conclusions ?
2. Is hundred of tags maintainable, and are their some tricks to make
this easy ?
3. What are fields' future ? Is there a will to make them more
important/usable or not ?

Thank you for your feedbacks.

[Tobias Beer]

Hi Jean ,

"project" field/tag. What I call "project" is very broad, and I have up to

30 or 40 to manage/follow. So basically I can use a tag per project, and
tag these tags with a "project" tag to avoid a complete mess. As projects
come and go, I'll probably have lots of them after a while. A little bit
scary in my opinion.

Projects sure are high-level tiddler candidates! Here's how I would manage
those...

Tag: *Projects* ...with project status tags tagging to it, e.g. *$active*,
*$someday*, *$**maybe*, *$finished* and then actual projects tagging to
those project status tags.

In tbGTD <http://tbgtd.tiddlyspot.com> there are equivalent task- or
action-status tags, e.g. *#next*, *#waiting*, *#future*, *#done* tagging to
a tiddler called *Actions* and then your actual "action tiddlers" tagging
to those action-status-tags.

"organization" field/tag. I'd like to put all my contacts in TW5, and they

all belong to one or more organization. Having tiddlers for each and every
organization is ok, but having tags for each and every of them may end up
having tons of them after a while. I'd prefer to use fields for each
contact that refers to their organization(s)

Organisations or *Networks* sure are prominent tiddler candidates!

I am thinking that especially with a lot of orgs you will definitely have
network information on top of contact information. You could apply the same
prefix style, e.g. having a tag *Networks*, with network types tagging to
it, e.g. *&Partner*, *&Supplier*, *&Customer*, etc... and then different
organisations tagging to those network types. This will allow you to easily
list orgs by different types, even contacts with a given "contact-role" for
orgs of a given type. Again, I would make "contact-roles" tiddlers, because
a single contact can assume more than one role. Of course, you could just
as well use a select-box at organisation-tiddlers so as to select a
network-type... but then you could not have an organisation that is both a
*&Partner* and *&Supplier*... unless you had one "checkbox-field" per
network-type... assuming that we'll have checkbox fields at some point.

Maybe I'm reluctant because I'm ignorant of some practices or ways to

organize TW5 tiddlers. Maybe having hundreds of tags is by no way an issue.

I don't think it is an issue, to the contrary. For example, it makes search
much easier. For example, try searching $, #, & ...catch my drift?

Do you have any experience regarding tags vs. fields TW5 organization ?

What were your conclusions ?

As you said yourself, tags are a lot more accessible (now)... which is
something that necessarily needs to be that way, as you can add your own custom
viewtemplate sections
<http://tb5.tiddlyspot.com/#Conditional%20ViewTemplate%20Section>
displaying dedicated field-information depending on filter criteria.

Is hundred of tags maintainable, and are their some tricks to make this

easy ?

Why wouldn't it be? To me, the trick is to use a smart tagging-hierarchy as
indicated above.

What are fields' future ? Is there a will to make them more

important/usable or not ?

Just as I hoped they would be in TWc, I hope they will become *much*
smarter in TW5. I would like to see typed fields
<https://developer.salesforce.com/page/An_Introduction_to_Force_Database>,
e.g. string, number, check, select, radio... etc... as well as an ability
to define fieldsets that you can associate with filter expressions
corresponding to the tiddlers for which you wish to display a given field
or fieldset.

Best wishes, Tobias.

[Jean-Charles]

Hi Tobias,

Thanks for your feedback.

Post by Tobias Beer
I don't think it is an issue, to the contrary. For example, it makes
search much easier. For example, try searching $, #, & ...catch my drift?

Ok, I got your point. Isn't this approach a kind of shortcut for hidden
properties or fields ? "&Supplier" standing for "networkCategory=Supplier",
"$" for "projectStatus", "#" for "taskStatus", etc. They seem to be
semantically equivalent, with the advantage of using all the tag features.
I'll give this way of organizing a try.

Post by Tobias Beer
What are fields' future ? Is there a will to make them more

Post by Jean-Charles
important/usable or not ?

Just as I hoped they would be in TWc, I hope they will become *much*
smarter in TW5. I would like to see typed fields
<https://developer.salesforce.com/page/An_Introduction_to_Force_Database>,
e.g. string, number, check, select, radio... etc... as well as an ability
to define fieldsets that you can associate with filter expressions
corresponding to the tiddlers for which you wish to display a given field
or fieldset.

Sounds promising :-)

[Alberto Molina]

Hi Jean Charles,

- Do you have any experience regarding tags vs. fields TW5
organization ? What were your conclusions ?
I started creating structured wikis like [1] with tags, because they are

much easier to manage. But I found at least two annoying problems.

1. Too much tags! When in view mode you end up with more than 10 tags,
some of them being "system tags", it is no more useful.
2. Tags have no semantic meaning, or they all share the same meaning. I
needed tags to categorize, others meaning "written by", or "about", or
"related to", etc., and you cannot do that with tags. For instance, if you
have a tiddler for a book, and you tag it "William Shakespeare", it could
mean that it is written by him, or that it talks about him, or it's related
to him, etc.

Fields are hidden from view, which could be a good thing, but its more work
if you want to display their content. On the one side, fields are perfect
to give different meanings or purposes for the information. On the other
side, they are worse to work with, specially if you want list fields.

- Is hundred of tags maintainable, and are their some tricks to make
this easy ?

You can hide these special tags from view, changing
$:/core/ui/ViewTemplate/tags

- What are fields' future ? Is there a will to make them more
important/usable or not ?
I hope so, but I don't know.

Regards,
Alberto

[1] wikiphilo.tiddlyspot.com

[Jeremy Ruston]

Hi Jean-Charles

Post by Tobias Beer
Do you have any experience regarding tags vs. fields TW5 organization ?

What were your conclusions ?

It's worth remembering that tags are just a special type of field, so it's
not really the dichotomy that it first appears.

Post by Tobias Beer
Is hundred of tags maintainable, and are their some tricks to make this

easy ?

I think the core needs some improvements to cope better with large amounts
of tags. For example, to reduce clutter it would be useful to be able to
"blacklist" certain tags so that they are only listed in edit mode. But
these changes are the sort of thing that it's easy to experiment with
without waiting for the core.

Post by Tobias Beer
What are fields' future ? Is there a will to make them more

important/usable or not ?

Fields are an integral part of the TW data model and so they are not going
anywhere. I would expect future improvements to make them more useful.

Best wishes

Jeremy

Post by Tobias Beer
Hi Jean Charles,

- Do you have any experience regarding tags vs. fields TW5
organization ? What were your conclusions ?
I started creating structured wikis like [1] with tags, because they are

much easier to manage. But I found at least two annoying problems.
1. Too much tags! When in view mode you end up with more than 10 tags,
some of them being "system tags", it is no more useful.
2. Tags have no semantic meaning, or they all share the same meaning.
I needed tags to categorize, others meaning "written by", or "about", or
"related to", etc., and you cannot do that with tags. For instance, if you
have a tiddler for a book, and you tag it "William Shakespeare", it could
mean that it is written by him, or that it talks about him, or it's related
to him, etc.
Fields are hidden from view, which could be a good thing, but its more
work if you want to display their content. On the one side, fields are
perfect to give different meanings or purposes for the information. On the
other side, they are worse to work with, specially if you want list fields.

- Is hundred of tags maintainable, and are their some tricks to make
this easy ?

You can hide these special tags from view, changing
$:/core/ui/ViewTemplate/tags

- What are fields' future ? Is there a will to make them more
important/usable or not ?
I hope so, but I don't know.

Regards,
Alberto
[1] wikiphilo.tiddlyspot.com
--
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
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

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

[Tobias Beer]

Hi Alberto,

Post by Alberto Molina
Tags have no semantic meaning, or they all share the same meaning. I
needed tags to categorize, others meaning "written by", or "about", or
"related to", etc., and you cannot do that with tags. For instance, if you
have a tiddler for a book, and you tag it "William Shakespeare", it could
mean that it is written by him, or that it talks about him, or it's related
to him, etc.

That is something I have pondered about for a long time. A simple tag (aka
keyword) simply is not good enough for so many usecases. Instead, what you
want is a qualified tag that expresses both something to relate to AND the
type of relation, encoded in one "semantic" tagging relation, that could be
expressed by something like "my tag++relation y"... whereas the ui would
actually allow you to explore this relation in a number of ways, e.g.

1. all with *tag* AND *relation*
2. all only with *tag*
3. all only with *relation*

...and allow for a wide range of more fine-grained queries against a
tiddler store. So, perhaps, it's time to introduce a new layer of
connecting tidbits, aka "relations"... and to seprate them, if not
eventually mingle them with tags in the above tag++relation type of manner.
Of course, just as tags are first class citizens, so should relations be.

Best wishes, Tobias.

[Mat]

Fields vs Tags - in deed! I suffer from exactly the prolems descried here.
Things did improve slightly with TW5s superior field handling over TWCs
but, still, there is a need to both have the smoothness and visibility of
tags but the "typing" of fields.

Here is a conceptual mockup that I'd like your input on (please, open
image).

The idea is to have

- a "public/viewable" part where currently the tags field is
- ...and a "admin/editview" part at tiddler footer, which actually is
how the current fields part already functions.

Now, in the "public/viewable" part, I propose to display *both* tags and
fields, possibly grouped (more on this below). *In practice, a field will
be treated like a tag with a type (type:tag = name:value). *

The rough workflow illustrated in the mockup goes:

1) (omitted from mockup) Just like today, in edit mode and in the tags
area, you start typing into a small edit box.
1b) (left side of mockup) Immediately this opens the (familiar) tags
suggestion list but the edit box you're filling in moved down a line and
above it now a tag pill is building up. If you're happy with a quick tag,
then you click the tick and it's created. Done. Very similar to how it
works today.

2) ...but if you want to type it or fine tune a bit, you'll notice the
dropdown list has two buttons for *type* and *settings*. See right image in
mockup.
The "type" side has another small edit box where you fill in the type. You
also get a suggestion list, equivalent to the tags suggestion list.
The resulting tag pill adjusts as you type.

3) The right hand *settings* menu should be pretty obvious, but the top
item, "Type" + eye, refers to if the type should be visible in the tag pill
or not, i.e if the tag pill should read "author:Patrick Modiano" or just
"Patrick Modiano".

4) Programmatically: Not until you actually click the tick ("Done") for the
pill is this actually created. Only then is it decided if this tag pill
really is a tag or if it is a field (i.e on the form name:value).
Regardless, there is a resulting pill - possibly with these typed variants
grouped first or last in the "tag area".
Tiddler in view mode looks the same of course.


<Loading Image...>


I'm leaving out my thoughts on the tiddler footer fields as they're pretty
much intact functionality wise. And I have some thoughts on algorithms for
the suggestion lists. More later, if of interest.


Other than the actual practical value this would have, I also think it
simplifies things conceptually for new users. You use simple tags until you
get sophisticated enough to need typed tags at which time it's a small step
to take. In their mind, it's probably still just "doing something to the
tag" kind of like the color setting - as opposed to bringing in a new term
and concept (fields) which seems to be something advanced and something
used by "the system".


<:-)

[Mat]

So, referrring to my post above and the image, what do you say - would it
work or is there some fundamental problem?

In a way it is merely about having some fields visible in view mode.

My major concern is if is possible to use such a field as a
tiddlertitlelink in the way tag names are? I.e can "foo:bar" or "bar" (i.e
"foo" hidden) linkified and still work as a field? Maybe it only has to be
linkified at the moment it is displayed?

...An interesting question is then what would happen when you click it? My
thoughts are that you open a tiddler titled *bar*, i.e not with the type
visible in the title... and the type is stored as... you guessed it... a
regular field. Perhaps "tagtype:foo". Actually not strange - it's simply
a field with the meta-data stating that when the tiddlertitle is used as a
tag, it is of type "foo".

Anothe question: is the idea possible with the two placehoders to fill in
and have the system decide upon clicking the tick/Add, if it is to be a tag
or a field, i.e based on if one or both placeholders were filled?

BTW, what would happen if one simply ditched the special tags field and
only used general fields but with a default value "tag" for whenever no
other name/attribute was specified.?


<:-)

Post by Mat
Fields vs Tags - in deed! I suffer from exactly the prolems descried here.
Things did improve slightly with TW5s superior field handling over TWCs
but, still, there is a need to both have the smoothness and visibility of
tags but the "typing" of fields.
Here is a conceptual mockup that I'd like your input on (please, open
image).
The idea is to have
- a "public/viewable" part where currently the tags field is
- ...and a "admin/editview" part at tiddler footer, which actually is
how the current fields part already functions.
Now, in the "public/viewable" part, I propose to display *both* tags and
fields, possibly grouped (more on this below). *In practice, a field will
be treated like a tag with a type (type:tag = name:value). *
1) (omitted from mockup) Just like today, in edit mode and in the tags
area, you start typing into a small edit box.
1b) (left side of mockup) Immediately this opens the (familiar) tags
suggestion list but the edit box you're filling in moved down a line and
above it now a tag pill is building up. If you're happy with a quick tag,
then you click the tick and it's created. Done. Very similar to how it
works today.
2) ...but if you want to type it or fine tune a bit, you'll notice the
dropdown list has two buttons for *type* and *settings*. See right image
in mockup.
The "type" side has another small edit box where you fill in the type. You
also get a suggestion list, equivalent to the tags suggestion list.
The resulting tag pill adjusts as you type.
3) The right hand *settings* menu should be pretty obvious, but the top
item, "Type" + eye, refers to if the type should be visible in the tag pill
or not, i.e if the tag pill should read "author:Patrick Modiano" or just
"Patrick Modiano".
4) Programmatically: Not until you actually click the tick ("Done") for
the pill is this actually created. Only then is it decided if this tag pill
really is a tag or if it is a field (i.e on the form name:value).
Regardless, there is a resulting pill - possibly with these typed variants
grouped first or last in the "tag area".
Tiddler in view mode looks the same of course.
<https://lh3.googleusercontent.com/-JsiCUOASAcM/VJzHvEFW38I/AAAAAAAAPCs/caKR5yhyVto/s1600/tagfields_both.png>
I'm leaving out my thoughts on the tiddler footer fields as they're pretty
much intact functionality wise. And I have some thoughts on algorithms for
the suggestion lists. More later, if of interest.
Other than the actual practical value this would have, I also think it
simplifies things conceptually for new users. You use simple tags until you
get sophisticated enough to need typed tags at which time it's a small step
to take. In their mind, it's probably still just "doing something to the
tag" kind of like the color setting - as opposed to bringing in a new term
and concept (fields) which seems to be something advanced and something
used by "the system".
<:-)

[Mat]

So, referrring to my post above and the image, what do you say - would it
work or is there some fundamental problem?

In a way it is merely about having some fields visible in view mode.

My major concern is if is possible to use such a field as a
tiddlertitlelink in the way tag names are? I.e can "foo:bar" or "bar" (i.e
"foo" hidden) linkified and still work as a field? Maybe it only has to be
linkified at the moment it is displayed?

...An interesting question is then what would happen when you click it? My
thoughts are that you open a tiddler titled *bar*, i.e not with the type
visible in the title... and the type is stored as... you guessed it... a
regular field. Perhaps "tagtype:foo". Actually not strange - it's simply
a field with the meta-data stating that when the tiddlertitle is used as a
tag, it is of type "foo".

Anothe question: is the idea possible with the two placehoders to fill in
and have the system decide upon clicking the tick/Add, if it is to be a tag
or a field, i.e based on if one or both placeholders were filled?

BTW, what would happen if one simply ditched the special tags field and
only used general fields but with a default value "tag" for whenever no
other name/attribute was specified.?


<:-)