stichting-crow / imbor Goto Github PK
View Code? Open in Web Editor NEWEen informatiemodel en objecttypenbibliotheek (né ontologie) voor assetbeheer van de openbare ruimte
Home Page: https://www.crow.nl/imbor
Een informatiemodel en objecttypenbibliotheek (né ontologie) voor assetbeheer van de openbare ruimte
Home Page: https://www.crow.nl/imbor
In IMBOR staan de vaste gegevens die een asset manager nodig heeft voor het tactisch beheer van een kunstwerk, in aanvulling op de gegevens die in IMGeo gevraagd worden.
Bij NEN 2767 (Conditiemeting gebouwen en kunstwerken) wordt een lijst van kunstwerk- en gebouwonderdelen verstrekt, met enkele gegevens die uit een inspectie of conditiemeting kunnen komen. Deze lijst bevat een soort decompositie, en wordt in de bouwwereld vaak als zodanig gebruikt.
Als IMBOR gebruikt wordt om een objecttypebibliotheek op te stellen en areaalgegevens te kunnen modelleren, willen de opstellers daarbij graag een decompositie hebben op basis van NEN 2767 om:
Hoe gebeurt dat nu?
Gebruikers "vertalen" elk op eigen manier de gegevens uit NEN 2767 naar een decompositie, met die onderdelen / het detailniveau die zij zelf nodig hebben. Dit zorgt voor werk bij elke asset manager, in plaats van een keer een collectieve inspanning.
Ik weet dat jullie hier ook discussies over voeren.... maar ik open er toch een issue voor.
bs:hasPart is niet de juiste relatie voor o.a.
Groenobject - GroenobjectSoortnaam,
Wegas - WegasVerkeersintensiteit
en nog een paar...
Als otl:Informatiemodel als bs:InformationObject getypeerd wordt kan de bs:describes relatie gebruikt worden die volgens mij wel past hierbij?
Suggestielijsten worden niet meegenomen.
Vastewaardelijsten worden wel meegenomen en leidend gemaakt voor de mogelijke waardes van een attribuut.
De kolom Referentietabel
uit de tabel X_Attributen
bepaalt of een attribuut een vastewaardelijst heeft (true
) of een suggestielijst (false
) omvat.
Issue #39 beschrijft hoe attribuutsoort (Vaste lijst/suggestielijst) niet gelijk lopen met referentietabelsoort (Vast/suggestie).
KOR-IMBOR records zetten we niet over naar de ontologie (deze filteren we bij de transformatie er uit op basis van informatie uit de Access database. Dit is de relatie tussen de tabel [X_Informatiemodellen] en [X_ObjecttypesAttributen]. Deze gaat Jochem nog toevoegen (20191029)
Bijproduct is een Excel sheet met in kolom A de URI's van de IMBOR objecttypen en de naam in KOR-IMBOR.
KOR-IMBOR is apart informatiemodel die we niet in de OTLBOR moeten willen onderhouden
IMGEO records zetten we niet over naar de ontologie (deze filteren we bij de transformatie er uit op basis van informatie uit de Access database. Dit is de relatie tussen de tabel [X_Informatiemodellen] en [X_ObjecttypesAttributen]. Deze gaat Jochem nog toevoegen (20191029)
Bijproduct is een Excel sheet met in kolom A de URI's van de IMBOR objecttypen en de naam in IMGEO
IMGEO is apart informatiemodel die we niet in de OTLBOR moeten willen onderhouden
Ter volledigheid introduceren we twee hoofdklassen skos:collection, te weten "IMBOR Hierarchie" en "IMBOR Vakdiscipline". "IMBOR Hierarchie" heeft de nadere subClasses zoals bij issues #17 en #18 vermeld.
Dit onderscheidt wordt gemaakt omdat we dan kunnen zeggen welke van de collecties voor het presenteren van een voor IMBOR gebruikers bekende hierarchie gebruikt kunnen worden, en welke niet.
We gebruiken de NTA om bij objecten semantiek toe te voegen (physical object), maar het hele eigenschappen verhaal wordt al door OWL geregeld dus daar gebruiken we de NTA verder niet voor.
Vandaar dat de 'gewone' constructies gebruik worden als: rdsf:range,
rdfs:domain,
owl:topObjectProperty
en owl:topDataProperty.
Omdat we voorzien dat het gebruik van de ontologie vooralsnog alleen maar is voor :
rdfs:subClassOf
bs:PhysicalObject
, maar deze issues zetten we op de roadmap IMBOR OTL.NTA schijft voor dat datatype owl:class zijn. Wij introduceren één superklasse om ze bij elkaar te houden in taxonomie. Deze klasse is 'domeinwaarde".
Zodoende kunnen we ook aangeven dat de rdfs:range van een owl:topObjectProperty in ons geval alleen deze klasse "domeinwaarde" kan zijn.
In de tabel X_Objecttypegroepen staat de kolom, "HoofdobjecttypeID". Waar dit van toepassing is, wordt de groep vervangen door de corresponderende record uit 'X_Objecttype'.
Zodoende hoeven we niet de single name aan te passen. De record 'Informatiemodel' wordt verder wel opgenomen als klasse. Want de onderliggende klassen (die niet samenvallen met een objecttypegroep nemen we gewoon op. 'Hulpobjecten' blijft ook over (die we dan wel gewoon als Class aanmaken)
Labels, voor objecttypes zoals "Brug" of eigenschappen als "belastingklasse", zijn taalafhankelijk.
Vanuit de NTA worden geen beperkingen opgelegd, vanuit de taalspecificatie wordt bepaald dat het welgevormd volgens BCP 47 moet zijn, zij het altijd in onderkast. Zie ook de voorbeelden aldaar.
In RDF worden Nederlandstalige literals soms niet, soms als @nl
, soms als @nl-NL
getagd. Eng bekeken moet @nl
geïnterpreteerd worden als geldend voor de hele Nederlandse taal in alle varianten, @nl-NL
als voor het Nederlands van Nederland, waarbij Vlaanderen, Suriname en de Caraïbische delen van het Koninkrijk worden uitgesloten.
CROW bedient Nederland en daarom geniet de explicietere @nl-NL
mijn voorkeur.
Binnen de tabel X_AttributenDomeinwaarden hebben sommige waardes een bovenliggend label. Deze bestaat binnen IMBOR om het scrollen door lange lijsten makkelijk te maken. In de LD versie doen we hier niets mee.
Er zijn attributen (zoals Afvoeren, maar er zijn er meer) die gedefinieerd zijn als DatatypeProperty, maar vervolgens wel een Class als range hebben (en daar mee dus ook een ObjectProperty zijn)
volgens mij is dit niet gewenst....
p:Attributen_319 rdfs:label "Afvoeren" ;
p:attribuutsorteergroep "Functie"@NL-NL ;
p:dataLabel "Afvoeren"@NL-NL ;
p:guid urn:uuid:5D80D795-C1AA-4BC2-953E-7BCE768446B3 ;
rdfs:domain otl:Objecttypes_402,
otl:Objecttypes_403,
otl:Objecttypes_433,
otl:Objecttypes_499 ;
rdfs:range p:Attributen_319Type,
xsd:boolean ;
rdfs:subPropertyOf owl:topDataProperty ;
skos:definition "Aanduiding of het groenafval afgevoerd moet worden."@NL-NL ;
skos:prefLabel "Afvoeren" .
In de wiki staat een duidelijke uri-strategie beschreven met /def/objecttype en def/prop voor objecttypes en attributen. Ik zou een /def/waardelijst (of cv voor ControlledVocabulary) willen voorstellen voor waardelijsten/domeinen.
groep:INF18 zit nu in de data (Informatiemodel 18 in Access = IMBOR). Dit zijn een flink aantal triples die nu eigenlijk geen waarde hebben. groep:INF18 wordt namelijk nergens gebruikt.
Dus wat mij betreft twee resoluties:
De niet meer bestaande objecttypegroep Verlichtingsobjecten staat nog wel in de Access-db.
Dit moet worden aangegeven bij Jochem/Harro.
Op verzoek van gebruikers: toevoegen van een planning voor IMBOR
Eerstvolgende release: IMBOR 2020-07, in Acces én linked data
Deadline gebruikerswensen: NTB
Bijeenkomst met softwareleveranciers: NTB, in mei
Publicatiedatum: 1 juni 2020
Publicatiedatum versie 3.0: 23 december
Wat hier op Github 0.6 versie heet, hebben we in de communicatie met de Provincies steeds 1.0 genoemd 😉
Dit jaar gaan de 2.0 en 3.0 opleveren, beide gefinancierd vanuit de Provincies.
SUF-BENCHMARKS records zetten we niet over naar de ontologie (deze filteren we bij de transformatie er uit op basis van informatie uit de Access database. Dit is de relatie tussen de tabel [X_Informatiemodellen] en [X_ObjecttypesAttributen]. Deze gaat Jochem nog toevoegen (20191029)
Bijproduct is een Excel sheet met in kolom A de URI's van de IMBOR objecttypen en de naam in SUF-BENCHMARK.
SUF-BENCHMARKS is apart informatiemodel die we niet in de OTLBOR moeten willen onderhouden
Er bestaan relaties tussen Objecttypes, deze worden apart behandeld. Het gaat om een filter in de tabel [X_Objecttypes] op de kolom [Hulpobject], met de waarde 'Ja'
Voor deze' relaties tussen Objecttypes zijn wat ons betreft twee opties, skos:related
en bs:hasPart. De semantiek van skos:related
is meer correct omdat in IMBOR er nauwelijks duidelijkheid wordt gegeven over de relatie. Echter omdat we ook al losjes gekozen hebben om alles een bs:PhysicalObject
te laten zijn... kiezen we er hier nu toch voor om al deze IMBOR relaties te classificeren als een bs:hasPart
. Zo blijven qua objecten en hun relaties dichter bij de NTA.
via Luuk Wijnholts
Er zijn behoorlijk wat Objecttypes die dubbele labels en preflabels hebben...
Over het algemeen een enkelvoud en een meervoudsvorm.
Waarschijnlijk omdat het vanuit IMBOR zowel collecties zijn als nu in de ontologie 'supertypen'?
otl:Objecttypes_499
rdf:type rdfs:Class ;
p:dataLabel "Waterobject"@NL-NL ;
p:geometryAsPolygon true ;
p:guid urn:uuid:08C0CFA2-8234-40B4-83CA-5C216D83F677 ;
p:guid urn:uuid:81CBE022-0D94-4377-82CA-3AA12937FE8D ;
rdfs:label "Waterobject"@NL-NL ;
rdfs:label "Waterobjecten"@NL-NL ;
rdfs:subClassOf otl:Beheerobject ;
skos:definition "Kleinste functioneel onafhankelijk stukje water met gelijkblijvende, homogene eigenschappen en relaties dat er binnen het objecttype Water van NEN 3610 wordt onderscheiden en dat permanent met water bedekt is."@NL-NL ;
skos:prefLabel "Waterobject"@NL-NL ;
skos:prefLabel "Waterobjecten"@NL-NL ;
.
De versienummering van de dataset en het datamodel is nog niet bepaald.
Ik stel mij voor dat het datamodel zelf weinig veranderingen zal doormaken gedurende het gebruik ervan. De dataset wordt samen met IMBOR geüpdatet en zal dientengevolge halfjaarlijks een nieuwe versie krijgen.
Hoe wijzigingen aan de dataset bekend worden gemaakt en in de dataset zitten, valt buiten de scope van deze issue.
Voor het abstracte datamodel verwacht ik iets als v1.0.0
, met typfoutjes (bugfix) hersteld in v1.0.1
, uitbreidingen in een v1.1.0
, terwijl verwijderingen en wijzigingen leiden tot v2.0.0
.
IMBOR is continue ontwikkeling en daarom ook de OTL BIM Pro. Bij deze ontwikkelingen worden voorstellen vastgesteld (IMBOR noemt dit gepubliceerd c.q. bevroren) voor een bepaalde periode. Voorstellen zitten daarmee in de dataset, maar kunnen op elk aspect nog wijzigen.
Voor de afnemers van de dataset kunnen we twee soorten bestanden beschikbaar stellen.
Versies van de dataset geldig-op-een-bepaalde-datum krijgen een versielabel mee van de datum op sorteervolgorde: bijvoorbeeld v20190801
voor de versie geldend vanaf 1 aug. 2019.
De volledige historische versie van IMBOR kan naast voorgenoemde datumstijl, ook versienummering krijgen parallel lopend met IMBOR. IMBOR publiceert 1-2x per jaar een nieuwe versie, e.g. 2019-1
, 2019-2
, 2020-1
. Dan wordt de versienummering v2019.1.0
, v2019.1.1
, v2019.2.0
, v2020.1.0
waarbij ook kleine wijzigingen (typfouten) tussendoor kunnen worden doorgevoerd.
Zolang de NTA niet is vastgesteld, maken we gebruik van owl:DataTypeProperty
en sh:datatype
voor de eigenschappen waarbij een nta8035:unit
is bepaald.
Dit zouden volgens de laatste versie NTA 8035 bij schrijven moeten zijn: owl:ObjectProperty
s met een rdfs:range
naar nta8035:QuantityValue
.
De NTA zegt dat de range van dataproperties een xsd:string
is, tenzij er een eenheid is aangegeven. Dit is in IMBOR zo. Die eenheden interpreteren wij naar de CDT/UMUC ontologie. Hiervoor maken we een interpretatie van de tabel [X_Eenheden], deze wordt apart verstrekt.
Er worden in het datamodel een aantal properties geïntroduceerd die er alleen maar 'voorlopig' zijn om wat informatie kwijt te kunnen die uit Access komt. Dit betreffen:
labels bij Attributen hebben geen @NL-NL tag.
bijvoorbeeld:
p:Attributen_813 rdfs:label "Draagkrachtig" ;
...
skos:prefLabel "Draagkrachtig" .
Dit vormt een probleem als we de OTL zelf willen controleren.
Of een OTL die voortbouwt op IMBOR willen controleren.
GWSW records zetten we niet over naar de ontologie (deze filteren we bij de transformatie er uit op basis van informatie uit de Access database. Dit is de relatie tussen de tabel [X_Informatiemodellen] en [X_ObjecttypesAttributen]. Deze gaat Jochem nog toevoegen (20191029)
Bijproduct is een Excel sheet met in kolom A de URI's van de IMBOR objecttypen en de naam in GWSW
Er is besloten door de provincies dat alles m.b.t. riolering bij de GWSWS gelaten wordt. We willen hier niets zeggen over deze objeccttypen en eigenschappen. Vandaar dat we het geheel uit de ontologie laten om geen overlap te hebben. *uitzoeken
Er is geen LICENSE-bestand aanwezig in de repo.
Omdat we een 'nieuwe' versie aan het maken zijn nemen we geen legacy mee.
Omdat we voorzien dat het gebruik van de ontologie vooralsnog alleen maar is voor :
rdfs:subClassOf
bs:PhysicalObject
, maar deze issues zetten we op de roadmap IMBOR OTL.De queries in het SPARQL-voorbeelden.ipynb notebook gaan goed omdat er bovenin voor de sparql interpreter geconfigureerd is dat inferencing gebruikt moet worden.
Als je de queries uit het notebook copy-paste naar een andere omgeving gaat dat niet automatisch goed... de rdfs:subClassOf queries doen dan standaard alleen de directe subclasses. Als je de query aanpast naar rdfs:subClassOf* gaat het wel goed.
misschien goed om dat duidelijk te maken in het notebook. ik las er ook even overheen en moest even goed nadenken wat er aan de hand was...
Voor Vakdisciplines gebruiken we dezelfde constructie als bij #17. Dus skos:collection
, met skos:member
Zodoende kunnen we aangeven op basis van [X_Publicatiegroepen], welke objecttypes in welke groepen horen en dat presenteren waar nodig.
De afgesproken hiërarchie resulteert in de rdfs:subClassOf structuur:
We kiezen dus voor single inheretence (t.o.v. multiple inheretence) omdat deze taxonomie ook voor eindgebruikers bij de provincies werkbaar moet zijn en de usecase vooralsnog alleen "het managen van eigenschappen" is.
Bijvoorbeeld shape:OBB788Shape
.
via Luuk Wijnholts
@redmer dit is een overblijfsel van een van onze probeersels. Misschien netjes om eruit te halen.
Sommige eigenschappen hebben eigenschappen naast rdfs:label
en skos:description
.
Die eigenschappen staan niet in X_Attributen
, X_AttributenDomeinwaarden
, maar in individuele tabellen genaamd REF_
of REFS_
.
Hoewel de meeste domeinwaardes geen secundaire eigenschappen hebben, hebben 86 tabellen meerdere eigenschappen.
Er moet worden bepaald of deze eigenschappen ook meegenomen moeten worden in OTL BIM Pro.
Alle eigenschappen uit de IMBOR worden owl:topDataProperty, tenzij ze verwijzen naar een waardelijst. Dan worden het owl:topObjectProperty.
We gebruiken geen owl:topAnnotationProperty omdat hierover geen reasoning gedaan kan worden.
... uitgezonderd 'Beheerobject';
... en te identificeren d.m.v. de bestaande PK <> FK link in Access.
Objecttypegroepen worden hiermee de tweede laag in de taxonomie. Dit is wederom voor de overerving van eigenschappen. Momenteel worden de objecttypegroepen ook op deze manier gebruikt in de IMBOR. Dat wil zeggen, in de User Interface (de formulieren) van IMBOR. De data (tabellen in IMBOR) stelt het anders. Maar omdat de eindgebruiker van IMBOR ons uitgangspunt is, wordt voor deze oplossing gekozen.
Sommige IMBOR Domeinwaardes hebben een BovenliggendeDomeinwaarde. Dit staat in X_AttributenDomeinwaarden
.
AttribuutID | Domeinwaarde | BovenliggendeDomeinwaarde | Definitie |
---|---|---|---|
Gebruiksfunctie | Fauna weren | Afscherming | Wild weren, fauna/wild keren |
Gebruiksfunctie | Anti-parkeer | Algemeen | Tegengaan van parkeren |
Gebruiksfunctie | Verbetering koeling | Milieu en klimaat | Beschaduwing, koeling |
Gebruiksfunctie | Begrazingsgebied | Natuurwaarde | Rust- en/of verblijfplaats voor grazers en andere diersoorten. Soms ‘begrazingsgebied’ genoemd. Valt hieronder wanneer het gebied bedoeld is om de grazers voedsel, drinkwater, beschutting en soortgenoten te bieden. |
Het is niet helemaal duidelijk hoe dit conform NTA 8035 gemodelleerd moet worden.
Verhoudt zich tot #22.
Er zijn vijf objecten die niet hulpobjecten zijn (geen vinkje hebben in X_Objecttypes), maar wel in de objecttypegroep "Informatiemodel" zitten. Dit zijn:
Deze worden niet bijzonder behandeld.
Vanuit de tabel X_Attribuutsoorten
worden er o.a. "Vaste lijst" en "Suggestielijst" onderscheiden.
Vanuit de tabel X_Tabelsoort
(via X_Attributen.referentietabel.tabelsoort
) worden REF_
en REFS_
tabellen onderscheiden.
REFS_
is een suggestielijst, REF_
een vaste lijst.
De waardes voor individuele attributen komen echter niet overeen tussen beide lijsten.
# | attr | attribuutSoort | attribuut | tabel | attrSoort | ts | tabelsoort |
---|---|---|---|---|---|---|---|
1 | 135 | 1 | Bereikbaarheid gedetailleerd | 181 | Vaste lijst | 3 | REFS_ |
2 | 1241 | 1 | Regelprogramma | 627 | Vaste lijst | 3 | REFS_ |
3 | 1201 | 1 | Type voorschakelapparaat | 609 | Vaste lijst | 3 | REFS_ |
4 | 1266 | 1 | Netbeheerder | 634 | Vaste lijst | 3 | REFS_ |
5 | 1198 | 1 | Brandregime | 606 | Vaste lijst | 3 | REFS_ |
6 | 207 | 1 | Beschermingsstatus gedetailleerd | 144 | Vaste lijst | 3 | REFS_ |
7 | 1200 | 1 | Optiek | 608 | Vaste lijst | 3 | REFS_ |
8 | 1207 | 1 | Remplacegroep | 613 | Vaste lijst | 3 | REFS_ |
9 | 910 | 1 | Attribuut | 150 | Vaste lijst | 7 | X_ |
10 | 911 | 1 | Domeinwaarde | 459 | Vaste lijst | 7 | X_ |
11 | 912 | 1 | Objecttype | 163 | Vaste lijst | 7 | X_ |
12 | 376 | 4 | Soort plantenbak | 294 | Suggestielijst | 2 | REF_ |
13 | 1257 | 4 | Type reiniging | 361 | Suggestielijst | 2 | REF_ |
Select *
WHERE {
GRAPH graph:X_Attributen {
?attr imborp:attribuutSoort ?attribuutSoort ; rdfs:label ?attribuut; imborp:referentietabel ?tabel .
}
GRAPH graph:X_Attribuutsoorten {
?attribuutSoort rdfs:label ?attrSoort ;
}
GRAPH graph:X_Tabellen {
?tabel imborp:tabelsoort ?ts ;
}
GRAPH graph:X_Tabelsoort {
?ts rdfs:label ?tabelsoort ;
}
}
De records uit [REF_Type/TypePlus/TypePlus2/TypePlus3] worden allemaal Classes, hiërarchisch gezien rdfs:subClassOf van de records uit [X_Objecttypes], d.m.v. de bestaande PK <> FK link in Access. Daar waar mogelijk voegen we bestaande definities toe.
Omdat uit gesprekken met de provincies is gehaald dat bij sommige provincies deze typen geinstantieerd worden (om er specifieke attributen aan te hangen). Kiezen we ervoor om deze als Classes te modelleren, i.p.v. de attribuut waarden die ze nu zijn in Access. Dit worden voorlopige Classes zonder dat er direct attributen aanhangen (uiteraard wel via overerving). Dit kan resulteren in Classes zonder definities.
Naast issue #12, #11, #13, #14 worden ook de BAG, BGT, IMKL, NEN3610 en "stelsel" records niet overgezet naar de ontologie. Deze filteren we bij de transformatie er uit op basis van informatie uit de Access database. Deze informatie komt uit de tabel [X_Informatiemodellen.
Dat zijn aparte informatiemodellen die we vooralsnog niet in de OTLBOR moeten willen onderhouden
Bij sommige eigenschappen in Access wordt zowel naar een vastewaardelijst gewezen ALS naar de eenheden tabel. In dit geval wordt bij de transformatie naar LD, alleen de vastewaardelijst overgenomen.
Omdat je veel queries wil doen via binding met de labels is het extra irritant als er spaties in staan
otl:TypePlus2_2053
rdf:type rdfs:Class ;
p:guid urn:uuid:34C101EE-B6C9-46D9-A0FE-9519EE0F0968 ;
rdfs:label "BW201-RB "@NL-NL ;
rdfs:subClassOf otl:TypePlus_2543 ;
skos:definition "Fietsers rechts oversteken"@NL-NL ;
skos:prefLabel "BW201-RB "@NL-NL ;
.
Voor de verdere informatiemodellen uit [X_Informatiemodellen] maken we nog geen onderscheidt. Deze worden zodoende 'automatisch' meegetransformeerd.
De rest van de informatie die opgenomen is im IMBOR behandelen we hetzelfde als alle IMBOR informatie. We beschouwen het nu als 'onderdeel' van de IMBOR en zodoende wordt alle informatie op dezelfde manier getransformeerd. Eventuele uitzonderingen hier op moeten nog worden vastgesteld.
Partijen willen een combinatie van IMGeo en IMBOR gebruiken in hun OTL, en ook om uit te vragen aan de markt. De bestaande mapping in Access is daar gelaten, deze is geschikt voor het berichtenverkeer van de BGT, maar niet voor een zuivere vertaling in linked data waarmee automatisering kan plaatsvinden. De wens is een mapping te hebben in IMBOR-linked data
Om een filter te kunnen maken per 'type' IMBOR object (gezien van de IMBOR hierarchie) maken we deze skos:collection
. Dit worden dan:
We maken er skos:collection
van omdat deze skos:member
hebben. De relatie skos:inScheme
heeft last van overerving dus kunnen we niet gebruiken. De relatie loopt zodoende van de collectie naar de class (IMBOR type). Er is geen waarde meer voor de relaties tussen de collectie, want we maken Beheerobject een superklasse en we 'objectificeren' ObjectTypeGroepen. De collectie relatie is zodoende alleen maar om aan te geven welk type het was.
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 is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
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.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.