Date
19 Sep
Call-in Information
Time: 10:00 am, Eastern Time (New York, GMT-04:00)
To join the online meeting:
https://lyrasis.zoom.us/j/84378615572?pwd=bGUxSjlyRTdjOGl5U1B6L0Yva3RQdz09
Meeting ID: 843 7861 5572
Passcode: 556561
One tap mobile
+16699006833,,84378615572#,,,,*556561# US (San Jose)
+19292056099,,84378615572#,,,,*556561# US (New York)Dial by your location
+1 669 900 6833 US (San Jose)
+1 929 205 6099 US (New York)
+1 253 215 8782 US (Tacoma)
+1 301 715 8592 US (Washington DC)
+1 312 626 6799 US (Chicago)
+1 346 248 7799 US (Houston)
877 853 5257 US Toll-free
888 475 4499 US Toll-free
Meeting ID: 843 7861 5572
Passcode: 556561
Find your local number: https://lyrasis.zoom.us/u/kerqtGDrJ4
Slack
- https://vivo-project.slack.com
- Self-register at: http://bit.ly/vivo-slack
Attendees
Resources
Agenda
Slack stand-up template
...
...
Notes
20221128
20221130
20221202
20221205
20221207
Notes
20220923
Georgy Litvinov
Dragan Ivanovic
Michel Heon
Benjamin Kampe
- Dragan: We can use https://www.w3.org/International/articles/language-tags/ to implement regions and private usages
- Dragan: I created some SPARQL query, once we defined an ontology to replace that. We need information about language, we don’t have a decision from Ontology group.
Michel: We can store theme, application, key as a property in URI.
Michel: You have to pay attention to the SPARQL query. Sparql is not really powerful, it is better to make multiple properties than try making multiple filters.
I can send you the script I used to create conversion.
Dragan: send it to me by email.
Georgy: The approach to store semantics in URI is not not a good idea, I think Ontology made a decision on that.
Michel : Dragan, you filter labels by the language tag and not using a key.
When you filter in SPARQL you filter by string representing the label. You have to put this label as a language filter of the string you want.
Michel said that ontology is not going to be used by VIVO, but other systems, so we need to consider a simple way to use it with other software. Example: this ontology is VIVO’s but not only VIVO that is going to use this ontology. And editor or value editor or tools that a linguistic person will use: in the structure it is easier to make a clear structure where it is easy to identify errors and expect software to make a job. If we have to make multiple actions to retrieve the information, then it is not good.
You have a tag and a property key, putting themes in a package in a label tag, you have to build.
Dragan: In RDF you have text and language, but application and theme are separated, so it is flexible.
Michel: by convention RDFS label is string associated to the individual, in our case id doesn’t represent key, it represents.
Dragan: Here we have N3 files and this directory copied to the VIVO folder. Is it possible that your generator splits triplets in different files? At the moment it generates everything in one file, I would like to split it into multiple files. One file for one language.
Michel: It is easy to do that, we can do that.
Dragan in rdf/i18n/ you have directories and in those directories you can find menu items for French Canadian. Besides those files you could find other files that would be only for French.
Michel: I don’t think it is a good idea. We would like to remove all language directories.
Dragan: We can have those directories in the home directory.
At the moment people should just copy files and translate files.
Dragan: I noticed that for each key we have the same keys.
Now you have application, key, theme, labels
Michel: We have to have a directory structure where all ftl files are defined. You can merge all files and make a big ontology and make changes inside that or you can make it key by key. If you add a new theme, then 99% is the same, so you don’t have to add ontology language files. But if you have specific ftl files where you have to change the structure of the key, then you will build directory structure and add ftl file into directory structure. For adding a new name we just put ftl file inside directory structure. In the first iteration it is possible to work with the default structure. So if we put the core directory and edit properties one by one, merge them and test if they work properly. So for French Canadian the best way to represent that is “fr” . I am just using this one.
Dragan: If you want to add Finnish translations what should be translated? Every single file for every key?
Michel: I would merge that in TTL and edit that in ttl, I would use that in automatic translation.
Dragan: That won't work without technical persons.
Michel: You need a technical person to do that. In UQUAM I preprocess files for librarians and they work with TTL files. It is just a copy paste in the text editor.
Dragan: we should have a language directory structure in home to load different files.
Michel: suffixes are not needed in TTL files.
Local property files in UQUAM github, not public. The only thing we have to maintain is a mechanism to work with that safely.
If I have specific text for UQUAM
Michel: if I have 10 ways to express something in French, if I want to have my own French translations I don’t want to have multiple files in different directories, I want to see that in one file. In French we have to represent. If you have one file for property.
Dragan: We should decouple VIVO and Vitro applications too into separate files.
Dragan: It should be split in multiple files, we have that option to put all in multiple files. What is the best organization? Is it possible that a translator does that without working with language files without TTL or N3 editing.
How your generator could easily split what collected from VIVO and Vitro, take in mind that Vitro could be run as a separate application.
Georgy how to figure out the application name?
Georgy: I will investigate and let you know.
Benjamin: I started investigating ftl files, I am currently looking through the ~120 ftl files, which doesn’t include i18n prefix, they have hardcoded translations.
Dragan: for German there are 3 flt files, but for French there are a lot of language specific flt files.
My task for Monday is to complete a problem with querying translations.
Michel: I will send you my script and we will take 15 minutes to talk about that.
Dragan: I am going to work on that on Monday, and will see how effective we will be next week.
Brian noted that we have existing users and we would like to retain translations to work for them. This task is a challenge.
We are going to have a meeting on Monday at the same time.
20220928
Participants:
Dragan Ivanovic
Michel Heon
Georgy Litvinov
Benjamin Kampe
Notes
Dragan: https://github.com/vivo-project/Vitro/pull/329 is ready for review
Dragan: There is some issues with converting russian translations in n3 from property files
Georgy: We might want to have some warnings about property files in smoke tests.
Michel: if you see the title here, it is not a real French, we have a gender on Object.
This is for male gender and letter is female. If you go to ftl file you will see another property.
We didn’t change the ftl file for this reason.
With ontology solutions we can have new property, where we could put gender inside property. For French you will use the same ftl file.
Georgy: We should separate translation keys
Dragan: We are going to reuse translations and we would need to create new property keys.
Michel: In my example Film is the other field and in this example it is ok, but not for every case.
In English first letters of titles should be capitalized. But in French it is not. Ritght now we have capitalization. We have two problems in that example.
Dragan: In the same file for Serbian translations it was the same problem.
Dragan: How to find all issues related?
Georgy: Look at localized ftl files and ask native speakers to create tickets for each problem.
Dragan: How many files do we have?
Michel: a lot.
Georgy: When we fix localized files we might want to disable localized ftl files.
Michel: Having translations in ontology is a really good start to solve the problem.
Michel: I am going to make some tests to find issues.
Dragan: Now you use one freemarker template for each form
Georgy: For general cases like this VIVONEWIndividualGenerator we should have two separate texts for this.
Michel: this is a good example, we should start from resolving this type of issue.
Dragan: One of our problems is reorganization of text in freemarker templates and another is reorganization of properties.
Next meeting is on Friday.
20220930
Participants
Michel Heon
Georgy Litvinov
Dragan Ivanovic
Mark Vanin
Agenda
Ontology
Generator
Notes
Dragan: The ontology should be in the Vitro too.
Christian suggested that skos:prefLabel shouldn’t be used. I have some comment. I need just key, so I could use
Package is an application.
Dragan: This came from a property package. You have some properties that came from the Vitro. But for some properties that came from Vitro we should enable that.
We have a couple of dillemas: we need to decide about properties and then names for properties.
Michel: skos:prefLabel is a reference where the individual points to, this individual corresponds to the property key. Rdfs:label is reserved to describe the individual itself?
We should reuse properties.
Dragan: If we have name individual represents.
Michel: with prefLabel we are able to resolve that
Discussion about prefLabel vs rdfs:label vs custom data property postponed to next week.
Michel is going to prepare an example.
Dragan: I am looking where it is applied.
One day vivo-languages and vitro-languages going to be merged to vivo and vitro
Dragan: Michel will try to prepare materials to align our efforts. I am worried that we won't have support.
Michel: If somebody has a better solution they can propose and we will do it for the next 10 years. I am not doing politics, we just have to do that.
Dragan: It is a very good work, we should arrange it somehow.
...
...