A few general comments:

1. There are some commits in the history that I don't understand. What does test: update based on change mean? It is very general.... Also, "delete tunes.csv". I don't see any change to "tunes.csv".

I'm thinking if we see two continuous commits, the test output is changed based on the previous commit.

2. If you are going to infer these types of data types element by element, then I think it needs to be documented somewhere that when reconciling, you need to put geographic data in this format and date-time data in the other format.

They are documented in the reconciliation process.

3. What do you think about the fact that we are essentially inferring data type on an element by element basis rather than a column by column basis? Are there situations where two elements in the same column will have different data types? Probably out of scope for this PR, but the more different types of inferences that you are doing based on some pretty contingent things (for example, could there be a non-geo data element that just happens to begin with "Point("?), the more I feel like this should be done on a column by column basis.

We format the coordinates in the reconciliation process, I think it's standardized.

I'm thinking if we see two continuous commits, the test output is changed based on the previous commit.

The best practice would be to reference the commit: test: update out_rdf.ttl based on cf33751

They are documented in the reconciliation process.

Where? Since this script applies to all DB's, then this kind of thing should be in documentation for this script.

We format the coordinates in the reconciliation process, I think it's standardized.

I don't think this addresses my question. Is there going to be a situation where the output of the reconciliation process (in other words, the reconciled csvs) has a single column with multiple data types?

They are documented in the reconciliation process.

Where? Since this script applies to all DB's, then this kind of thing should be in documentation for this script.

Right now the only place where we have to format datetime and coordinate is in The Sessions DB, so I assume this is a 1/4 chance.

We format the coordinates in the reconciliation process, I think it's standardized.

I don't think this addresses my question. Is there going to be a situation where the output of the reconciliation process (in other words, the reconciled csvs) has a single column with multiple data types?

One column will always be one single type. I can change the .startwith to another pattern matching. I think that processing by column would be extra work for the operator, where we have to indicate the columns with their types manually? Therefore I assume that pattern matching would be simpler.
One of my idea that we can process by column is that we apply pattern matching to the entire column to ensure that the column is the same type. But this would take too much resources to check.

One column will always be one single type. I can change the .startwith to another pattern matching. I think that processing by column would be extra work for the operator, where we have to indicate the columns with their types manually? Therefore I assume that pattern matching would be simpler.
One of my idea that we can process by column is that we apply pattern matching to the entire column to ensure that the column is the same type. But this would take too much resources to check.

Ok, yes... let's not worry about it now. But wanted to know. Thanks!

Right now the only place where we have to format datetime and coordinate is in The Sessions DB, so I assume this is a 1/4 chance.

I'm not sure what you mean by 1/4 chance. There will be other databases, though, so I would put this in the README for this script.

I'm not sure what you mean by 1/4 chance. There will be other databases, though, so I would put this in the README for this script.

I work mainly on 4 different databases, and only The Session needs reformat. That's where 1/4 comes from.

One column will always be one single type. I can change the .startwith to another pattern matching. I think that processing by column would be extra work for the operator, where we have to indicate the columns with their types manually? Therefore I assume that pattern matching would be simpler.
One of my idea that we can process by column is that we apply pattern matching to the entire column to ensure that the column is the same type. But this would take too much resources to check.

Ok, yes... let's not worry about it now. But wanted to know. Thanks!

Right now the only place where we have to format datetime and coordinate is in The Sessions DB, so I assume this is a 1/4 chance.

I'm not sure what you mean by 1/4 chance. There will be other databases, though, so I would put this in the README for this script.

My mistake, but many recordings and authors have integers as their names. I would have to consider these instances

My mistake, but many recordings and authors have integers as their names. I would have to consider these instances

Can you give us some examples where "recordings and authors have integers as their names"?

My mistake, but many recordings and authors have integers as their names. I would have to consider these instances

No mistake...just something to think about. Since the csv2rdf/csv2rdf_single_subject.py script is designed for use across all the databases, then it should be documented somewhere for all the databases that we are assuming a canonical datetime format. That way, if we add another database with a different date time format, we know immediately that one of the transformations we need to apply is to the datetime.

I think recordings and authors having integers in their name is a big reason why we want to do this inference of type at the column level, rather than the individual cell level. You'd have to have a recording with a pretty specific title to be caught up in this, of course, but since we already know that the whole column will have the same data type, it seems cleaner just to go ahead and use that knowledge rather than one day have a weird and hard-to-find bug because someone decided to name their some "Point(1,2)" or something.

My mistake, but many recordings and authors have integers as their names. I would have to consider these instances

Can you give us some examples where "recordings and authors have integers as their names"?

This is a recording, it's artist is "1651", which is recognized as an integer in the RDF since it does not have quotes.

<https://thesession.org/recordings/3720> a <http://www.wikidata.org/entity/Q49017950> ;
    ns3:Artist <https://thesession.org/recordings/artists/2112>,
        1651 ;

My mistake, but many recordings and authors have integers as their names. I would have to consider these instances

No mistake...just something to think about. Since the csv2rdf/csv2rdf_single_subject.py script is designed for use across all the databases, then it should be documented somewhere for all the databases that we are assuming a canonical datetime format. That way, if we add another database with a different date time format, we know immediately that one of the transformations we need to apply is to the datetime.

I think recordings and authors having integers in their name is a big reason why we want to do this inference of type at the column level, rather than the individual cell level. You'd have to have a recording with a pretty specific title to be caught up in this, of course, but since we already know that the whole column will have the same data type, it seems cleaner just to go ahead and use that knowledge rather than one day have a weird and hard-to-find bug because someone decided to name their some "Point(1,2)" or something.

Ok. Do you think that there should be some user-defined variables that specifies the type of each column? Or should it be automatically recognized?

@candlecao Why are you committing to this branch? If the changes you are making need to be committed to the repo, please make another branch and pull request.

@candlecao Why are you committing to this branch? If the changes you are making need to be committed to the repo, please make another branch and pull request.

Ok, got it. I will be careful next time. I can give up my committing on the branch this time. Thanks.