Proposal: render fieldnames as links, and see what's possible with fieldname nodes!

#19

My approach does not uses TiddlyWiki’s field solution; instead, both the field name and field value are placed within the title.

As a result, both the field name and field value become links.

#20

I admit to being baffled by “both the field name and field value are placed within the title” … the title of… what exactly? If I have a tiddler with, say, 9 substantive-content fields beyond title, text, and the automatic ones (common for a bibliographic wiki), your solution would be different. It would use … 9 additional tiddlers … Or 18 tiddlers? Or one tiddler with 9 field-value pairs packed into a long title, or…?

Also, I don’t understand how “both the field name and field value become links” by being part of (one) title; the title of a tiddler itself can be treated as a link, but doesn’t naturally articulate into separate links for component parts (without some additional fancy footwork).

If you’re not using fields at all, I’m not sure that yours is really a comment specific to this thread (which is very much about fields), but you do seem to be suggesting that there’s an approach different from using fields but somehow comparable and useful to you, so I’m intrigued (as well as confused) by your comment. Say more?

1 Like
#21

If I can summarize what I got out of an exchange with @tomzheng in that thread a few months ago, he’s building a system that allows him to parse structured titles to declare relationships between tiddlers, which might then also let you derive additional facts. So for instance the title John Adams was married to Abigail Adams would be parsed by an explicit married to rule and assert a relationship between the tiddlers John Adams and Abigail Adams. His idea was that this would allow some recursive parsing to build up larger such relationships; his example was “Tom’s sister is Jerry’s sister’s teacher”.

While there are some very interesting ideas in there, I was never convinced that I would ever have any need for such a tool. And no, I don’t see that it has anything to do with this thread.

1 Like
Alternative Ways to Read JSON Data
#22

Thanks for filling in the missing connection, @Scott_Sauyet!

Indeed, when a field houses a relationship that is in a sense bigger than (or just not neatly subordinate to) either of the component tiddlers, then the implementation of a third tiddler to function as the relational bridge/glue makes a great deal of sense. Genealogical relations are a great case in point. (And I love the granular recursive possibilities of having a tiddler connecting Person1 as a witness to the event of a ceremony whereby the relation of A to B was formalized, etc. where templates in A and B reach into such relations to show the connections…, and maybe our web picks up on another tiddler in which a diary entry by Person2 serves as evidence that [Person1 witnessed the union of A and B], etc., though doubt was in turn cast on that diary entry by… [etc.])

Having a relation-holding tiddler would of course not possibly make sense for most bibliographic field-value pairs such as:

bibtex-year: 2021
bibtex-pages: 188
bibtex-LCCN: 2038748676
bixbtex-series: Emerging Research
bibtex-volume: 54

… where the field-values have little to zero “there” there across records with the same value (let alone the same value across multiple fields, as when 54 might be the volume value for one tiddler and the pages value for another!)

Even when the field-value does have a coherent tiddler-like identity worth linking up (such as author), it would very silly indeed to have a tiddler for the book, a tiddler for the author, and a THIRD logically independent tiddler to store the fact that this-here book was written by that-there person ;). One would never want one’s “grip” on a bibliographic record (say, in porting it from one wiki to another) to leave behind info that has this “card-catalog” constitutive relation to the tiddler’s content.

Still, one might want a relationship tiddler for something like (say) citation connections or special-purpose notes. (The fact that brown2024 cites mingus2019 certainly is “baked into” the brown book, but it’s not a “core” data point, and it wouldn’t scale well to cram all such detailed connections into the primary tiddler!)

#23

I don’t find it all that silly. I think there are plenty of times when this would make great sense.

If you think of certain records/tiddlers as representing bibliographic entries, then sure, you want them to be as intact and comprehensive as you reasonably can make them.

But if you think of your wiki as a whole as (at least in part) a bibliography, then it might make more sense. So if the following two questions have equal importance in your wiki, then a well-normalized (in the database sense) set of data could well be the best structure:

  • Who wrote The Fragility of Goodness?
  • What works did Martha Nussbaum publish?

This helps to some extent with the “Martha Nussbam”/“Nussbaum, Martha C” problem, as we can have a dropdown to select Person when creating an Person/Work tiddler. And we can have an aliases list field on the Person tiddler. And if we have separate Citation records, then the appropriate format of the author’s name in that instance can be in its own field.

On the other hand, I don’t see any good reason for any such many-to-many relationships between a work and a bibtex-year. If I wanted context around the year – What other works were published that year? Who was born/died/married in that year? Etc. – then I would expect a virtual tiddler with a template that could answer those questions. The difference is that an author feels like an important entity. A year does not.

You know tremendously more than I do about academic bibliographies, so I may be talking out of my hat. But this idea fits with with how I’ve built a number of other wikis.

#24

And I suspect I would have spoken against compound titles, but in the absence of an approach to better support relationships it is a brave attempt.

Agreed

Here in my Infinite Topic No touch tags - or flags on tiddlers without editing or changing the tiddler - #102 by TW_Tones I recently raised;

  • The exception may be when we want more info stored in the relationship itself.

Essential to support accross tiddler relationships

As I belive I have some methods available now to build a robust set of inter tiddler relationship tools I have one remaining problem to be solved. This is well reflected in the concept of marriage.

  • If Mr and Mrs are married it is a relationship
  • However it should be time limited where possible
    • A marriage has a start date and may have an end date
    • What if we know they married but not when? we still want to maintain the relationship
    • What if we want to record when we recorded it?
    • What if we know the year not the date?
  • So there is sometimes, if not often, a need for relationships to;
    • Be maintained even with changes in one of the related tiddlers, or the relationship
    • Contain additional information

I am working on finding a solution to the issues around this right now;

Linking tiddlers via there title eg; ones spouse, yet storing additional information about that relationship.

#25

You’re dealing with the usual tiddlers and fields. For example:


title: title1

field1:value1

Then field1 is converted into a link.

Through filters or other programming methods, you can derive value1 from title1 and field1. You can also display this value1 to users via views.

I placed all information within the title. For example:


title:title1

title:field1

title:value1

title:title1 field1 value1

Since all these are titles, they are all links.

Currently, I cannot obtain value1 through filters or programming methods. I can only allow users to derive value1 from title1 and field1 via views.

My solution not only retrieves value1 from title1 and field1, but also obtains field1 and title1 from value1. Queries can be performed in either direction, similar to Prolog.

In Prolog, if the information a b c exists, you can query a b X to obtain c, or query X b c to obtain a.

Many phenomena share underlying commonalities.

For instance, tag1 can add supplementary information to title1. For example:


title:title1

tag:tag1

However, if we avoid using tags and instead employ wiki links, we can organize information in a similar manner. For example:


title:tag1

text:[[title1]]

We achieve the tag effect through backlinks.

For example, the following two approaches achieve the same effect:


tag:tag1 tag2



tag1:

tag2:

No solution is unique; alternatives exist for any approach. Multiple paths lead to the same destination. For instance, I replaced the outliner with the table.

My ssspc can also store field name and field value information while generating links. Thus, it aligns with this thread’s core point. It isn’t a field-specific solution. But for storing supplementary information, fields aren’t the only approach.

Therefore, my reminder in this thread is: if you require field values to be links, consider abandoning the field method and adopting the ssspc approach. This provides a ready-made solution.

My approach also qualifies as a no-touch tags solution.

My approach is to attach information to a tiddler in another location.

My approach allows attaching information to multiple tiddlers in bulk.

However, my approach is completely unrelated to TiddlyWiki’s existing information structure. Should I participate in TiddlyWiki discussions?

#26

@Springer

I just want to support the clarity in your first post, and also you using field-description. Using this prefix field- for all field-related data tiddlers can similtaniously be tags, field and contain other content.

  1. Should the fieldname solution be “direct” or “indirect”?
  • I think we should start with direct fieldname, but provide an option to migrate to $:/fields/fieldname if needed. The editor and other tools can be designed to look for $:/fields/fieldname first then fieldname. This allows us to use the system thus hidden form if the fieldname clashes with anything.
  1. Should users have fine-grained option to enable/disable “missing” fieldname links?
  • On second reading I think this is a good idea, especialy when parsed in the text field. But we need a local overide for some cases where the fieldname is multifunction eg the tags field may also open the/a tags manager.
  • Secondly we can have a more > fields tab to access them if disabled.
  1. What do you all think are the essential or most exciting fields about fields ?
    I think the latitude to define a field even complex attributes through field- prefixed fields. Here are some I want;
  • field-description what is it about
  • field-caption eg description field may have Description sentence case
  • field-tooltip appears on mouse over
  • field-values filter or list on what where to find values
  • field-type - this would point to a shared field-type whic may describe how to edit or display a color field, email address, short text, numbers etc… there will be far fewer field-types than fields needing definition
    • A field although it has a field-type may localy override a field-type-fieldname if it differs from a field-typ tiddler in some way, just by including that field-type-fieldname in a field tiddler.
    • For full and comprehencive field handling we would need to discuss what exists within a field-type tiddler, even if they are the same tiddler.
    • An important thing about field-types is they can be freely built and shared without use unless assigned to a field-tiddler.
  • The items you raise such as is_textarea/is_list etc… are better handled in reusable field-type-fieldnames be they in the field tiddler or in a shared field-type-tiddler

In a related matter it is clear we can say use an arbitary field to indicate it is a field tiddler eg field-description but this is somewhat arbitary, and one needs to remember what it is. I have come to the conclusion we need a defacto standard of a tiddler-type where we can indicate it is a field-tiddler, field-type-tiddler and other forms like contact, bookmark, organisation, domain, project etc…

  • However as discussed above one tiddler can quite easily have more than one role so perhaps tiddler-types (field) could be a list of roles, or we could use a tiddler-roles field?
  • We may then simple add another role or type to the list to create a field tiddler. The view template can then add a panel to any tiddler found to have the field role (or other roles). Such pannels can be turned off globaly with $:/config/design-mode=no
    • We can have a cascade option for loading the correct view template, body template(s) etc… for each role provisioned in advance, just use them as needed.
1 Like
#27

I am not sure I grasp this. With my own deep knowledge to TiddlyWiki I feel I need to mature what we already have.

If it may help, when you go into tiddlywikis editor and have a custom field its editable towards the bottom of the page. Where you will see the field name in text as a lable to the field. This is where we were proposing having that fieldname link to a tiddler of the same name, like tag tiddlers (the tag pills) link to a tiddler with the tags name, at first missing, if you create a tiddler from a tag, we call it a “tag tiddler” and this topics idea was to also have “field tiddlers” and there in we can start to build additional features as we do for “tag tiddlers” that can have a caption, description, icon color etc…

  • However in the case of field tiddlers we can start to introduce field-types, selection filters and value and more.
#28

From the perspective of improving TiddlyWiki, there’s no point in discussing it further, because my solution doesn’t utilize TiddlyWiki’s data structure at all.

I fully understand what this thread is discussing. In the demo, clicking the field name brings up the field tiddler. Within the field tiddler, you can see all the values for that field, as well as which tiddlers contain values for that field. My solution can fully achieve this effect.

#29

Of course you should! You clearly have something interesting to offer.

But I’ve invested a reasonable amount of time in trying to understand ssspc. While I think I’ve grasped the basics, I also haven’t seen any use-cases where I would choose it over other TW techniques. Perhaps at some point I’ll have a moment of enlightenment where this suddenly makes sense to me. I haven’t gotten there yet, though.

1 Like
#30

Hi @TW_Tones and all. Getting back to this thread after being away.

I think this is an especially important area for community collaboration. It’s valuable to have rough consensus on the most important kinds, and potentially dangerous if different plugin-solutions or other community-circulated variations emerge in ways that conflict. We may also converge on some field-type candidates that we’d eventually like to see supported in the core through the existing cascade for field editing templates (using $:/tags/FieldEditorFilter tag), but also perhaps cascade support for field display and linking-behavior as well.

At any rate, before we get really clear about field-types, we should pause on whether the TYPE of data might be unhooked from its MULTIPLICITY:

For example, biblio wikis handle lots of PERSON-NAMES as a kind of field-data (where there are special functions and lookups designed to handle the complexity of names), AND it would be ideal if this could articulate separately from whether this field can hold a MULTIPLE values (ordered or unordered list of names for authors, editors, etc.).

Similarly, in theory the fact that a field holds COLOR-type data (or DATE-type or URL-type) shouldn’t determine whether it’s a field that can hold multiple such values.

Stretch case: a field with any of the above data types might be configured to allow for a FILTER input…, without losing other features of being handled as according to its type (when it comes to display, linking, etc., of the output of the filter).

image
image1842×546 70.7 KB

EDIT TO ADD: The data-type NUMBER is an interesting case, because JSON “in the wild” expects numeric values not to have quote-marks around them. I don’t know much about what’s at stake in specifying that a field holds numeric value(s) — rather than just allowing that filters can operate on them, use nsort etc., but perhaps it could be powerful.

ALSO to ADD: It can be powerful if we can allow that a field’s MULTIPLE values can have custom DELIMITERS (overriding the default [[only double brackets help cluster value-strings]] convention. In particular: biblio wikis inherit bibtex data, where bibtex-author values are separated by and … but of course TiddlyWiki needs lots of help parsing multiple values there. But imagine if — right in the fieldname tiddler — you could specify that hobbies is a comma-delimited list, or topics is a semicolon-delimited list, etc. Then additional functions could effectively handle those value lists properly. After all, we don’t want to have to convert bibtex-author values such as Dewey, John and Bentley, Arthur into [[Dewey, John]] [[Bentley, Arthur]] because this conversion is not only a one-time nuisance, but also inhibits further free interchange and collaboration across bibtex databases.

(I’m sure the matrix above is not ideal in the details. Still I hope the idea is clear: that FIELD-TYPE of data and plurality/order of data (FIELD-IS-LIST or whatever) may want to articulate separately. Example fields above are just there to illustrate natural “fit” in off-the-shelf TW. I only treat ordered and unordered lists separately because TW currently has trouble treating tags as an ordered list. Even though it’s easy enough to ignore ordering as needed, maybe it matters for a given wiki’s purpose that some multiple-value field is order-independent.)

Last note: This old thread by @TW_Tones (which I completely missed, as it was a busy season work-wise) also included quite a bit about field types: Rapid Database development tools proposal - #33 by Scott_Sauyet (in addition to some stuff about editing that pulls in a somewhat different direction). …

1 Like
#31

Thanks @Springer some very important issues you have raised on the next step of the field-type. Which we have not discussed as much so far, but clearly you have investigated this to a substantial extent.

  • In particular the alternative types of list field is importiant amongst more in your reply.

Yes, this is why I hope we can soon share a framework on which we can build field-types.

I feel we have three more key issues to address that are importiant to an open and forward looking platform on which the community can thrive. All three influence how field-types can be implemented.

  • The ability to have tiddlers be qualified so that fields can be defined differently for different sets of fields. tiddler-type perhaps?
  • Custom fields at least need view and edit modes, so as we implement this we may as well allow two or more modes, for example “update” mode may be when you can modify a field when viewing it by clicking on a field edit button, and read-only does not give you these options.
    • A field or field-type system will need to take account of these modes
  • The provision of a standard macro or widget, so it is trivial to make use of fields and retrive the nessasary tiddler-type, field definitions, field-type and mode responce. Then display or edit the field in the user interface. I have done something similar in the past but want to socialise it with you and others interested.
  • Later we can use the above to prepare forms, create new tiddlers and fields.

More on the first item above tiddler-type

As has being discussed elsewhere tiddlywiki has reserved the type field for its own core operation and different mime types. Thus we can’t use this to differentiate between different tiddlers which will have different field sets and field definitions. We need to find an aggreed way to do this, because people can build their own sharable solution with their own tiddler-type/s

  • Allthough it may be safer to consider implementing a “roles” approach where tiddlers can have one or more roles at one time. I have just done a Proof of Concept on this but for missing/tag/field/and flag tiddlers.

Why tiddler-type now?

A simple use of tiddlywiki will result in field definitions based directly on a fieldname that are shared throughout the wiki.

However sometimes users may want a different definition for the same field or fields. This would be hard to retrofit, but simple to add now. We just need an aggreement. But do read though section this before commiting to this.

  • A field defined from a tiddler without a tiddler-type may use the tiddler fieldname,
  • A field defined from a tiddler with a tiddler-type will use that to construct a field definition in tiddler-type/fieldname.
    • thus the same fieldname can be defined different ways for different tiddler-types.
    • An optional prefix of “$:/” could use “$:/tiddler-type/” to prefix field definitions only for that tiddler-type
    • For safetly if a tiddler-type is in use but field definition is found at $:/tiddler-type/fieldname then fall back to fieldname. So custom tiddler-type or roles can still use standard field definitions.

I propose that tiddlers have a tiddler-type field that defines the primary role of the tiddler, we could call it the first role. Then we can make use of the roles or tiddler-roles field in future, so tiddlers can have multiple roles. A common extra role may be as a todo item, to do something on the current tiddler-type instance.

  • We need to simlify the use of a list field like the roles/tiddler roles so that rolls are added to the tiddler not replacing any existing ones.

Yes, nothing is new :nerd_face:

Lets do it!

#32

Responses

Might it be easier to skip tiddler-type and just do a tiddler-roles list field right up front?

If it make a preliminary implementation easier, we can start by working with only the first value in that list, but the changes should be easier than they would be if we had to switch from tiddler-type later.

I think this is essential, but see the discussion on the Diamond Problem below.

What would this be for? I’m not following.

Questions for thought

  • Is a tiddler-type/tiddler-role any more than a mapping of field-names to field-types? Would it also include ViewTemplate(s)? Might it be packaged as a new plugin type?
  • Would the selection of a type/role automatically add the related fields with some default or blank values? Or would the user be expected to create them manually?
  • How do we handle the Diamond Inheritance Problem? Imagine we have a system displaying timelines of when actors and props are on stage during a scene. We might show various circles (actors) and rectangles (props) appearing and disappearing, with some color-coding and sizing to distinguish greater and lesser importance or such. An Actor tiddler might have the role Stage Presence, with timestamp fields for came and left, and it might have the role Drawable Object with a color field, and number fields for top, left, height, and width. The problem should be clear: The two roles define the field left, with different meanings and different field types. How do we handle that?1

Implementation

I feel as though a great deal of the functionality may already be covered by the FieldEditorCascade. We should be able to write a function that generates and runs a cascade based on the field-name to field-type mapping in a tiddler-type/tiddler-role tiddler, to select the proper editor. I will try to play with this, but it won’t be for more than a week.




1 I know this example is strained. Rather than using came and left, one would likely use entered and exited. But it was the only thing that came to mind quickly. And it shows the sort of things that could happen. A better example would be much appreciated.

#33

Admission Of Ignorance

I’m likely an idiot!

I just don’t grasp how the aim of O/P, if achieved, would help?

Could you folk give me some idea, some speculative examples, of how it could?

Grazie, TT

#34

Perhaps wait until a working example is given but the idea is to create a defacto standard that helps expierenced users and novices alike add aditional field handling when building something.

  • A simple example may be introducing a background-color field to tiddlers and being able to use the color swatch selector.
  • A more complex example may be to make an email address field that insists on something@domain for rudimentary validation testing.
  • Perhaps a field with a list of items to select from, or select from all existing values for that field.

There are millions of different fields you could create with all kinds of content but when you break them down there is perhaps 12-14 common field types including number, date, short text, textare etc… For this we will build a set of field-types that you can assign to any fieldname. The community can build and share these or include them in there wiki, solution or plugin.

I have a firm belife if you build a basic simple system people will make use of it to build anything, It is possible already we just want to make it much easier and put us on the same page. If you dont want anything to do with it, you dont have to :nerd_face:

Thanks for your responce @Scott_Sauyet I am glad you support parts of this approach and review your responces in more detail tomorrow, thanks.

  • Another option may be tiddler-types
  • Or roles

however I think tiddler-roles also sets a standard for fields relating directly to the tiddler uses the prefix tiddler-, field related ones field- one of which is field-type and the field type uses the prefix field-type-

I will be back

#35

Gosh, I thought it was all pretty spelled out in the original post, and in the working demo, where the idea pretty much is achieved, and not speculative — though it certainly could be fleshed out more.

The OP was about rendering fieldnames (in edit-field interface) as links (though we’ve also recently gone on to talk about types of fields, and what might matter about the parameters of fields). Making fieldnames open up nodes in the story river is especially powerful if fieldname nodes render not just as generic “Missing Tiddlers” but instead show templates that automatically draw information about those fields into useful form. At any rate, once we approach fieldnames as having a “there there” (just like tagname tiddlers), we can use those tiddlers to further clarify and develop how that field should function.

Consider a bibliographic database in TiddlyWiki form. One might be editing a record, and say, "But what is bibtex-LCCN? Hover over that field name, and see a tooltip: “Library of Congress Catalog Number”. Cool! Click on the fieldname to see an virtual-tiddler template overview of which records have this information.

Click on bibtex-publisher to see a template showing all the publisher values across the wiki. Click on bibtex-year to see what year-date values are in the system (including some inherited records that are improperly formatted — nice to see that from a clear angle!) Basically, leverage the fieldname as a new “x-ray slice” for your data.

Consider a home wiki, where you discover some tiddlers have a field called acct and others have a field called account. Oops. Click on each fieldname to see immediately which records have acct field, and which have the account field, to troubleshoot quickly. (Heck, we could have the fieldname template build in the functionality of “rename field”, though I haven’t gotten there yet.)

More powerfully: the fieldname node, if you “edit it into being” as a tiddler, is an ideal place to store important info and pivotal details about the field. In addition to the field description (and/or caption and/or tooltip) and notes about what “hangs” on that field (templates or plugin functions, etc.), we may develop various neat solutions that adapt to things like:

  • whether a field should offer a big text-entry input area for editing
  • whether its values should appear as links (the way “modifier” does in default subtitle)
  • whether the entry for that field should display a date-selection drop-down
  • whether the field should be parsed for name data (with its particular fuzzy match challenges)
  • whether this field’s values should be validated for uniqueness

It’s the essence of TiddlyWiki to make things “intertwingled”. Empowering fields as structural conduits is a natural next step.

2 Likes
#36

Okay. I sort-of get it. The biblio examples I do understand.

I’m still a bit unclear on whether this way is the best.

But I should be quiet because I don’t wanna stymie your efforts.

TT

#37

Certainly, I can see why many folks want something like “tiddler categories” (not the type field but effectively “types of tiddlers”).

In my experience, conditional logic (picking up on whatever aspects matter) pretty much always suffices, and I don’t need to add explicit tiddler kinds. (If a tiddler has bibtex-title field, that fact triggers certain cascade conditions, templates, etc. Introducing some additional data-point to flag it as belonging to “bibliographic record tiddler” category seems redundant.)

At any rate — even if others do want a dedicated way to “categorize” tiddler by tiddler-type (beyond tags and other existing conditions), I’m not sure how/why developing field kinds (different functional shapes for fields) requires this. A well-designed wiki surely ought not to have the same fieldname functioning very differently across different tiddlers.

Hmm, I’m worried about “feature-sprawl” here.

How common is it for someone to say: This TiddlyWiki project needs the very same field to function differently across different tiddlers?

Perhaps an extreme case would involve handling frequently-imported-and-exported data that is stubbornly structured around some field names that also have some other role in the wiki… If it came to that, I think I’d be happy with letting the field description be explicit about the double role, and letting cascade conditions function in a conditional-governed way to deal with the forking. At any rate, surely the fieldnames that the core uses are not going have forked definitions or forked functions, right?

In an earlier post, you were talking about making TW approximate certain database capabilities better, and indeed that is my background (having developed complex solutions in FileMaker prior to discovering TiddlyWiki).

But the more powerful the database, the more neatly we find fields (and field “types”) to be uniformly defined.

One thing I love about TiddlyWiki is that we can play with lots of “free-form” stuff (have tiddlers that float along without being assigned to this or that “table”, have a field or tag whose power starts out small, and then grows…). It’s nice that we can be fuzzy about fields in the beginning: a field is by default just a named but otherwise free-form place to store a string. The on-ramp for a TiddlyWiki solution is gentle and fun. :slight_smile:

Still, my sense is that fields — as such — are powerful precisely because they can specialize. To want a specialized field is to want tiddlers to have a potential “pocket” — of a certain size and shape — to be handled pretty-much uniformly across a wiki. TW until now has invited users to add their own fields, but without any further functional differentiation. But if you and I want more powerful fields, I think we need the potential narrowness of a field’s function to be a point of leverage. Of course there can be conditionally variable handling, but it should still make sense within a unified understanding of the field’s role. (The “coin pocket” might appear hidden totally inside the front pocket of my dress slacks, while being higher up and visible on my jeans. But a coin-pocket accomplishes what it does by being compact — holding more securely precisely because it’s not designed to hold pencils or wallets.)

So… which of these non-simple field-definitions scenarios is more like what you’re imagining:

  1. Conditional nuance: bibtex-author field has a clear role, but needs to be handled differently in context (for example, delimiting values by default with and — except in language:French tiddlers, where they’d be delimited by et? Or case# needs to be validated for uniqueness across records with one tag, but not in others…

  2. Mere homonyms: A field name might not have any steady function across the wiki, because somehow we’re attached to having est field hold a date for year “established” in records for businesses, while est field will hold currency figure for “estimated cost” in records for remodeling tasks…

?

I’m all-in for (1), but (2) feels like a last resort that I wouldn’t want to design around…

1 Like
#38

I think this depends upon whether the wiki is lovingly crafted from scratch or if it’s partly built out of existing pieces. If one plugin defines some field-types that I want to use on some subset of my tiddlers, and another defines other field-types that I want to use on some overlapping subset, it’s no problem. But if they happen to define the same field-name for two different purposes, then we have a problem. Sure, they’re “mere homonyms”, but we need to figure out how to handle them. (Or not; it may simply be an intractable problem.)

@Springer: I was rereading the OP, and happened to notice a RSOE if I tried to delete a field tiddler, real or virual. I haven’t investigated why, but thought I’d let you know.,