WordNet-LMF formats
Home Page: https://globalwordnet.github.io/schemas/
Read the documentation here
index.html is constructed with PanDoc
pandoc -t html -H template/header -A template/afterbody -B template/beforebody --shift-heading-level-by=-1 index.md > index.html
wn.rdf is generated from the Turtle with Rapper
rapper -i turtle -o rdfxml-abbrev wn.ttl > wn.rdf
The link to W3C OntoLex Model should be https://www.w3.org/2016/05/ontolex/ in the https://globalwordnet.github.io/schemas/#rdf section.
It would be good to have tagged release with the 1.0 DTD (the version we are using for LiLT) and then maybe start a new file (WN-LMF-1.1.dtd) for the new DTD, so that people are not surprised by changes.
The Morphosemantic Database in https://wordnet.princeton.edu/download/standoff-files defines a set of semantic relations associated with derivationally related words. Some of these relations can be mapped to the current relations in the DTD and https://globalwordnet.github.io/schemas/ or https://globalwordnet.github.io/gwadoc/ but some are missing (e.g. bodyPart). Can we add the missing one in the DTD?
On the schemas page, the descriptions for both pairs are exactly the same:
A relation between two concepts where concept B comes into existence as a result of concept A.
A relation between two concepts where concept A comes into existence as a result of concept B.
Yet in the the more extensive docs the entries for causes, is_caused_by, involved_result, and result do seem to have semantically distinguishable (but similar) meanings.
I guess the descriptions for causes and is_caused_by are the most "wrong" on the schemas page as they differ more significantly from the descriptions in the GWA docs.
Currently the order of Definition and SynsetRelation is specified in the DTD. This seems unnecessary.
If in the DTD a “&” is used instead of a “,”, that would allow a different order.
The order of the words within a synset is not specified in the format, however this is important information that many wordnets have. I would propose adding a new tag Member in the Synset that indicates the order of the words in the synset.
For example:
<Synset id="ewn-02327239-n" ili="i47769" partOfSpeech="n">
<Definition>(usually informal) especially a young rabbit</Definition>
<SynsetRelation relType="hypernym" target="ewn-02326697-n"/>
<Member>bunny</Member>
<Member>bunny rabbit</Member>
</Synset>See: https://github.com/globalwordnet/schemas/blob/master/index.html#L420
It is missing a c, should be ontolex:LexicalConcept.
Hi,
we would like to point out that according to the current definition of the property wn:partOfSpeech (which has domain ontolex:LexicalEntry), synsets with parts of speech are inferred to be of type lexical entry. This means for example that they have to have at least one lexical form which does not make sense with synsets....
Cheers,
Andrea and Fahad
In the DTDs, a LexicalEntry have an identifier defined as https://github.com/globalwordnet/schemas/blob/master/WN-LMF-1.1.dtd#L35
The type ID, https://www.w3.org/TR/REC-xml/#id, is quite restricted and can potentially be an issue for words in other languages with accents, etc. Nevertheless, I do want to preserve the legibility and avoid creating extra artificial ids. Ideally, I would like 1-1 relation with the URI used in the RDF encoding. But we can use % scape in URIs. Any idea?
This is used in the DTDs, and we have a page for it here:
https://github.com/globalwordnet/schemas/tree/master/dc
but it is not being added to the github-pages.
Many (some) projects have logos, and these can be useful to display as visual representations. Can we add a logo to the meta data?
Strictly speaking, this is not an issue but tentative proposals, open for discussion.
Here they go:
1 - It is appropriate to distinguish between core levels and extensions
2 - The core level should define
- the core contents of a word net
- possibly an extension mechanism, but not the extensions themselves
3 - The core level should deal only with stand-alone internal coherence and well-formedness. It excludes external references to external databases. Internal references should be checked.
4 - Extensions are permissible and should have their own namespace. They can deal with external reference. They are responsible for their own validation.
5 - Each extension should provide a strip-down mechanism that produces core-conformant data, in effect stripping down non-core data.
This can be easily done with each extension providing an XSLT transform script "to_core.xsl" that, when invoked, will filter non-core data away.
Invocation can then be triggered by simply including this in the XML header:
<?xml-stylesheet type="text/xsl" href="to_core.xsl"?> or passing the XSLT to DOM builders.
The WN-LMF 1.0 DTD allows 14 of the 15 Dublin Core elements as attributes (setting aside the attribute vs element thing (#5) for a moment) on many LMF elements. The missing one is dc:language. Some of the LMF elements have their own language attribute, but not all that allow Dublin Core metadata.
Is there a reason for this situation? Can we just add in dc:language and use that instead of the default namespace's language attribute?
We have non-English wordnets that build on an existing wordnet (generally PWN). For instance, the Japanese Wordnet is built on top of PWN 3.0's synsets and relations but contributes lemmas, definitions, and examples (here in an older LMF variant retrieved from http://compling.hss.ntu.edu.sg/wnja/index.en.html):
<LexicalResource>
<GlobalInformation label="Japanese WordNet 1.1 by NICT"/>
<!-- produced on 2010-10-22 -->
<Lexicon languageCoding='ISO 639-3' label='Japanese Wordnet' language='jpn' owner='NICT' version='1.1'>
<LexicalEntry id ='w239520'>
<Lemma writtenForm='夜半' partOfSpeech='n'/>
<Sense id='w239520_15168185-n' synset='jpn-1.1-15168185-n'/>
<Sense id='w239520_15167027-n' synset='jpn-1.1-15167027-n'/>
</LexicalEntry>
...
<Synset id='jpn-1.1-15168185-n' baseConcept='3'>
<Definition gloss="夜の12時。夜中。">
<Statement example="幼い子供が真夜中まで起きているのを許されるべきではない"/>
</Definition>
<SynsetRelations>
<SynsetRelation targets='jpn-1.1-15228378-n' relType='hype'/>
<SynsetRelation targets='jpn-1.1-15167027-n' relType='hprt'/>
</SynsetRelations>
</Synset>While I'm not certain of details like how these IDs map to PWN synsets, my point is that there is no explicit encoding of the dependency on PWN 3.0, and I don't see it in the DTD for the current LMF, either. Let's pretend the DTD has something like this:
<!ELEMENT Lexicon (Require*, LexicalEntry+, Synset*)>
...
<!Element Require EMPTY>
<!ATTLIST Require
lexicon NMTOKEN #REQUIRED
version CDATA #REQUIRED>
This would allow something like:
<Lexicon id="jwn" ...>
<Require lexicon="ewn" version="2020" />
...I'd like for this to extend to other kinds of extensions, too. For instance, we could extract all taboo words or scientific names into wordnet "layers" that can enabled or disabled as needed.
Why don't we add syntactic behavior to senses (and possibly synsets), which is where it is in PWN.
It should not be on the lexical entry, ...
We are looking to add some pronunciation information to English WordNet and it would be good to add this as a schema extension. As I see it we would need to have the following information
As such, I would suggest something like as follow:
<LexicalEntry id="ewn-transport-n">
<Lemma writtenForm="transport" partOfSpeech="n">
<Pronunciation notation="ipa" dialect="GB" notes="RP">/tɹænzˈpɔːt/</Pronunciation>
<Pronunciation notation="ipa" dialect="GB" notes="RP">/tɹɑːnˈspɔːt/<Pronunciation>
<Pronunciation notation="ipa" dialect="US" notes="GenAM">/tɹænzˈpɔɹt/</Pronunciation>
</Lemma>
<Sense>...</Sense>
</LexicalEntry>Do we need a separate attribute for sense keys or is ID sufficent?
Why partOfSpeech is an attribute of the Lemma and not an attribute of lexicalEntry?
The following wordnet pointers don't appear to have entries (relType) in the DTD:
| pointer | string in the wndb2lmf converter |
|---|---|
$ |
verb_group |
;u |
domain_usage |
-u |
missing |
We may consider some previous definitions from https://github.com/own-pt/openWordnet-PT/blob/master/wn30.ttl? See constraints on the relations.
Please check and add a definition.
I just implemented WN-LMF as a new export format for DanNet to be queried using goodmami/wn.
Limiting myself to the relations defined directly by GWA is fine (it is a limited format, after all), however, I also ran into an issue where elements without a corresponding ILI key resulted in a failed import of the DanNet dataset in the goodmami/wn library.
I tracked the issue back to here where the various WN-LMF.dtd files state:
<!ATTLIST Synset
id ID #REQUIRED
ili CDATA #REQUIRED
... >I must say that I find this requirement to be a quite limiting.
Why should a WordNet be fully linked to the ILI to be valid as WN-LMF...? AFAIK only the English WordNet fits this requirement and only because (and correct me if I'm wrong here) the CILI is essentially just the repurposed, core structure of the Princeton WordNet.
I suggest that this requirement be scrapped entirely.
IMO the definition of exemplifies is not clear and makes me think of a hyponym/hypernym relation.
exemplifies
rdfs:comment
A relation between two concepts where B is a type of concept A
is_exemplified_by
rdfs:comment
A relation between two concepts where A an example of the type B
Cf. also "example for vs. example of".
Compare the definitions given on the github page:
exemplifies: Indicates the usage of this word
is_exemplified_by: Indicates a word involved in the usage described by this word
In order to understand I looked at some examples, e.g.
"hence" exemplifies "archaism, archaicism"
"archaism, archaicism" is_exemplified_by "hence"
IMO this relation would be easier to understand if we put it like this:
has_example
A relation between two concepts A and B where A has example B.
is_example_for
A relation between two concepts A and B where A is an example for B.
Example:
"hence" is_example_for "archaism, archaicism"
"archaism, archaicism" has_example "hence"
The wn30.xml from https://github.com/bond-lab/omw-data/tree/main/wns/pwn30 has similar used in place of verb_group that is documented in https://globalwordnet.github.io/schemas/. The DTD files do not contain the verb_group:
<Synset id="pwn-02136271-v" ili="i32435" partOfSpeech="v" dc:subject="verb.perception">
<Definition >to throw or bend back (from a surface); "Sound is reflected well in this auditorium"</Definition>
<SynsetRelation relType="domain_topic" target="pwn-06094774-n" />
<SynsetRelation relType="similar" target="pwn-02136533-v" />
<SynsetRelation relType="hyponym" target="pwn-02136533-v" />
<SynsetRelation relType="hyponym" target="pwn-02766925-v" />
</Synset>The dc: attributes are defined as elements not attributes by Dublin Core so that any attempt to validate against this external reference will fail. How to see this ?
The namespace URL http://purl.org/dc/elements/1.1/ redirects to
http://dublincore.org/specifications/dublin-core/dcmi-terms/2012-06-14/?v=elements
This page maps the URL to a schema location and contains the following:
Target namespace: http://purl.org/dc/elements/1.1/
Schema location: http://dublincore.org/schemas/xmls/qdc/2008/02/11/dc.xsd
The latter dc.xsd can be downloaded and defines
<xs:element name="title" substitutionGroup="any"/>
<xs:element name="creator" substitutionGroup="any"/>
<xs:element name="subject" substitutionGroup="any"/>
<xs:element name="description" substitutionGroup="any"/>
<xs:element name="publisher" substitutionGroup="any"/>
<xs:element name="contributor" substitutionGroup="any"/>
<xs:element name="date" substitutionGroup="any"/>
<xs:element name="type" substitutionGroup="any"/>
<xs:element name="format" substitutionGroup="any"/>
<xs:element name="identifier" substitutionGroup="any"/>
<xs:element name="source" substitutionGroup="any"/>
<xs:element name="language" substitutionGroup="any"/>
<xs:element name="relation" substitutionGroup="any"/>
<xs:element name="coverage" substitutionGroup="any"/>
<xs:element name="rights" substitutionGroup="any"/>
All elements are declared as substitutable for the abstract element any,
which means that the default type for all elements is dc:SimpleLiteral.
Some documents specify the schema they expect to be validated against, typically using
xsi:noNamespaceSchemaLocation and/or xsi:schemaLocation attributes.
However, normally this isn't what you want. Usually the document consumer should choose the schema, not the document producer. This is what I did here where validation data is split according to namespaces between dc.xsd and WN-LMF-1.1.xsd.
dc: attributes are obviously meta data (I have grouped them into a Meta attribute group) except
dc:identifier (the sensekey): this acts more as a foreign key into another database and is the umbilical cord to the wn31 data, a sort of birth certificate with a mention of the parents. As such it means nothing within the confines of WordNet2019 as pointed out elsewhere : it is NOT a sense (nor synset) pointer. Besides 38 senses in adj alone have no dc:identifier. That's why I call it a foreign key. As such it should have its own namespace. I would suggest changing dc:identifier to wn31:sensekey.
arguably dc:subject is another umbilical-cord foreign key into wn31 in which case it should be transformed into wn31:lexfile. ... But it is also a reference to the lexical file it belongs to. If we anticipate more lexical files, it should be a lexfile attribute with the current (null) namespace.
likewise the ili attribute is a foreign key. It points to nothing within this database. I would suggest changing it to ili:id with its own namespace.
This leaves the problem of sensekeys that would have a meaning within the current database. If they have such a meaning, they are generated, not copied. Incidentally, let me mention that each version of WordNet generates its own sensekeys, the grinder tool does that. It turns out the sensekeys can be generated. I have worked on a XSLT-based transformer tool that does just that in a declarative way (XML-to-XML XSLT transformation description) and is to be found here. More on this later. The transformer adds a sensekey attribute. It would make sense to use it in a standalone generation of index.sense.
Besides being pointers, generated sensekeys have also been considered a measure of stability between successive versions of the WordNet database (if two versions generate the same sensekeys it's highly likely that nothing has changed in the distribution of senses). It can be used as such (and given an important weight) by the relaxmapper which is meant to find mappings between hierarchies of data. Again, this makes sense if the sensekeys are generated, not copied.
See above in Foreign-key attributes section.
Another option is to put it it in the top element (either LexicalResource or Lexicon) of the xml lexical file (it can then be easily accessed by tools). But the problem will remain when merging.
Allowing it
would avoid considerable redundancy ("The banks %s the check" is repeated 7433 times!)
Like this:
<LexicalResource>
<Lexicon>
...
<SyntacticBehaviour id='svo1' subcategorizationFrame="The banks %s the check" />
<SyntacticBehaviour id='sv1' subcategorizationFrame="The coins %s "/>
<SyntacticBehaviour id='svo2' subcategorizationFrame="They %s the bags on the table" />
<SyntacticBehaviour id='svo3' subcategorizationFrame="They %s the coin " />
...
<LexicalEntry id="ewn-inoculate-v" >
<Lemma writtenForm="inoculate" partOfSpeech="v" />
<Sense id="ewn-inoculate
<SyntacticBehaviour idref="svo1" senses="ewn-inoculate-v-00086587-03"/>
<SyntacticBehaviour idref="sv1" senses="ewn-inoculate-v-00053234-01 ewn-inoculate-v-00055835-01 ewn-inoculate-v-00188584-01"/>
<SyntacticBehaviour idref="sv02" senses="ewn-inoculate-v-00188584-01"/>
<SyntacticBehaviour idref="sv03" senses="ewn-inoculate-v-00086587-03 ewn-inoculate-v-00834278-01" />
...
</LexicalEntry>
</Lexicon>
</LexicalResource/">
Note I left out the problem of naming these frames.
Both are defined as
A relation between two concepts where concept A comes into existence as a result of concept B@en
Also, wn:causes and wn:involved_result share the same definition:
A relation between two concepts where concept B comes into existence as a result of concept A@en
In DTD file, Synset has example. (https://github.com/globalwordnet/schemas/blob/master/WN-LMF-relaxed-1.0.dtd#L88)
but json scheme file's Synset hasn't example field (
schemas/wn-json-schema-1.1.json
Lines 339 to 527 in 6a8c120
Is this bug? or some reason?
WordNet includes modifiers for adjective position, e.g.,
We should add an attribute to allow this modelling. Perhaps in a language independent way?
AFAICS the property wn:ili is not defined, neither in http://globalwordnet.github.io/schemas/wn nor in http://wordnet-rdf.princeton.edu/ontology.
The page https://globalwordnet.github.io/schemas/#rdf mentions namespace http://ili.globalwordnet.org/ili/ but I was not able to find this URL.
Should be there according to the site
Can we have more than one RDF schema? The schema adopted by http://openwordnet-pt.org precedes the W3C OntoLex Model being based on https://www.w3.org/TR/wordnet-rdf/. We have the schema specification and we are also developing a https://www.w3.org/TR/shacl/ validation.
Might seem redundant (given synset definition) but would be useful in the case where the definition is taken from a dictionary or some other pre-existing lexical resource (as is our case)
In some wordnets (I think PWN and plWordnet) the ranking of senses is meaningful, and I do not know how we should capture this in the DTD.
The hyperlink written here returns 404: https://github.com/globalwordnet/schemas/blob/master/index.html#L395
Scanning through the Turtle file, I noticed that you define your own POS relations and classes rather than use the lexinfo:partOfSpeech relation which is heavily used in the Ontolex specification, which I understand that @jmccrae helped bring to life. I'm unsure why this is the case?
In the Ontolex specification it is specifically stated that
I think that this is an excellent ideal as it makes integration of existing datasets mostly a matter of merging sets of triples. The second best option would be having some kind of derived lexinfo relation triple which can be inferred via equivalent/subclass relations.
Unfortunately, the GWA schema's partOfSpeech relation and PartOfSpeech class are proprietary and not linked to any external definitions. I have used Ontolex as the basis for the new version of DanNet, so my part-of-speech tags are all defined using lexinfo:partOfSpeech relation rather than wn:partOfSpeech.
How do you suggest we bridge this gap? The way I see it, either version 1.2 of the schema removes this bit and datasets use lexinfo:partOfSpeech directly -OR- a direct equivalency to lexinfo:partOfSpeech is established in the schema -- preferably the first as it simplifies things.
I could also add both wn and lexinfo relations for all LexicalEntry classes in the new DanNet, but that's both confusing and a messy fix IMO. Better to fix the schema than work around its flaws. Having competing standards for this is not a great situation.
The relevant part of the schema:
:partOfSpeech a owl:ObjectProperty ;
rdfs:domain ontolex:LexicalEntry ;
rdfs:range :PartOfSpeech ;
rdfs:label "part of speech"@en ;
rdfs:comment "The syntactic class of the entry, e.g., noun, verb"@en .
:PartOfSpeech a owl:Class ;
rdfs:label "part of speech"@en ;
rdfs:comment "The syntactic class of the entry, e.g., noun, verb"@en ;
owl:oneOf (
:noun :verb :adjective :adverb :adjective_satellite :named_entity
:conjunction :adposition :other_pos :unknown_pos ) .
:noun a :PartOfSpeech ;
rdfs:label "noun"@en.
:verb a :PartOfSpeech ;
rdfs:label "verb"@en .
:adjective a :PartOfSpeech ;
rdfs:label "adjective"@en .
:adverb a :PartOfSpeech ;
rdfs:label "adverb"@en .
:adjective_satellite a :PartOfSpeech ;
rdfs:label "adjective satellite"@en .
:named_entity a :PartOfSpeech ;
rdfs:label "named entity"@en .
:conjunction a :PartOfSpeech ;
rdfs:label "conjunction"@en .
:adposition a :PartOfSpeech ;
rdfs:label "adposition"@en .
:other_pos a :PartOfSpeech ;
rdfs:label "other pos"@en .
:unknown_pos a :PartOfSpeech ;
rdfs:label "unknown pos"@en .Should we have an attribute for lexicographer files? Is this something that many (more than one) wordnet projects use?
Most of the relations described at https://globalwordnet.github.io/gwadoc/ have inverse relations (called "reverse" in the documentation). However, none of these have been marked as owl:inverseOf in the Ontolex schema files. I wonder why that is the case? I really hope it's simply a case of a lack of time or an oversight, rather than a conscious omission.
There is a wn-simple-1.1.ttl which seems to be a pre-Ontolex RDF schema and this does retain some useful OWL definitions for inter-Resource relations, including owl:inverseOf. However, it seems that this is fundamentally incompatible with the later Ontolex versions (e.g. wn-lemon-1.1.ttl or wn-lemon-1.1.rdf) -- or at least I see no path to obtain equivalence between the different ontology definitions. If I choose the Ontolex schemas I gain a broader set of relations and build on the most current shared definition of what constitutes a WordNet graph, but on the other hand I lose very valuable OWL information. In my case, I really need both.
I am currently using the 1.1 schema files to construct an ontology for DanNet. I actually expected the various relations to have e.g. owl:inverseOf since this is so heavily featured in the documentation (almost every relation listed has a "reverse" relation) so I never bothered to check the schemas if they actually contained this information. I am relying on OWL reasoning to infer the "missing" RDF triples in order to have a consistent dataset and less duplication of data. The fact that the Ontolex-schemas have relatively sparse ontological information compared to wn-simple-1.1.ttl is really not a great foundation for us at the Center for Language Technology to build a knowledge graph on. The schemas are too simple in their current incarnations.
I appreciate the work you're doing to consolidate WordNet standards and create a common foundation, so I hope that you will reconsider.
The following new synset relations have been suggested by Ewa
simple_aspect: czytać "read/be reading (habitual/progressive)" -> przeczytać "have read" [pl]\secondary_aspect: kopać "dig/be digging" -> nakopać "have dug out a lot of sth" [pl]feminine_form: pig -> sowmasculine_form: & pig -> boaryoung_form: pig -> pigletdiminutive: pig -> piggyaugmentative: дом "house" -> домище "great house" [ru]anto_gradable: hot <-> cold, warm <-> coolanto_simple: complete <-> incompleteanto_converse: wife <-> husband, employer <-> employeeir_synonym or interregister_synonym: money <-> dough, loot informal, 食べる taberu "eat"<-> 召し上がる meshiagaru "honored person eats" honorific [ja]I think we could add these quite easily, right?
If a wordnet author wishes to ensure whitespace is preserved in things like examples, definitions, etc. in the WN-LMF format, they should use the xml:space attribute with the value "preserve", but this attribute must be declared in the schema if it is to be used in a valid document. See goodmami/wn#151 (comment) for further discussion.
I'm not advocating for or against this attribute's inclusion as I don't know if there's a real need, but just raising the issue for discussion since it came up in goodmami/wn#151.
The wn-simple-1.1.ttl, wn-simple-1.2.ttl, and wn-simple-1.3.ttl files are missing the following @prefix annotations:
@prefix cc: <http://creativecommons.org/ns#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix vann: <http://purl.org/vocab/vann/> .
@prefix voaf: <http://purl.org/vocommons/voaf#> .
As such, they will fail to be processed by an RDF application.
Would be useful for languages with gender (in languages like Italian the same Lexical Entry can have singular and plural forms of different genders so it would be good to have this in the ATTLIST for Form too)....(I also think part of speech would make more sense as part of the ATTLIST for Lexical Entry if we start to add grammatical attributes at the level of Lexical Entry)
In https://globalwordnet.github.io/schemas/, the antonym relation is defined as non-Princeton relation?
Original comment for @1313ou
The dc: attributes are defined as elements not attributes by Dublin Core so that any attempt to validate against this external reference will fail. How to see this ?
The namespace URL http://purl.org/dc/elements/1.1/ redirects to
http://dublincore.org/specifications/dublin-core/dcmi-terms/2012-06-14/?v=elementsThis page maps the URL to a schema location and contains the following:
Target namespace: http://purl.org/dc/elements/1.1/
Schema location: http://dublincore.org/schemas/xmls/qdc/2008/02/11/dc.xsd
The proposed change would be to change the DC attributes to elements. The obvious issue with this is that it breaks backwards compatibility, and the guidelines on Dublin Core are not a hard requirement (RDF for example uses attributes).
In https://globalwordnet.github.io/schemas/ we have the
The set of relations between senses is limited to the following
Non-Princeton WordNet Relations:
In the DTDs:
From https://globalwordnet.github.io/gwadoc/#pertainym, I got that this is the \ in the PWN https://wordnet.princeton.edu/documentation/wninput5wn.
So in conclusion, the page https://globalwordnet.github.io/schemas/ listed twice the same relation as two different relations but they are the same one, right?
This issue is meant to collect the changes we would like to make to WN-LMF but have not because doing so would break backward compatibility. When we get to a 2.0 version we have a chance for some simplification and belt-tightening, so it would be a shame if we miss some and have to wait for the next major version.
For better discussion, these issues could be broken up into separate issues (maybe with an appropriate label or milestone to group them?).
These are changes we would have made in WN-LMF 1.1 if backwards compatibility were not an issue.
<SyntacticBehaviour> from <LexicalEntry>; it became a child of <Lexicon>senses attribute from <SyntacticBehaviour>; these associations are handled by the subcat attribute on <Sense> elementsid attribute on <SyntacticBehaviour> requiredThese are new changes that we might consider
Remove (edit: in the comments below, a case is made for other uses of <Tag><Tag>)
The use case presented in Bond et al. 2020 ("Some Issues with Building a Multilingual Wordnet") seems more elegantly handled by the script attribute on <Lemma> and <Form>:
<Lemma writtenForm="头发" partOfSpeech="n" script="Hans" />
<Form writtenForm="頭髮" script="Hant" />
<Form writtenForm="tóufa" script="Latn-pinyin" />
<Form writtenForm="tou2fa5" script="Latn-pinyin-x-numeric" />
<Form writtenForm="toufa" script="Latn-pinyin-x-simple" />Above, if script were limited to ISO15924 script names, then all 3 pinyin variants would be just "Latn", so I used BCP-47-like tags minus the language and region names. The "pinyin" variant and private-use tags "numeric" and "simple" can be used to distinguish them.
Remove <Count>? (see comments below)
Remove <ILIDefinition>? (see comments below)
Remove (apparently) unused attributes?
sourceSense on <Definition>lexicalized on <Sense> and <Synset>status on anything with metadata
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.