Schema could not be saved - "Your schema is incomplete so it cannot be saved yet"

[Iñaki LL]

Hi again, I attempted to save a simple dataset (two rows) before upload to Wikidata. There were a number of issues appearing in the Issues tab, but they vanished and I cannot see them right now. One of them cited the need for references, which is informative. (Would not be enough to add a common reference to the source of the dataset on one of the statements, say "Title of the work" or "Publication"?)

I attempted to save what I had, but I was prevented from doing it. I got this message: "Your schema is incomplete so it cannot be saved yet". At this point, I am pretty lost. See capture attached. Any hints welcome!

Regards

Iñaki

[Owen Stephens]

Just based on the screenshot I can see you have added an Alias property to the schema but not populated it - that could be the problem?

Owen

[Iñaki Lopez de Luzuriaga]

I lost the schema (I would build it again), but I don't think so, because I remembered having attempted also adding the alias. Could it be related to the stage of the process I fill the data in, like adding the Term Description or P31 at the schema and not before?

Iñaki

Hau idatzi du Owen Stephens (ow...@ostephens.com) erabiltzaileak (2022 mar. 25, or. (09:25)):

--
You received this message because you are subscribed to a topic in the Google Groups "OpenRefine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openrefine/oOSg-0MelBQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openrefine+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openrefine/07f29089-a045-48cc-896a-1a69e590ce66n%40googlegroups.com.

[Owen Stephens]

I don't think the order you add things will make a difference as long as all the necessary data is present in the schema

If you can recreate the error and share the project with the error in it then I can have a look and see if I can work out the problem.

Owen

[Iñaki Lopez de Luzuriaga]

Hi Owen, here you are the project and the capture of the final message attached ("Your schema is incomplete and could not be saved") if you could give it a look. Appreciated

Iñaki

Hau idatzi du Owen Stephens (ow...@ostephens.com) erabiltzaileak (2022 mar. 28, al. (17:44)):

To view this discussion on the web visit https://groups.google.com/d/msgid/openrefine/bec7bcbe-a97d-474c-ab57-d3d2fe8db6edn%40googlegroups.com.

[Owen Stephens]

Hi Iñaki,

Using your project as long if I add an 'alias' field the schema but don't fill it in (as in your screenshot) then I get the same error message as you. However if I put some text in  the Alias, the schema saves without a problem. I think you said you'd already tried this, but this is the only thing that currently makes sense to me - can you check again?

I also note that you've reconciled the "Date of publication" column to point at a Wikidata entity for the year - I don't think this will work, as the date of publication property in wikidata expects a string in a valid date format, not a pointer to a wikidata entry - so I think you'll need to remove the reconciliation data from that column and just make sure you have a valid date string in there (i.e. yyyy, yyyy-MM or yyyy-MM-dd)

Best wishes

Owen

[Iñaki LL]

I added a variation of the description in the Alias to try the way you did it. However, it does not make sense for the real content, since the Term Alias refers to each title of the dataset.

On the "Date of publication", as you could check yourself, it was reconciled to calendar year. This is what I am also doing with a larger dataset now, based on text type values in the cells. I understand that the calendar year proposed in the corresponding reconciliation window. Would not that be the right type for Date of publication, i.e. YYYY?

Iñaki

2022(e)ko martxoakren 31(a), osteguna (12:11:41 (UTC+2)); Owen Stephens erabiltzaileak hau idatzi zuen:

[Iñaki LL]

* I understand that the calendar year proposed in the corresponding reconciliation window is YYYY. Would not that be the right type for Date of publication, i.e. YYYY?

2022(e)ko martxoakren 31(a), osteguna (12:55:07 (UTC+2)); Iñaki LL erabiltzaileak hau idatzi zuen:

[Owen Stephens]

Hi Iñaki

On 31 Mar 2022, at 11:55, Iñaki LL <inaki.l...@gmail.com> wrote:

I added a variation of the description in the Alias to try the way you did it. However, it does not make sense for the real content, since the Term Alias refers to each title of the dataset.

What should go in the Alias from the project? (i.e. which column?)

On the "Date of publication", as you could check yourself, it was reconciled to calendar year. This is what I am also doing with a larger dataset now, based on text type values in the cells. I understand that the calendar year proposed in the corresponding reconciliation window. Would not that be the right type for Date of publication, i.e. YYYY?

I’m not completely sure (maybe someone who knows the interaction better can comment) but you are reconciling a value like 1814 to the Wikidata entity https://www.wikidata.org/wiki/Q6943. However the “Publication date” property in Wikidata (P577)  expects a date string (you can, not a pointer at a Wikidata entity - so I don’t think you will be successful if you have the value reconciled to the Wikidata entry. If you look at the "Wikidata property examples" at https://www.wikidata.org/wiki/Property:P577 you’ll see that the dates given don’t link to any other Wikidata entity, but are rather just the year expressed as a string of digits

Best wishes

Owen

You received this message because you are subscribed to the Google Groups "OpenRefine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrefine+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openrefine/8d5c2a84-97fd-44f0-aa9f-3c72d9caa72dn%40googlegroups.com.

[Iñaki LL]

2022(e)ko martxoakren 31(a), osteguna (13:02:40 (UTC+2)); Owen Stephens erabiltzaileak hau idatzi zuen:

Hi Iñaki

On 31 Mar 2022, at 11:55, Iñaki LL <inaki.l...@gmail.com> wrote:

I added a variation of the description in the Alias to try the way you did it. However, it does not make sense for the real content, since the Term Alias refers to each title of the dataset.

What should go in the Alias from the project? (i.e. which column?)

There is no Alias column. So I understand that an Alias column in the project would be mandatory? 

On the "Date of publication", as you could check yourself, it was reconciled to calendar year. This is what I am also doing with a larger dataset now, based on text type values in the cells. I understand that the calendar year proposed in the corresponding reconciliation window. Would not that be the right type for Date of publication, i.e. YYYY?

I’m not completely sure (maybe someone who knows the interaction better can comment) but you are reconciling a value like 1814 to the Wikidata entity https://www.wikidata.org/wiki/Q6943. However the “Publication date” property in Wikidata (P577)  expects a date string (you can, not a pointer at a Wikidata entity - so I don’t think you will be successful if you have the value reconciled to the Wikidata entry. If you look at the "Wikidata property examples" at https://www.wikidata.org/wiki/Property:P577 you’ll see that the dates given don’t link to any other Wikidata entity, but are rather just the year expressed as a string of digits

O my... Ok, I hope this does not take very long to change (calendar year > P577). I see in P577 that it also allows for a whole century, like 1900s. Eventually, I converted not available cells ([s.a.] in Spanish/Latin, or sine anno) into null type cells.  

[Iñaki LL]

* Eventually (in my main project)

2022(e)ko martxoakren 31(a), osteguna (13:20:40 (UTC+2)); Iñaki LL erabiltzaileak hau idatzi zuen:

[Owen Stephens]

On 31 Mar 2022, at 12:20, Iñaki LL <inaki.l...@gmail.com> wrote:

2022(e)ko martxoakren 31(a), osteguna (13:02:40 (UTC+2)); Owen Stephens erabiltzaileak hau idatzi zuen:

Hi Iñaki

On 31 Mar 2022, at 11:55, Iñaki LL <inaki.l...@gmail.com> wrote:

I added a variation of the description in the Alias to try the way you did it. However, it does not make sense for the real content, since the Term Alias refers to each title of the dataset.

What should go in the Alias from the project? (i.e. which column?)

There is no Alias column. So I understand that an Alias column in the project would be mandatory? 

No not at all - but you shouldn’t add an Alias field to the schema if you don’t have anything to put in it - just remove it from your schema completely

 I see in P577 that it also allows for a whole century, like 1900s.

Yes it does - but see my previous comments on this - this is done by setting the ‘precision’ on the property - which as far as I know you cannot do via the OpenRefine schema - you would have to do this via Quickstatements (or directly by editing in Wikidata)

Eventually, I converted not available cells ([s.a.] in Spanish/Latin, or sine anno) into null type cells.   

As per my previous comments - this isn’t something you can populate into the publication date property. You can set the property as ‘unknown value’ - but firstly not via OpenRefine (again Quickstatements supports this, or directly on Wikidata) and secondly unless it is truly not known (i.e. it has been established to a high degree that no-one knows this) then you would normally just omit the property (there are many things you might not know about the book, but you don’t set a property for each one!) The ’unknown value’ is meant for things that are not just unknown to you or a single data source, but genuinely not known to anyone - generally I’d be very cautious about using it and I think I already linked to some information about using this.

Best wishes

Owen

To view this discussion on the web visit https://groups.google.com/d/msgid/openrefine/5dd48cfa-3027-4bb1-bf0b-df6649c765d8n%40googlegroups.com.

[Iñaki LL]

2022(e)ko martxoakren 31(a), osteguna (13:43:39 (UTC+2)); Owen Stephens erabiltzaileak hau idatzi zuen:

On 31 Mar 2022, at 12:20, Iñaki LL <inaki.l...@gmail.com> wrote:

2022(e)ko martxoakren 31(a), osteguna (13:02:40 (UTC+2)); Owen Stephens erabiltzaileak hau idatzi zuen:

Hi Iñaki

On 31 Mar 2022, at 11:55, Iñaki LL <inaki.l...@gmail.com> wrote:

I added a variation of the description in the Alias to try the way you did it. However, it does not make sense for the real content, since the Term Alias refers to each title of the dataset.

What should go in the Alias from the project? (i.e. which column?)

There is no Alias column. So I understand that an Alias column in the project would be mandatory? 

No not at all - but you shouldn’t add an Alias field to the schema if you don’t have anything to put in it - just remove it from your schema completely

Good to know! (Wikidata provides a default term field to fill in) Thanks

 I see in P577 that it also allows for a whole century, like 1900s.

Yes it does - but see my previous comments on this - this is done by setting the ‘precision’ on the property - which as far as I know you cannot do via the OpenRefine schema - you would have to do this via Quickstatements (or directly by editing in Wikidata)

Good

Eventually, I converted not available cells ([s.a.] in Spanish/Latin, or sine anno) into null type cells.   

As per my previous comments - this isn’t something you can populate into the publication date property. You can set the property as ‘unknown value’ - but firstly not via OpenRefine (again Quickstatements supports this, or directly on Wikidata) and secondly unless it is truly not known (i.e. it has been established to a high degree that no-one knows this) then you would normally just omit the property (there are many things you might not know about the book, but you don’t set a property for each one!) The ’unknown value’ is meant for things that are not just unknown to you or a single data source, but genuinely not known to anyone - generally I’d be very cautious about using it and I think I already linked to some information about using this.]

My thought on this is that the unknown date is somewhat tricky in this case, but for practical reasons I decided to take the null option, along the lines of your comments. This is bibliography, and it is not about whether we know the date or not; the information provided refers directly to an annotation by the librarian. That is what I understand, it is all a matter of subtle nuance. Therefore, the [s.a.] "sine anno"  would refer us to the information added by the librarian to the publication's entry, not to our external knowledge/information on the publication.

[Iñaki LL]

Following up from the post above. The only type of values proposed on reconciliation for date of publication  (Q1361758) seem to be either calendar year or natural number. So at this stage would natural number be a better option than calendar year? I am lost here to be honest. Thanks

Iñaki

2022(e)ko martxoakren 31(a), osteguna (15:54:25 (UTC+2)); Iñaki LL erabiltzaileak hau idatzi zuen:

[Owen Stephens]

You should not be reconciling data to populate the date of publication - the date of publication property requires a correctly formatted string not a reconciled value. That is to say - it needs a string like "1841" not a pointer to the wikidata entity https://www.wikidata.org/wiki/Q7622 - so basically don't reconcile this column at all

Owen

[Iñaki LL]

Unfortunately just strings w/o reconciliation did not work for me. Best regards

Iñaki

2022(e)ko apirilakren 4(a), astelehena (17:09:42 (UTC+2)); Owen Stephens erabiltzaileak hau idatzi zuen:

[Owen Stephens]

On Monday, April 4, 2022 at 6:09:09 PM UTC+1 Iñaki LL wrote:

Unfortunately just strings w/o reconciliation did not work for me. Best regards

 

I don't know if anyone else can comment but my understanding is that it would be impossible to set the Publication Date property to a value other than a valid date - so reconciled values just won't work (as I understand it).

If anyone else knows differently please comment as I don't want to be mis-informing Iñaki (and others) in my response

Owen

 

[Antoine Beaubien]

I’ve read parts of this thread, and though I can’t comment on this specific issue, I must say that I did have through time a lot a problem with Wikidata schema and errors. I didn’t yet do some bug reports because I found it hard to describe a repeating pattern to trigger an error.

But, I know that if you rename a column, it doesn’t get updated in the schema right away…

But a lot of other small issues. They would all go away if I took time to rebuild the schema…

Sorry to not be more helpful, but I just wanted to give Iñaki LL a bit of « solidarity time ». I feel you, Iñaki LL. ;-)

Regards, 

   Antoine

--

You received this message because you are subscribed to the Google Groups "OpenRefine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrefine+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openrefine/96a65a60-4721-4f6b-88d7-fde5c766bc39n%40googlegroups.com.

[Antoine Beaubien]

Iñaki, I've just create a Feature Request so that we have a better error message when we can't save the schema.

Owen, if you can give a look at it and see if it’s well done or pinpoint me possible improvements.

Please vote for it in order to show you share the same need. If you want, you can add information about your current problem or other changes.

https://github.com/OpenRefine/OpenRefine/issues/4724

Regards,

   Antoine

[Antoine Beaubien]

Iñaki,

You wrote on GitHub:
>This is not my worst issue right now with OpenRefine, the worst being I cannot upload the project despite progress starting, but actually blocked (see the googlegroups conversations). 

by « Upload », you mean to Wikidata?
Yes, its seams that you ALSO have a date format problem.

Can you share a small data set, and, why not, an export of your schema in JSON?

Regards,

   Antoine

Le lundi 4 avril 2022 à 13 h 09 min 09 s UTC-4, Iñaki LL a écrit :

Unfortunately just strings w/o reconciliation did not work for me. Best regards

Iñaki

2022(e)ko apirilakren 4(a), astelehena (17:09:42 (UTC+2)); Owen Stephens erabiltzaileak hau idatzi zuen:

You should not be reconciling data to populate the date of publication - the date of publication property requires a correctly formatted string not a reconciled value. That is to say - it needs a string like "1841" not a pointer to the wikidata entity https://www.wikidata.org/wiki/Q7622 - so basically don't reconcile this column at all

Owen

On Thursday, March 31, 2022 at 3:34:23 PM UTC+1 Iñaki LL wrote:

Following up from the post above. The only type of values proposed on reconciliation for date of publication  (Q1361758) seem to be either calendar year or natural number. So at this stage would natural number be a better option than calendar year? I am lost here to be honest. Thanks.

[Iñaki LL]

Hi Antoine, I think I posted a message, but went astray. I posted a wrong link in GitHub, so here you are the open thread, where I follow up. Best regards

Iñaki

2022(e)ko apirilakren 9(a), larunbata (11:45:52 (UTC+2)); ant...@beaubien.qc.ca erabiltzaileak hau idatzi zuen: