Actually a correct set wouldn't be "AB Arthur; BC Zaphod; DE Trillian" - there would be no spaces between terms. it would be "AB Arthur;BC Zaphod;DE Trillian". A semi-colon isn't needed after the last item but won't upset TB if present, e.g. as a result of some code-based list production where all items have the same terminator applied.

Currently, you've data like "AB Arthur, BC Zaphod, and DE Trillian" which if added to a Set would create a single list value. Bear in mind though that just changing the source from commas to semi-colons isn't enough though as "and DE Trillian" isn't an author. Therefore, I guess you'll need to write some queries to strip terms like 'and', 'et al' etc. at some point in your import or - depending on the workflow/volume of data, correct such terms manually.

OK, as Set attribute values we've comma+space delimited strings instead of such strings' contents being discrete TB list items. To resolve that, this action code works (testing in v5.10.1):

$MySetA = $MySet.replace(", ",";");

Alternatively, if an 'and ' is the only non-author content apart from the commas we can use:

$MySetA = $MySet.replace("and ","").replace(", ",";");

Note how the dot-operators let us 'chain' two discrete actions together - and the 'and' sub-strings are replaced with nothing then all the ', ' sub-strings are replaced with semi-colons. If the were more garbage terms than just 'and ' I'd try and weed them before the point and certainly not try and chain many .replace() arguments as in other than a very small test something is likely to get overloaded. IOW, I don't think the design intent for chaining would be for twenty chained .replace() calls. YMMV depending on your TBX's size/complexity/content.

If a note's $MySet had 2 discrete values "ant, bee, cow;dog, eel, fox", $MySetA now holds 6 discrete values. Actually you can set the data back on itself, with either of:

$MySet = $MySet.replace(", ",";");
$MySet = $MySet.replace("and ","").replace(", ",";");

... but if testing code and working on real data it might be worth cleaning the data into a new attribute, checking it in the latter and only then overwriting it back into the correct attribute (and deleting the temporary one).

The above tests were done in a $Rule but a more real-world scenario is you'll make and agent to find the data to clean:

Query:  $Authors      (only match notes with data in $Authors)
Action:   $Authors2 = $Authors.replace(", ",";");

Check that Set attribute $Authors2 is giving you the results expected and then change the agent's action:

Action:   $Authors = $Authors2;

You can now delete $Authors2. Of course, this whole action assumes the process is once-only.  I guess you could use either of:

$Authors = $Authors.replace(", ",";")
$Authors = $Authors.replace("and ","").replace(", ",";")

...and leave it running all the time to clean new data being added in non-TB-list form. I'd be more tempted to import author data to some other attribute and only then clean it into $Authors so as to have more control.

Without seeing more of the workflow and how dirty the source data is, it's hard to conjecture much further - though I would suggest looking at the export methods of any upstream app to see if it can export the author info in TB list-friendly format.

P.S. I'm aware the usage of .replace() above doesn't match documented usage. I'm not sure why, but it seems some previous limitations of conts/replace against sets/lists has been removed since these features were added.

Perfect! I just hadn't noticed the .replace() operator.

Thanks!