Alteryx Designer Desktop Ideas

The DateTime Tool currently displays incoming date-time data types in a dropdown menu and "If no date-time columns are present, the field appears dimmed and shows 'No Suitable Input Fields Available'". However, considering the complexity of date formats, it's beneficial to directly view the data type of incoming date-time data instead of relying solely on visual inspection. While Designer filters options based on string or date/time types automatically, having visibility into the data type ensures a more sound interpretation of the input for analysis purposes.

I’ve been using the Regex tool more and more now. I have a use case which can parse text if the text inside matches a certain pattern. Sometimes it returns no results and that is by design. 

Having the warnings pop up so many times is not helpful when it is a genuine miss and a fine one at that. 

Just like the Union tool having the ability to ignore warnings, like Dynamic Rename as well, can we have the ignore function for all parse tools? 

That’s the idea in a nutshell.

It would be great if you could include a new Parse tool to process Data Sets description (Meta data) formatted using the DCAT (W3C) standard in the next version of Alteryx.

DCAT is a standard for the description of data sets. It provides a comprehensive set of metadata that can be used to describe the content, structure, and lineage of a data set.

We believe that supporting DCAT in Alteryx would be a valuable addition to the product. It would allow us to:

• Improve the interoperability of our data sets with other systems (M2M)
• Make it easier to share and reuse our data sets
• Provide a more consistent way to describe our data sets
• Bring down the costs of describing and developing interfaces with other Government Entities
• Work on some parts of making our data Findable – Accessible – Interopable - Reusable (FAIR)

We understand that implementing support for this standards requires some development effort (eventually done in stages, building from a minimal viable support to a full-blown support). However, we believe that the benefits to the Alteryx Community worldwide and Alteryx as a top-quality data preparation tool outweigh the cost.

I also expect the effort to be manageable (perhaps a macro will do as a start) when you see the standard RDF syntax being used, which is similar to JSON.

DCAT, which stands for Data Catalog Vocabulary, is a W3C Recommendation for describing data catalogs in RDF. It provides a set of classes and properties for describing datasets, their distributions, and their relationships to other datasets and data catalogs. This allows data catalogs to be discovered and searched more easily, and it also makes it possible to integrate data catalogs with other Semantic Web applications. 

DCAT is designed to be flexible and extensible, so they can be used to describe a wide variety. They are both also designed to be interoperable, so they can be used together to create rich and interconnected descriptions of data and knowledge.

Here are some of the benefits of using DCAT:

• Improved discoverability: DCAT makes it easier to discover and use KOS, as they provide a standard way of describing their attributes.
• Increased interoperability: DCAT allows KOS to be integrated with other Semantic Web applications, making it possible to create more powerful and interoperable applications.
• Enhanced semantic richness: DCAT provides a way to add semantic richness to KOS , making it possible to describe them in a more detailed and nuanced way.

Here are some examples of how DCAT is being used:

• The DataCite metadata standard uses DCAT to describe data catalogs.
• The European Data Portal uses DCAT to discover and search for data sets.
• The Dutch Government made it a mandatory standard for all Dutch Government Agencies.

As the Semantic Web continues to grow, DCAT is likely to become even more widely used.

DCAT

• Reference Page: https://www.w3.org/TR/vocab-dcat/
• Dutch (NL) Standard: https://forumstandaardisatie.nl/open-standaarden/dcat-ap-donl
• WIKI Pedia on DCAT: https://en.wikipedia.org/wiki/Data_Catalog_Vocabulary

RDF

• Reference Page: https://www.w3.org/TR/REC-rdf-syntax/
• Dutch (NL) Standard: https://forumstandaardisatie.nl/open-standaarden/rdf
• WIKI Pedia on DCAT: https://en.wikipedia.org/wiki/Resource_Description_Framework

It would be great if you could include a new Parse tool to process Business Glossary concepts formatted using the SKOS (W3C) standard in the next version of Alteryx.

SKOS is a widely used standard for the representation of concept and term relationships. It provides a consistent way to define and organize concepts (including versioning), which is essential for the interoperability of these data.

We believe that supporting SKOS in Alteryx would be a valuable addition to the product. It would allow us to:

• Improve the interoperability of our data sets with other systems (M2M)
• Make it easier to share and reuse our data sets
• Provide a more consistent way to describe our data sets
• Bring down the costs of describing and developing interfaces with other Government Entities
• Work on some parts of making our data Findable – Accessible – Interopable - Reusable (FAIR)

We understand that implementing support for this standards requires some development effort (eventually done in stages, building from a minimal viable support to a full-blown support). However, we believe that the benefits to the Alteryx Community worldwide and Alteryx as a top-quality data preparation tool outweigh the cost.

I also expect the effort to be manageable (perhaps a macro will do as a start) when you see the standard RDF syntax being used, which is similar to JSON.

SKOS, which stands for Simple Knowledge Organization System, is a W3C Recommendation for representing controlled vocabularies in RDF. It provides a set of classes and properties for describing concepts, their relationships, and their labels. This allows KOS to be shared and exchanged more easily, and it also makes it possible to use KOS data in Semantic Web applications.

SKOS is designed to be flexible and extensible, so they can be used to describe a wide variety. They are both also designed to be interoperable, so they can be used together to create rich and interconnected descriptions of data and knowledge.

Here are some of the benefits of using SKOS:

• Improved discoverability: SKOS makes it easier to discover and use KOS, as they provide a standard way of describing their attributes.
• Increased interoperability: SKOS allows KOS to be integrated with other Semantic Web applications, making it possible to create more powerful and interoperable applications.
• Enhanced semantic richness: SKOS provides a way to add semantic richness to KOS , making it possible to describe them in a more detailed and nuanced way.

Here are some examples of how SKOS and DCAT are being used:

• The Library of Congress uses SKOS to describe its controlled vocabularies.
• The Dutch Government made it a mandatory standard for all Dutch Government Agencies.

As the Semantic Web continues to grow, SKOS is likely to become even more widely used.

SKOS

• Reference Page: https://www.w3.org/TR/skos-reference/
• Dutch (NL) Standard: https://forumstandaardisatie.nl/open-standaarden/skos
• WIKI Pedia on SKOS: https://en.wikipedia.org/wiki/Simple_Knowledge_Organization_System
• Video: https://youtu.be/pbTRDDQ43Sw?si=RG3f-jPBsx2OK8IQ
• Tools: https://csiro-enviro-informatics.github.io/info-engineering/semantic-tools.html

RDF

• Reference Page: https://www.w3.org/TR/REC-rdf-syntax/
• Dutch (NL) Standard: https://forumstandaardisatie.nl/open-standaarden/rdf
• WIKI Pedia on DCAT: https://en.wikipedia.org/wiki/Resource_Description_Framework

1. TEXT TO COLUMN TOOL : Check Mark  for “Output/No-Output” next  to  “OUTPUT ROOT NAME”  

Most of the time I don't want/need the column that I parsed. Provide a check box for if you want the root column output. 

Idea removed, regex will do the job. 

Many of today's APIs, like MS Graph, won't or can't return more than a few hundred rows of JSON data. Usually, the metadata returned will include a complete URL for the NEXT set of data.

Example:  https://graph.microsoft.com/v1.0/devices?$count=true&$top=999&$filter=(startswith(operatingSystem,'W...') or startswith(operatingSystem,'Mac')) and (approximateLastSignInDateTime ge 2022-09-25T12:00:00Z)

This will require that the "Encode URL" checkbox in the download tool be checked, and the metadata "nextLevel" output will have the same URL plus a $skiptoken=xxxxx value.  That "nextLevel" url is what you need to get the next set of rows.

The only way to do this effectively is an Iterative Macro . 

Now, your download tool is "encode URL" checked, BUT the next url in the metadata is already URL Encoded . . . so it will break, badly, when using the nextLevel metadata value as the iterative item.

So, long story short, we need to DECODE the url in the nextLevel metadata before it reaches the Iterative Output point . . . but no such tool exists.

I've made a little macro to decode a url, but I am no expert. Running the url through a Find Replace tool against a table of ASCII replacements pulled from w3school.com probably isn't a good answer.

We need a proper tool from Alteryx!

Someone suggested I use the Formula UrlEncode ability . . .

Unfortunately, the Formula UrlEncode does NOT work. It encodes things based upon a straight ASCII conversion table, and therefore it encodes things like ? and $ when it should not.  Whoever is responsible for that code in the formula tool needs to re-visit it.

Base URL: https://graph.microsoft.com/v1.0/devices?$count=true&$top=999&$filter=(startswith(operatingSystem,'W...') or startswith(operatingSystem,'Mac')) and (approximateLastSignInDateTime ge 2022-09-25T12:00:00Z)

Correct Encoding: 

Add ability to name the columns for the text to column fields tool. 

Although this could also effect ANY formula, the RegEx tool does not support a flag for Multiline.  Often incoming data contains multiple lines of data and the user must replace new lines and carriage returns with a space or other delimiter in order to operate a regular expression on all of the data.

RegEx has a multiline flag (for Alteryx it would be a checkbox) that allows it to handle each line separately.

domain.com

test.com

site.com

if these are individual records, then \w+\.com$ works wonderfully,  if these are all contained in a single EXCEL cell, then you need to write to community to figure out what to do.

Cheers,

Mark

Checkbox ability to ‘not’ output the original column on a text to columns tool

Can a function be added to the Text-to-Column tool that allows selecting "split on entire entry" or "split on entry-as-a-whole" for the delimiters field?

Background:

Currently if we type  vs.  in the delimiters field, it'll look for each character separately including spaces.

The recommendation in the tool help is to use RegEx for splitting on whole words, but for some, RegEx is quite intimidating and adding this function would be a big help for new users.

Proposed Change:

2 Radio Buttons added to the Text-to-Column tool

1. Split by Each Entry
   1. Current functionality
   2. Should be default
   3. Splits on every letter, space, punctuation, etc. separately
2. Split by Entire Entry
   1. Allow splitting by using entire entry in the field
   2. Still includes spaces, letters, and punctuation, but now sees as "whole-word"

Example of function:

1. Radio button set to "split by entire entry"
2. Delimiter field has:   vs. 
3. Tool sees  ______ vs. ______  in a column in the data
4. Tool splits ______  and  ______ into new columns leaving out the entire vs. including the spaces entered around it

Thank you!

SOOOOoooooo many times it'd be great to just dictate the character length/count (fixed width) for the parse (just like you can in excel), instead of being constrained by a delimiter or being obligated to go create (potentially complex) REGEX.  Ideally you could go into the column and insert the <break> (multiple times if needed) after the given character where you'd like the parse to occur.  Anything past the last <break> would all be included in the final parse section/field. 

You could also do it a little less visual and just identify/type the character count you want for each column.  If you really want to enhance this idea, you could also include the ability to name the fields and prescribe the data type.  Those would just be gravy on the meat of the idea however, which is, provide the ability to parse by fixed length fields.

In Japan, the prople usually use the date format "yyyy/mm/dd". But there is no preset in Date tool. So I usually use custom setting, but it is the waste of time.

So please add yyyy/mm/dd format to the preset in Date tool configuration for Japanese people.

The XML Parse tool has a checkbox to ignore errors and continue.  This idea works for all options that allow you to ignore errors.  It would be great if XML Parse had 2 outputs, 1 for successful records and another for the errored records.  This would make it much easier to identify and update (if necessary) errored records.

In my view this would make it more similar to other tools like Filter or Spatial Match where records that don't fit your criteria follow a different flow.

Thanks for considering

We've got your metadata.  Suppose the "SELECT COLUMNT TO SPLIT" question is considered by Alteryx and this happens:

• A field is selected because it contains similar \W (regex for non-word characters) patterns in the data (e.g. count of delimiters in the field are roughly equal).
• The delimiter (MODE delimiter or BEST) is defaulted
• Split # of columns = MODE count + 1

If a user updates the Field/Delimiter, the metadata could suggest the right Number of columns based upon the delimiter.

This all belongs in the automagically idea bank.  It saves me the time of counting delimiters or trial and error counts.

Cheers,

Mark

Prezados, boa tarde. Espero que estejam todos bem.

A sugestão acredito eu pode ser aplicada tanto na ferramenta de entrada de dados, quanto na ferramenta de texto para colunas.

Existem colunas com campos de texto aberto e que são cadastrados por áreas internas aqui da empresa. Já tentamos alinhar para que esses caracteres, que muitas das vezes são usadas como delimitadores, não sejam usados nesses campos. Porém achei melhor buscar uma solução nesse sentido, para evitar qualquer erro nesse sentido.

A proposta é ser possível isolar essa coluna que existem esses caracteres especiais, para que não sejam interpretadas como delimitadores pelo alteryx, fazendo pular colunas e desalinhando o relatório todo.

Obrigado e abraços

Thiago Tanaka

Prezados boa tarde. Espero que estejam bem.

Minha ideia/sugestão vem para aprimoramento da ferramenta "Texto para Colunas"  (Parse), onde podemos delimitar colunas com caracteres de delimitação.

Atualmente, a delimitação não ocorre pro cabeçalho, tendo que ser necessário outros meios para considerar o cabeçalho como uma linha comum, para depois torná-lo como cabelho, ou tratar somente o cabeçalho de forma separada.

Seria interessante que a propria ferramenta de texto para coluna já desse a opção de delimitar a coluna de cabeçalho da mesma forma.

Obrigado e abraços

Thiago Tanaka

It would be absolutely marvellous if the ability to use a field as the replace value could be incorporated into the Regex tool. Currently the "Replacement Text" field is a hardcoded text value, and so to make that dynamic you have to wrap the tool in a batch and feed in the value as a Control Parameter. If we could just select a field to use as the replacement value, that would be spiffy.

M.

Currently I find myself always wanting to replace the DateTime field with a string or visa verse.

It would be nice to have a radio button to pick whether to append the parsed field to replace the current field with the parsed field.

I understand that all you need is a select tool after, this would be a nice QoL change especially where the field may be dynamically updated.