Temporary: remove langString

[elf-pavlik]

Currently data only had @en language tags. Also to my knowledge online forms don't allow selecting language tags.

The main reason is that shacl2shex currently doesn't support sh:or, so when I generate LDO types it just drops all the propeties which have xsd:string | rdf:langString.

#20 tracks i18n for names and we should also track other strings we would like to support.

I would expect that by the time we have proper i18n support for the catalog we should also resove issues with generating LDO types. Either by improving shacl2shex or LDO supporting SHACL directly o-development/ldo#25

[elf-pavlik]

@jeff-zucker do you know how did my name get @en tag?
Nothing important just wondering where it was assigned this way. Does your form add set it to any text input?

[jeff-zucker]

The form does add @en to some strings. However, since your record does not have an ex:modified field, it was not submitted via a form unless you later erased the ex:modified field. So I don't have any idea how it happened. Will the SHACL object to the @en after your PR? If so, I guess I can erase them all and remove the part of the script that adds them.

[elf-pavlik]

This PR has two commits, first one changes shapes and the second one removes all the @en tags from the data so valiations still pass. If you are ok with this temporary removal of language tags you would just need to update your forms not to add it.

[jeff-zucker]

Yes, good, I'll remove it from the scripts.

[pmcb55]

Hi @jeff-zucker and @elf-pavlik - I'm just curious (seriously, I REALLY am JUST curious)...

The reason I'm curious is merely in trying to understand your respective prespectives on the 'semantics' (yuk, I hate that word generally (i.e., if ever talking with lay-people - i.e., people who 'have-never-heard-of' or 'have-no-interest-in' RDF), but given you're both RDF-heads, what might your shared understanding of the semantics of 'ex:name' actually be?

I ask merely because, as an Irish native, I officially have multiple 'official'/'authorative' forms of both my 'first name' (whatever 'first name' 'means', i.e., just ask an Icelandic person), and my 'sur name ' (e.g., I can officially use 'Pat'@en, 'Patrick'@en, 'Padraig'@'ga', or 'Padraic'@en as my 'first' or 'given' 'name', and I can use 'McBennett'@en, or 'MacBeneid'@ga as my official 'family name' or 'sur**name**')...?

Anyway, I don't mean to be in any way antagosnistic or negative, but in very simple terms, I just believe any notion of automatically applying, or removing, language tags to instances of any vocab term just seems hugely problamatc to me (i.e., I'd just never do it!).

But, of course, that does leave the remaining open question of what semantics ARE you trying to convey, even to 'simple'/apparently-unambiguous example terms, such as your 'ex:name' term?

In fact, I think this is a perfect example of how 'seemingly simple' notions like merely 'naming' someone, is actually frought with inherent, real-world, unavoidable complexity and ambiguity - which is PRECISELY WHY we need something as flexible and expressive as RDF as the basis for our 'reality modelling' in the first place (so obviously I'm definitely in your camp here generally!).

Personally, I think that the very best articulation that I've yet come across of how to effectively tackle this 'intuitively simple' notion of 'naming' something is how Semantic Arts finally got around to (after much encouragement on my part!) modelling the (apparently!) super-simple notion of an 'Address': https://www.youtube.com/watch?v=AoEZAIeBlQo

In other words (in my attempt to 'come with answers, not problems'), I'd just personally avoid 'ex:name' in any examples ('cos it's just so overloaded and actually (in the real-world) 'complex' semantically (at least outside any myopic 'North American' or 'England-only' mindsets)), or else just adopt a very precisely defined definition of 'name', such as that offered by DPV (which (I assume!) at least tries to confirm to EU/GDPR-regulation-defined semantics regarding the meaning of a person's 'name').

[elf-pavlik]

Hi @pmcb55

I'm considering our current placeholder ex:name as rather generic, which can accomodate full name, nickname or whatever one chooses to label something (including themselves). When it comes to personal names I find this W3C article very hepful https://www.w3.org/International/questions/qa-personal-names.en

Anyway, I don't mean to be in any way antagosnistic or negative, but in very simple terms, I just believe any notion of automatically applying, or removing, language tags to instances of any vocab term just seems hugely problamatc to me (i.e., I'd just never do it!).

👍 Besides removing existing language tags in this PR, @jeff-zucker also adjusted his forms not to automatically add them.
While I see value in using language tags, I think we should be more strategic about it. Your input is very welcome and we could either use #20 or crate more issues to track it. Closed PR is sub-optimal to track future work IMO

I didn't have chance to watch the video you linked (1h), I'll try to ingest it later this week to be able to understand your comment better.

[jeff-zucker]

I just believe any notion of automatically applying, or removing, language tags to instances of any vocab term just seems hugely problamatc

I don't think any of us have an intention to automatically apply language tags. My early scripts did that inadvertantly in some cases but they no longer do. When we develop fuller support for localization, we will presumably have forms that support user-chosen language tags.

what semantics ARE you trying to convey, even to 'simple'/apparently-unambiguous example terms, such as your 'ex:name' term?

My opinion: ex:name is a field whose prompt could be "how do you want to identify yourself or identify this product or service?". This does not expect or require any outside reference as to the nature of that identifier. Currently we have first names, last names, both first and last names, internet handles, nicknames, and other kinds of identifiers. When we can develop support for localization, I think it is important to support localized forms of names. This is especially true of products and services. For exmaple, "मनस्" is an appropriate identifier for locales which use the Devanagari script and "Manas" for locales using Roman script. A product's identifier should be expressable in all contexts in which it might occur.

[elf-pavlik]

Small nit pick, I would think of it as labels rather than identifiers, actually pretty close to concept of label in RDFS and SKOS. Also our ex:name seems pretty similar to schema:name

The name of the item.
Canonical URL: https://schema.org/name
Equivalent Property: dcterms:title

EDIT it also fits @jeff-zucker suggestion of dcterms:title in #21