Metadata vs. DataTiddlerPlugin
DigitalOrganics
TW2.1 and what Udo implements w/ data fields in his DataTiddlerPlugin?
DigitalOrganics
(or any other kind of "metadata") on a per tiddler basis and then,
using forEachTiddler, construct lists and take various actions based on
this info.
Jeremy Ruston
> > TW2.1 and what Udo implements w/ data fields in his DataTiddlerPlugin?
Extensible metadata refers to the data that's wrapped around a
tiddler, like the modified date, the name of the last modifier, and
the tags. This metadata doesn't form part of the text of the tiddler,
but rather is edittable via special controls. So the goal of EMD is to
be able to add additional fields to tiddlers that are transparent to
normal use of the tiddler. The classic example might be fields to
contain the name of the parent tiddler and the next and previous
sibling tiddlers.
Udo's DataTiddler allows subsections of a tiddler to be referenced in
isolation; in other words it gives an API to data *within* a tiddler,
rather than to the metadata.
By the way, 2.1 will also have a feature I've been called 'embedded
fields' which is in effect a very simplified version of Udo's
DataTiddler.
> Any comments? With Udo's plugin, I can store relationship information
> (or any other kind of "metadata") on a per tiddler basis and then,
> using forEachTiddler, construct lists and take various actions based on
> this info.
You can indeed, but it's not metadata in the conventional sense
because your additional fields will be part of the main body of the
item.
Cheers
Jeremy.
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
DigitalOrganics
Udo Borkowski
My "PartTiddler" plugin (http://tiddlywiki.abego-software.de/#PartTiddlerPlugin), not the "DataTiddler" plugin, allows subsections of a tiddler to be referenced in isolation and handled as if they were separate tiddlers.
The "DataTiddler" plugin (http://tiddlywiki.abego-software.de/#DataTiddlerPlugin) allows you to store any kind of JavaScript objects (such as strings, booleans, numbers, or even arrays and compound objects) within individual tiddlers. This data can be easily accessed and modified through named fields (in JavaScript code). (Internally JSON is used for that purpose)
Both plugins store their information in the tiddler text, the DataTiddler in a hidden form and the PartTiddler either hidden or visible.
Back to the original question: what is the difference between DataTiddler and MetaData:
* MetaData will only contain String data (as currently planned for the first version), DataTiddler can hold nearly any kind of JavaScript object.
* The data is stored either in the Tiddler text (for DataTiddler) or separately from the text (for MetaData).
I assume it is very easy to port code that is using the DataTiddler plugin to use the MetaData feature (if only Strings are used as data). Also the use in the forEachTiddler macro requires very little changes.
Udo
michaelg
Nice app, from my initial look. I'm still exploring it's usefulness but
it looks promising.
For my question:
>>metadata ... will be implemented in TW2.1
Will the user be able to define what the tags are? I'd like to be able
to enter metadata to control the sequence of a report. Ideally to have
any number of logic threads, with tiddlers assigned a precedance in a
thread. Then a separate tag that would sequence strings of tiddlers to
their places in the overall narrative. Does this sound feasible?
One further refinement, for historical narratives, would be to assign
dates any one tiddler and have that drive the sequencing (and flag
inconsitancies). Does this sound like a possible application for what
you're working on?
Cudos for all you've done to date.
michaelg
Jeremy Ruston
> to enter metadata to control the sequence of a report. Ideally to have
> any number of logic threads, with tiddlers assigned a precedance in a
> thread. Then a separate tag that would sequence strings of tiddlers to
> their places in the overall narrative. Does this sound feasible?
The metadata features are really an internal API to be used by
plugins, and won't have much of a user interface of their own. Your
scenario is eminently feasible, but it would still require some kind
of plugin to encapsulate the particular logic you need.
> One further refinement, for historical narratives, would be to assign
> dates any one tiddler and have that drive the sequencing (and flag
> inconsitancies). Does this sound like a possible application for what
> you're working on?
Yes, that would also be a perfectly reasonable application of metadata.
Cheers
Jeremy
Udo Borkowski
The metadata features are really an internal API to be used by plugins, and won't have much of a user interface of their own.
The idea is to extend the "edit" macro (and maybe the "view" macro). E.g. currently " <<edit title>> " is used to create a field to edit the "title" of a tiddler. In an extension you may use (e.g.)
<<edit field: RecNo>>"
to edit the "RecNo" metadata field.
Later you may refer to the value entered for RecNo in other macros. E.g. when using the ForEachTiddler macro (http://tiddlywiki.abego-software.de/ForEachTiddlerPlugin) you could get the tiddlers sorted by the RecNo using this call:
<<forEachTiddler
sortBy 'parseInt(store.getValue(tiddler, "RecNo"))'>>
Udo
----------
Udo Borkowski
http://www.abego-software.de
Jeremy Ruston
> provide a simple user interface for this.
Yup, this was the "not much" I meant :)
Don't you think that your example could just be <<edit RecNo>>,
though? The implication is that there would be a data dictionary being
consulted to figure out the type of the field.
Udo Borkowski
Don't you think that your example could just be <<edit RecNo>>, though?
I just wanted to make it more explicit that this edits a field since I had the idea that we may want to use the edit macro to edit even more stuff than "build in stuff" and metadata fields in the future. Using the "field" as an indicator makes it easier to extend this later. Also it helps to avoid name clashes. E.g. assume that we introduce a "versionNo" build-in attribute in a future version of the TiddlyWiki core. This will break all TWs that have already defined its own "versionNo" metadata field.
So I would prefer to keep this "field:" prefix.
Daniel Baird
Don't you think that your example could just be <<edit RecNo>>,
though?
Of cause this would be no big deal.
I just wanted to make it more explicit that this edits a field since I had the idea that we may want to use the edit macro to edit even more stuff than "build in stuff" and metadata fields in the future.
;D
--
Daniel Baird
http://danielbaird.com (TiddlyW;nks! :: Whiteboard Koala :: Blog :: Things That Suck)
Udo Borkowski
Or even <<editField RecNo>>, just to make it super simple.
Actually I prefer to put all this stuff in a single "edit" macro since I expect that the edit macro will cover some additional functionality in the future that may be shared by all kind of stuff that can be edited. Creating separate macros may make it harder to share this common code.
Just some ideas:
<<edit field:RecNo type:integer>>
creates a field that allows numeric input
<<edit field:SSN len:10>>
limits the field to 10 characters
<<edit field:pwd password:true>>
creates a "password" field for the data, i.e. the "*" are displayed instead of real chars.
...
BTW: as I write this I just got another idea what could be edited through the "edit" macro: options (as stored in the Cookies)
<<edit option:UserName>>
edit the UserName option
<<edit option:SliderOptionsPanel type:boolean>>
...
This parallels the already existing "option" macro. So it does not look like a real benefit, just more typing. But using this option it is now possible to refer to all the other (future) features of "edit": password-style, validation, size restriction, patterns, ....
Udo
Saq Imtiaz
The metadata features are really an internal API to be used by
plugins, and won't have much of a user interface of their own.Providing the API is the first step, but I actually also envision to provide a simple user interface for this.
The idea is to extend the "edit" macro (and maybe the "view" macro). E.g. currently " <<edit title>> " is used to create a field to edit the "title" of a tiddler. In an extension you may use (e.g.)
<<edit field: RecNo>>"
to edit the "RecNo" metadata field.
That sounds good Udo, but why stop there? I sort of assumed you would be adapting your FormTiddlerPlugin to work with metadata as well ;)
Saq
Saq Imtiaz
> > What's the difference between the metadata that will be implemented in
> > TW2.1 and what Udo implements w/ data fields in his DataTiddlerPlugin?
Extensible metadata refers to the data that's wrapped around a
tiddler, like the modified date, the name of the last modifier, and
the tags. This metadata doesn't form part of the text of the tiddler,
but rather is edittable via special controls. So the goal of EMD is to
be able to add additional fields to tiddlers that are transparent to
normal use of the tiddler. The classic example might be fields to
contain the name of the parent tiddler and the next and previous
sibling tiddlers.
This is slightly off-topic, and I do apologize for that, but I was wondering where we are with regards to the advent of EMD?
It's just that for some time, I've been putting off some of my TW projects in wait for EMD, as they'd be much more easily implemented with it. However, if the wait for EMD was long enough I'd just bite the bullet and go ahead and code them now, and then update later.
Now I do realize that you might be hesitant to commit to a deadline of any sort, and I respect that. So let's try this a different way. Do you have any idea as to how long we definitely wont see the EMD release? :)
So if you were to say 8 weeks for example, its not committing to anything with regards to when it will be ready. But it will allow us to decide whether we want to wait for it or code away. :)
I don't at all mean to come across as pushy or impatient, and I do apologize in advance if it might seem that way.
Cheers,
Saq
Jeremy Ruston
metadata. Development has now begun in earnest:
http://trac.tiddlywiki.org/tiddlywiki/timeline
Cheers
Jeremy
Udo Borkowski
I sort of assumed you would be adapting your FormTiddlerPlugin to work with metadata as well ;)
Udo
Saq Imtiaz
2.1 will be out in less than 8 weeks, complete with extensible
metadata. Development has now begun in earnest:
Great news, thanks Jeremy!
Cheers,
Saq
Saq Imtiaz
I sort of assumed you would be adapting your FormTiddlerPlugin to work with metadata as well ;)
That is planned. I assume I will release this soon after TW 2.1
I'm glad to hear that Udo. One suggestion while we are on this topic. It might be nice to have a read only mode for the FormTiddler Plugin, that only displays the EMD but doesn't allow editing.
Cheers,
Saq
Daniel Baird
Or even <<editField RecNo>>, just to make it super simple.No, that's too easy. ;-)
Actually I prefer to put all this stuff in a single "edit" macro since I expect that the edit macro will cover some additional functionality in the future that may be shared by all kind of stuff that can be edited. Creating separate macros may make it harder to share this common code.
One plugin can add several macros though, right? If there were a lot of <<edit field: fieldname>> and <<edit meta: fieldname>> and <<edit cookie: fieldname>> or whatever, I reckon it'd be nice to use editField, editMeta, and editCookie, even if they were just oneliners that coverted their calls into <<edit field: >> calls.
I guess I'm just thinking that the people who use the macros aren't always developers, sometimes they're non-coding power users. Seems a bit arbitrary to have some macros that need an extra word in the middle.
;D
Udo Borkowski
One plugin can add several macros though, right? If there were a lot of <<edit field: fieldname>> and <<edit meta: fieldname>> and <<edit cookie: fieldname>> or whatever, I reckon it'd be nice to use editField, editMeta, and editCookie, even if they were just oneliners that coverted their calls into <<edit field: >> calls.
I guess I'm just thinking that the people who use the macros aren't always developers, sometimes they're non-coding power users. Seems a bit arbitrary to have some macros that need an extra word in the middle.
Udo
Udo Borkowski
* browsing: only clicking buttons and links is "enabled"
* typing: user can type in text fields
* editing/"authoring": User can create new tiddlers or edit existing ones (through the standard "edit" menu feature).
But I haven't decided on the details yet.
Chris Lawley
On 17 Jun 2006, Daniel Baird wrote about aliases and sparked this thought...
How obvious an idea is it to have a mechanism, let's call it
'aliasifier' that looks at a table of, um, aliases.
|editField |edit field:|
|editMeta |edit meta:|
|editCookie |edit cookie:|
Advantages
""""""""""
+ Single mechanism
+ Easy to extend
+ Possibility for (careful) user to add own aliases
+ Could be used to alias tiddlers (?)
Disadvantages
"""""""""""""
- Possible issues/side effects getting parameters to the actual
function
- Unwitting duplication of names giving rise to all sorts of
problems
Could be solved by scanning the table when it is edited.
- Slow down parsing of names
- everything has to be checked against the alias table first
Could be solved if the aliased name had to start or end with
some sort of 'flag' (don't like this, tho')
Could you alias an alias?
There should be a shadow list and the user version should require
'systemConfig' to be active.
chris :-)
Daniel Baird
This is a good idea. Is there a plugin that does aliasing already, or is that just tiddler name aliasing?
Anyway this is a good example of where Jeremy's idea of Embedded Data (ED, as opposed to Extensible MetaData or EMD) would be useful -- Chris's idea of having a user-maintained table of macro aliases would be easy to implement when there's core code to support retrieving data from a table inside a tiddler.
(see this thread for more about ED and EMD: http://groups.google.com/group/TiddlyWikiDev/browse_thread/thread/b4fa2553ece95e09/
)
It's also IMHO a good example of something that should probably live forever as a plugin rather than put into core.
Like Chris points out, there's gonna be problems with alias and real macro names clashing and other stuff, and equally important it's more complexity that a lot of users won't ever want or need to deal with.
On the other hand there's sure to be a bunch of users who use macros a lot and would love to have the functionality to alias macros. I reckon you chould even extend Chris's proposal a bit (and clear up any ambiguity about passing params) by specifying how params are used in the aliases, maybe like this:
| editMeta | edit meta: $- |
| quickThing | thing presetOne $2 $1 presetTwo $- |
..so $1 means the first param, $2 the second, $- any remaining. So if you type <<quickThing Daniel Chris Jeremy Udo>>
..it gets expanded into:
<<thing presetOne Chris Daniel presetTwo Jeremy Udo>>
Named style params would probably still work.
So.. Chris, start reading up on your JavaScript -- TW2.1 will be out soon with ED and EMD, and you can implement this idea in a nice plugin for us all :)
;Daniel
Simon Baird
http://jackparke.googlepages.com/jtw.html#MyMacroMacro
--
Simon Baird <simon...@gmail.com>
Daniel Baird
At first glance, that doesn't look like it passes params on to the real macro. Jack Parke, if you're listening, is that right?
Probably not a big job to add that feature, though.
;D
Paco Rivière
> 2.1 will be out in less than 8 weeks, complete with extensible
> metadata. Development has now begun in earnest:
>
> http://trac.tiddlywiki.org/tiddlywiki/timeline
>
> Cheers
>
> Jeremy
Would it be posible to have any new strings some days before to be able
to launch Lingo translations at the same time, or even before?
When tidding finals touches strings will probably already decided.
Saq Imtiaz
Anyway this is a good example of where Jeremy's idea of Embedded Data (ED, as opposed to Extensible MetaData or EMD) would be useful -- Chris's idea of having a user-maintained table of macro aliases would be easy to implement when there's core code to support retrieving data from a table inside a tiddler.
(see this thread for more about ED and EMD: http://groups.google.com/group/TiddlyWikiDev/browse_thread/thread/b4fa2553ece95e09/
)
Hmmm... while on the topic of EMD, the thought occurred to me that if we could implement a method for writing back entries to EMD tables as well, it could serve as a nice form for presenting 'data entries' to the end user, while still being able to access and modify them from plugins etc....
Saq
Jeremy Ruston
> to launch Lingo translations at the same time, or even before?
>
> When tidding finals touches strings will probably already decided.
You can see the changes so far to Lingo.js here:
http://trac.tiddlywiki.org/tiddlywiki/log/Branches/2.1/core/js/Lingo.js
You can click through to inspect the individual changes. My general
policy with Lingo.js is only to add to it; I've purposefully never
refactored any of the names to make them more logical.
Soon, I'd like to bring together the various translations and host
them under tiddlywiki.org.
Cheers
Jeremy