მონაცემთა მეცნიერის შენიშვნები: მონაცემთა შეკითხვის ენების პერსონალიზებული მიმოხილვა

პირადი გამოცდილებიდან გეუბნები, სად და როდის რა იყო გამოსადეგი. ეს არის მიმოხილვა და დისერტაცია, რათა ცხადი იყოს, რა და სად შეგიძლიათ შემდგომი გათხრა - მაგრამ აქ მე მაქვს ექსკლუზიურად სუბიექტური პირადი გამოცდილება, შესაძლოა ყველაფერი სრულიად განსხვავებული იყოს თქვენთვის.

რატომ არის მნიშვნელოვანი შეკითხვის ენების ცოდნა და გამოყენება? მონაცემთა მეცნიერებას აქვს მუშაობის რამდენიმე მნიშვნელოვანი ეტაპი და პირველი და ყველაზე მნიშვნელოვანი (ამის გარეშე, რა თქმა უნდა, არაფერი იმუშავებს!) არის მონაცემების მოპოვება ან მოპოვება. ყველაზე ხშირად, მონაცემები სადღაც რაღაც ფორმით ზის და იქიდან „ამოღებას“ საჭიროებს. 

შეკითხვის ენები საშუალებას გაძლევთ ამოიღოთ სწორედ ეს მონაცემები! და დღეს მე გეტყვით იმ კითხვის ენებზე, რომლებიც გამომადგა და გეტყვით და გაჩვენებთ სად და როგორ ზუსტად - რატომ არის საჭირო სწავლა.

იქნება მონაცემთა მოთხოვნის ტიპების სამი ძირითადი ბლოკი, რომლებსაც განვიხილავთ ამ სტატიაში:

• „სტანდარტული“ შეკითხვის ენები არის ის, რაც ჩვეულებრივ ესმით შეკითხვის ენაზე საუბრისას, როგორიცაა რელაციური ალგებრა ან SQL.
• სკრიპტირების შეკითხვის ენები: მაგალითად, პითონის საგნები პანდაები, სკრიპტები ან ჭურვი.
• მოითხოვეთ ენები ცოდნის გრაფიკებისა და გრაფიკების მონაცემთა ბაზებისთვის.

ყველაფერი, რაც აქ არის დაწერილი, მხოლოდ პირადი გამოცდილებაა, რაც იყო სასარგებლო, სიტუაციების აღწერით და „რატომ იყო საჭირო“ - ყველას შეუძლია სცადოს, როგორ შეიძლება მსგავსი სიტუაციები შეგექმნას და შეეცადოს წინასწარ მოემზადო მათთვის ამ ენების გაგებით. სანამ თქვენ მოგიწევთ (სასწრაფოდ) განაცხადის გაკეთება პროექტზე ან თუნდაც პროექტზე მისვლა, სადაც ისინი საჭიროა.

"სტანდარტული" შეკითხვის ენები

სტანდარტული შეკითხვის ენები არის ზუსტად იმ გაგებით, რომ ჩვენ ჩვეულებრივ ვფიქრობთ მათზე, როდესაც ვსაუბრობთ შეკითხვებზე.

ურთიერთობითი ალგებრა

რატომ არის საჭირო დღეს რელაციური ალგებრა? იმისათვის, რომ კარგად გესმოდეთ, თუ რატომ არის შეკითხვის ენების სტრუქტურირება გარკვეული გზით და გამოიყენოთ ისინი შეგნებულად, თქვენ უნდა გესმოდეთ მათი ძირითადი საფუძველი.

რა არის რელაციური ალგებრა?

ფორმალური განმარტება ასეთია: რელაციური ალგებრა არის ურთიერთობის ოპერაციების დახურული სისტემა რელაციური მონაცემების მოდელში. ცოტა უფრო ადამიანურად რომ ვთქვათ, ეს არის ოპერაციების სისტემა მაგიდებზე, რომ შედეგი ყოველთვის არის ცხრილი.

იხილეთ ყველა ურთიერთობითი ოპერაცია ამ სტატია Habr-დან - აქ ჩვენ აღვწერთ, რატომ უნდა იცოდეთ და სად გამოგადგებათ.

რატომ?

იმის გაგება, თუ რა არის შეკითხვის ენები და რა ოპერაციები დგას გამონათქვამების მიღმა კონკრეტულ შეკითხვის ენებში, ხშირად იძლევა უფრო ღრმა გაგებას, თუ რა მუშაობს შეკითხვის ენებში და როგორ.

Აღებულია ამ სტატიები. ოპერაციის მაგალითი: შეერთება, რომელიც აერთიანებს ცხრილებს.

მასალები შესასწავლად:

კარგი შესავალი კურსი სტენფორდიდან. ზოგადად, რელაციური ალგებრაზე და თეორიაზე უამრავი მასალაა - Coursera, Udacity. ასევე არის უზარმაზარი მასალა ინტერნეტში, მათ შორის კარგი აკადემიური კურსები. ჩემი პირადი რჩევა: კარგად უნდა გესმოდეთ რელაციური ალგებრა - ეს არის საფუძვლების საფუძველი.

SQL

Აღებულია ამ სტატიები.

SQL არსებითად რელაციური ალგებრის იმპლემენტაციაა - მნიშვნელოვანი გაფრთხილებით, SQL არის დეკლარაციული! ანუ, როდესაც წერთ შეკითხვას რელაციური ალგებრის ენაზე, თქვენ რეალურად ამბობთ როგორ გამოვთვალოთ - მაგრამ SQL-ით თქვენ მიუთითებთ რისი ამოღება გსურთ და შემდეგ DBMS უკვე წარმოქმნის (ეფექტურ) გამონათქვამებს რელაციური ალგებრის ენაზე (მათი ეკვივალენტობა ჩვენთვის ცნობილია, როგორც კოდის თეორემა).

Აღებულია ამ სტატიები.

რატომ?

რელაციური DBMS: Oracle, Postgres, SQL Server და ა.შ. ჯერ კიდევ არის თითქმის ყველგან და არსებობს წარმოუდგენლად დიდი შანსი, რომ მოგიწიოთ მათთან ურთიერთობა, რაც ნიშნავს, რომ თქვენ ან უნდა წაიკითხოთ SQL (რაც ძალიან სავარაუდოა) ან დაწეროთ ( არც არის გამორიცხული).

რა წავიკითხოთ და ვისწავლოთ

ზემოთ მოყვანილი იგივე ბმულების მიხედვით (რელატიური ალგებრას შესახებ), არის წარმოუდგენელი რაოდენობის მასალა, მაგალითად, ამ.

სხვათა შორის, რა არის NoSQL?

„კიდევ ერთხელ ხაზგასმით უნდა აღინიშნოს, რომ ტერმინს „NoSQL“ აქვს აბსოლუტურად სპონტანური წარმოშობა და მის უკან არ გააჩნია ზოგადად მიღებული განმარტება ან სამეცნიერო ინსტიტუტი“. Შესაბამისი სტატიის ჰაბრზე.

ფაქტობრივად, ხალხმა გააცნობიერა, რომ სრული ურთიერთობითი მოდელი არ არის საჭირო მრავალი პრობლემის გადასაჭრელად, განსაკუთრებით მათთვის, სადაც, მაგალითად, შესრულება კრიტიკულია და დომინირებს გარკვეული მარტივი მოთხოვნები აგრეგაციით - სადაც მნიშვნელოვანია მეტრიკის სწრაფად გამოთვლა და მათი ჩაწერა. მონაცემთა ბაზა და ფუნქციების უმეტესობა რელატიური აღმოჩნდა არა მხოლოდ არასაჭირო, არამედ საზიანოც - რატომ უნდა ნორმალიზდეს რაღაც, თუ ის გააფუჭებს ჩვენთვის ყველაზე მნიშვნელოვანს (გარკვეული ამოცანისთვის) - პროდუქტიულობა?

ასევე, ხშირად საჭიროა მოქნილი სქემები კლასიკური რელაციური მოდელის ფიქსირებული მათემატიკური სქემების ნაცვლად - და ეს წარმოუდგენლად ამარტივებს აპლიკაციის განვითარებას, როდესაც მნიშვნელოვანია სისტემის განლაგება და მუშაობის სწრაფი დაწყება, შედეგების დამუშავება - ან სქემა და შენახული მონაცემების ტიპები. არც ისე მნიშვნელოვანი.

მაგალითად, ჩვენ ვქმნით საექსპერტო სისტემას და გვსურს შევინახოთ ინფორმაცია კონკრეტულ დომენზე მეტა-ინფორმაციასთან ერთად - შეიძლება არ ვიცოდეთ ყველა ველი და უბრალოდ შევინახოთ JSON თითოეული ჩანაწერისთვის - ეს გვაძლევს ძალიან მოქნილ გარემოს მონაცემთა გაფართოებისთვის. მოდელი და სწრაფად განმეორებადი - ასე რომ, ამ შემთხვევაში, NoSQL კიდევ უფრო სასურველი და წასაკითხი იქნება. ჩანაწერის მაგალითი (ჩემი ერთ-ერთი პროექტიდან, სადაც NoSQL იყო ზუსტად იქ, სადაც საჭირო იყო).

{"en_wikipedia_url":"https://en.wikipedia.org/wiki/Johnny_Cash",
"ru_wikipedia_url":"https://ru.wikipedia.org/wiki/?curid=301643",
"ru_wiki_pagecount":149616,
"entity":[42775,"Джонни Кэш","ru"],
"en_wiki_pagecount":2338861}

დაწვრილებით აქ NoSQL-ის შესახებ.

რა ვისწავლოთ?

აქ, უფრო სწორად, თქვენ უბრალოდ უნდა საფუძვლიანად გააანალიზოთ თქვენი დავალება, რა თვისებები აქვს მას და რა NoSQL სისტემებია ხელმისაწვდომი, რომლებიც შეესაბამება ამ აღწერას - და შემდეგ დაიწყოთ ამ სისტემის შესწავლა.

შეკითხვის ენების სკრიპტირება

თავდაპირველად, როგორც ჩანს, რა კავშირი აქვს მას პითონთან ზოგადად - ეს არის პროგრამირების ენა და არა შეკითხვებზე.

• Pandas ფაქტიურად მონაცემთა მეცნიერების შვეიცარიული არმიის დანაა, მასში ხდება მონაცემთა უზარმაზარი ტრანსფორმაცია, აგრეგაცია და ა.შ.
• Numpy - ვექტორული გამოთვლები, მატრიცები და ხაზოვანი ალგებრა იქ.
• Scipy - ამ პაკეტში ბევრი მათემატიკაა, განსაკუთრებით სტატისტიკა.
• Jupyter lab - ბევრი საძიებო მონაცემთა ანალიზი კარგად ჯდება ლეპტოპებში - სასარგებლოა იცოდეთ.
• მოთხოვნები - ქსელთან მუშაობა.
• Pyspark ძალიან პოპულარულია მონაცემთა ინჟინრებში, სავარაუდოდ, თქვენ მოგიწევთ ურთიერთობა ამ ან Spark-თან, უბრალოდ მათი პოპულარობის გამო.
• *სელენი - ძალიან სასარგებლოა საიტებიდან და რესურსებიდან მონაცემების შესაგროვებლად, ზოგჯერ მონაცემების მისაღებად სხვა გზა უბრალოდ არ არსებობს.

ჩემი მთავარი რჩევა: ისწავლე პითონი!

პანდა

მაგალითისთვის ავიღოთ შემდეგი კოდი:

import pandas as pd
df = pd.read_csv(“data/dataset.csv”)
# Calculate and rename aggregations
all_together = (df[df[‘trip_type’] == “return”]
    .groupby(['start_station_name','end_station_name'])
                  	    .agg({'trip_duration_seconds': [np.size, np.mean, np.min, np.max]})
                           .rename(columns={'size': 'num_trips', 
           'mean': 'avg_duration_seconds',    
           'amin': min_duration_seconds', 
           ‘amax': 'max_duration_seconds'}))

არსებითად, ჩვენ ვხედავთ, რომ კოდი ჯდება კლასიკურ SQL შაბლონში.

SELECT start_station_name, end_station_name, count(trip_duration_seconds) as size, …..
FROM dataset
WHERE trip_type = ‘return’
GROUPBY start_station_name, end_station_name

მაგრამ მნიშვნელოვანი ნაწილი ის არის, რომ ეს კოდი არის სკრიპტისა და მილსადენის ნაწილი; სინამდვილეში, ჩვენ ვნერგავთ შეკითხვებს Python მილსადენში. ამ სიტუაციაში, შეკითხვის ენა ჩვენთან მოდის ბიბლიოთეკებიდან, როგორიცაა Pandas ან pySpark.

ზოგადად, pySpark-ში ჩვენ ვხედავთ მონაცემთა ტრანსფორმაციის ანალოგიურ ტიპს შეკითხვის ენის საშუალებით:

df.filter(df.trip_type = “return”)
  .groupby(“day”)
  .agg({duration: 'mean'})
  .sort()

სად და რა წავიკითხოთ

ზოგადად თავად პითონზე პრობლემა არ არის იპოვნეთ შესასწავლი მასალები. ონლაინ გაკვეთილების დიდი რაოდენობაა pandas, pySpark და კურსები ნაპერწკალი (და ასევე თავისთავად DS). მთლიანობაში, კონტენტი აქ შესანიშნავია გუგლინგისთვის და თუ ერთი პაკეტის არჩევა მომიწია, რომელზეც ფოკუსირება მომიწევდა, ეს, რა თქმა უნდა, პანდები იქნებოდნენ. რაც შეეხება DS+Python მასალების კომბინაციასაც ძალიან ბევრი.

Shell, როგორც შეკითხვის ენა

მონაცემთა დამუშავებისა და ანალიზის საკმაოდ ბევრი პროექტი, რომლებთანაც მე მიმუშავია, არის, ფაქტობრივად, ჭურვის სკრიპტები, რომლებიც იძახიან კოდს Python-ში, Java-ში და თავად shell ბრძანებებს. მაშასადამე, ზოგადად, შეგიძლიათ მილსადენები განიხილოთ bash/zsh/ და ა.შ., როგორც ერთგვარი მაღალი დონის მოთხოვნა (რა თქმა უნდა, შეგიძლიათ ჩართოთ მარყუჟები, მაგრამ ეს არ არის დამახასიათებელი DS კოდისთვის ჭურვის ენებზე), მოდით მივცეთ მარტივი მაგალითი - მე მჭირდებოდა ვიკიმონაცემების QID რუკების გაკეთება და სრული ბმულები რუსულ და ინგლისურ ვიკიებზე, ამისთვის დავწერე მარტივი მოთხოვნა ბრძანებებიდან bash-ში და გამოსავალისთვის დავწერე მარტივი სკრიპტი Python-ში, რომელიც მე შეკრიბეთ ასე:

pv “data/latest-all.json.gz” | 
unpigz -c  | 
jq --stream $JQ_QUERY | 
python3 scripts/post_process.py "output.csv"

სადაც

JQ_QUERY = 'select((.[0][1] == "sitelinks" and (.[0][2]=="enwiki" or .[0][2] =="ruwiki") and .[0][3] =="title") or .[0][1] == "id")' 

ეს იყო, ფაქტობრივად, მთელი მილსადენი, რომელმაც შექმნა საჭირო რუქა; როგორც ვხედავთ, ყველაფერი მუშაობდა ნაკადის რეჟიმში:

• pv ფაილის გზა - იძლევა პროგრესის ზოლს ფაილის ზომაზე დაყრდნობით და გადასცემს მის შინაარსს შემდგომში
• unpigz -c წაიკითხა არქივის ნაწილი და მისცა jq-ს
• jq გასაღებით - ნაკადმა მაშინვე გამოუშვა შედეგი და გადასცა პოსტპროცესორს (იგივე როგორც პირველ მაგალითში) პითონში
• შინაგანად, პოსტპროცესორი იყო მარტივი სახელმწიფო მანქანა, რომელიც აფორმებდა გამომავალს 

საერთო ჯამში, რთული მილსადენი, რომელიც მუშაობს ნაკადის რეჟიმში დიდ მონაცემებზე (0.5 ტბ), მნიშვნელოვანი რესურსების გარეშე და დამზადებულია მარტივი მილსადენისა და რამდენიმე ხელსაწყოსგან.

კიდევ ერთი მნიშვნელოვანი რჩევა: შეძლოთ კარგად და ეფექტურად იმუშაოთ ტერმინალში და დაწეროთ bash/zsh/ და ა.შ.

სად იქნება ის სასარგებლო? დიახ, თითქმის ყველგან - ისევ, ინტერნეტში უამრავი მასალაა შესასწავლი. კერძოდ, აქ ამ ჩემი წინა სტატია.

R სკრიპტირება

კიდევ ერთხელ, მკითხველმა შეიძლება წამოიძახოს - კარგი, ეს არის მთელი პროგრამირების ენა! და რა თქმა უნდა, ის მართალი იქნება. თუმცა, მე ჩვეულებრივ ვხვდებოდი R-ს ისეთ კონტექსტში, რომ, ფაქტობრივად, ძალიან ჰგავდა შეკითხვის ენას.

R არის სტატისტიკური გამოთვლითი გარემო და ენა სტატიკური გამოთვლისა და ვიზუალიზაციისთვის (შესაბამისად ამ).

აღებული აქედან გამომდინარე,. სხვათა შორის, გირჩევთ, კარგი მასალაა.

რატომ სჭირდება მონაცემთა მეცნიერს R-ის ცოდნა? ყოველ შემთხვევაში, იმიტომ, რომ არსებობს არა-IT ადამიანების უზარმაზარი ფენა, რომლებიც აანალიზებენ მონაცემებს R-ში. მე მას შემდეგ ადგილებში შევხვდი:

• ფარმაცევტული სექტორი.
• ბიოლოგები.
• Ფინანსური სექტორი.
• წმინდა მათემატიკური განათლების მქონე ადამიანები, რომლებიც სტატისტიკას ეხება.
• სპეციალიზებული სტატისტიკური მოდელები და მანქანათმცოდნეობის მოდელები (რომლებიც ხშირად გვხვდება მხოლოდ ავტორის ვერსიაში, როგორც R პაკეტი).

რატომ არის ის სინამდვილეში შეკითხვის ენა? იმ ფორმით, რომელშიც ის ხშირად გვხვდება, ეს არის რეალურად მოდელის შექმნის მოთხოვნა, მათ შორის მონაცემების წაკითხვა და შეკითხვის (მოდელის) პარამეტრების დაფიქსირება, ასევე მონაცემთა ვიზუალიზაცია პაკეტებში, როგორიცაა ggplot2 - ეს ასევე არის მოთხოვნების დაწერის ფორმა. .

კითხვების მაგალითები ვიზუალიზაციისთვის

ggplot(data = beav, 
       aes(x = id, y = temp, 
           group = activ, color = activ)) +
  geom_line() + 
  geom_point() +
  scale_color_manual(values = c("red", "blue"))

ზოგადად, ბევრი იდეა R-დან გადავიდა პითონის პაკეტებში, როგორიცაა pandas, numpy ან scipy, როგორიცაა მონაცემთა ჩარჩოები და მონაცემთა ვექტორიზაცია - ასე რომ, ზოგადად R-ში ბევრი რამ თქვენთვის ნაცნობი და მოსახერხებელი მოგეჩვენებათ.

ბევრი წყაროა შესასწავლი, მაგალითად, ამ.

ცოდნის გრაფიკები

აქ მე მაქვს ოდნავ უჩვეულო გამოცდილება, რადგან საკმაოდ ხშირად მიწევს მუშაობა ცოდნის გრაფიკებთან და გრაფიკების შეკითხვის ენებთან. აქედან გამომდინარე, ჩვენ მხოლოდ მოკლედ გადავალთ საფუძვლებზე, რადგან ეს ნაწილი ცოტა უფრო ეგზოტიკურია.

კლასიკურ რელაციურ მონაცემთა ბაზებში გვაქვს ფიქსირებული სქემა, მაგრამ აქ სქემა მოქნილია, თითოეული პრედიკატი რეალურად არის "სვეტი" და კიდევ უფრო მეტი.

წარმოიდგინეთ, რომ თქვენ აყალიბებდით ადამიანს და გინდოდათ აღეწერათ ძირითადი რამ, მაგალითად, ავიღოთ კონკრეტული ადამიანი, დუგლას ადამსი და გამოვიყენოთ ეს აღწერა საფუძვლად.

www.wikidata.org/wiki/Q42

თუ გამოვიყენებდით რელაციურ მონაცემთა ბაზას, უნდა შეგვექმნა უზარმაზარი ცხრილი ან ცხრილები დიდი რაოდენობით სვეტებით, რომელთა უმეტესობა იქნება NULL ან შევსებული ნაგულისხმევი False მნიშვნელობით, მაგალითად, ნაკლებად სავარაუდოა, რომ ბევრ ჩვენგანს ჰქონდეს ჩანაწერი კორეის ეროვნულ ბიბლიოთეკაში - რა თქმა უნდა, ჩვენ შეგვიძლია მათი განთავსება ცალკე ცხრილებში, მაგრამ ეს საბოლოო ჯამში იქნება მოქნილი ლოგიკური სქემის მოდელირების მცდელობა პრედიკატებით ფიქსირებული რელაციურის გამოყენებით.

ასე რომ წარმოიდგინეთ, რომ ყველა მონაცემი ინახება როგორც გრაფიკი ან როგორც ორობითი და უნარული ლოგიკური გამონათქვამები.

სად შეიძლება შეხვდე ამას? პირველ რიგში, მუშაობა მონაცემთა ვიკიდა ნებისმიერი გრაფიკის მონაცემთა ბაზებით ან დაკავშირებული მონაცემებით.

ქვემოთ მოცემულია შეკითხვის ძირითადი ენები, რომლებითაც მე გამოვიყენე და ვიმუშავე.

SPARQL

ვიკი:
SPARQL (რეკურსიული აკრონიმი საწყისი Eng. SPARQL პროტოკოლი და RDF შეკითხვის ენა) - მონაცემთა შეკითხვის ენა, წარმოდგენილი მოდელით RDFდა ოქმი გადასცეს ეს მოთხოვნები და უპასუხოს მათ. SPARQL არის რეკომენდაცია W3C კონსორციუმი და ერთ-ერთი ტექნოლოგია სემანტიკური ქსელი.

მაგრამ სინამდვილეში ეს არის შეკითხვის ენა ლოგიკური ერთიანი და ორობითი პრედიკატებისთვის. თქვენ უბრალოდ პირობითად აკონკრეტებთ რა არის დაფიქსირებული ლოგიკურ გამონათქვამში და რა არა (ძალიან გამარტივებული).

თავად RDF (Resource Description Framework) ბაზა, რომელზედაც სრულდება SPARQL მოთხოვნები, არის სამმაგი. object, predicate, subject - და შეკითხვა ირჩევს საჭირო სამეულებს მითითებული შეზღუდვების მიხედვით: იპოვეთ X ისეთი, რომ p_55(X, q_33) იყოს ჭეშმარიტი - სადაც, რა თქმა უნდა, p_55 არის ერთგვარი კავშირი ID 55-თან და q_33 არის ობიექტი ID 33-ით (აქ და მთელი ამბავი, ისევ ყველანაირი დეტალის გამოტოვებით).

მონაცემთა პრეზენტაციის მაგალითი:

სურათები და მაგალითი ქვეყნებთან აქ აქედან გამომდინარე,.

ძირითადი შეკითხვის მაგალითი

სინამდვილეში, ჩვენ გვინდა ვიპოვოთ ?country ცვლადის მნიშვნელობა ისეთი, რომ პრედიკატისთვის
Member_of, მართალია, წევრი_of(?country,q458) და q458 არის ევროკავშირის ID.

რეალური SPARQL შეკითხვის მაგალითი პითონის ძრავში:

როგორც წესი, მე უნდა წავიკითხო SPARQL, ვიდრე დამეწერა - ამ სიტუაციაში, სავარაუდოდ, სასარგებლო იქნება ენის გაგება, სულ მცირე, საბაზისო დონეზე, რათა გავიგო ზუსტად როგორ ხდება მონაცემების მოძიება. 

ინტერნეტში შესასწავლი უამრავი მასალაა: მაგალითად, აქ ამ и ამ. მე ჩვეულებრივ ვგუგლებ კონკრეტულ დიზაინებსა და მაგალითებს და ეს საკმარისია ამ დროისთვის.

ლოგიკური შეკითხვის ენები

ამ თემაზე მეტი შეგიძლიათ წაიკითხოთ ჩემს სტატიაში აქ. და აქ ჩვენ მხოლოდ მოკლედ განვიხილავთ, თუ რატომ არის ლოგიკური ენები კარგად მორგებული კითხვების დასაწერად. არსებითად, RDF არის მხოლოდ p(X) და h(X,Y) ფორმის ლოგიკური განცხადებების ნაკრები, ხოლო ლოგიკურ შეკითხვას აქვს შემდეგი ფორმა:

output(X) :- country(X), member_of(X,“EU”).

აქ საუბარია ახალი პრედიკატის გამომავალი/1-ის შექმნაზე (/1 ნიშნავს ერთეულს), იმ პირობით, რომ X-ისთვის მართალია, რომ ქვეყანა(X) - ანუ, X არის ქვეყანა და ასევე წევრი_of(X,"EU").

ანუ ამ შემთხვევაში მონაცემებიც და წესებიც ერთნაირად არის წარმოდგენილი, რაც გვაძლევს პრობლემების ძალიან მარტივად და კარგად მოდელირების საშუალებას.

სად შეხვდით ინდუსტრიაში?: მთელი დიდი პროექტი კომპანიასთან, რომელიც წერს შეკითხვებს ასეთ ენაზე, ისევე როგორც მიმდინარე პროექტზე სისტემის ბირთვში - როგორც ჩანს, ეს საკმაოდ ეგზოტიკური რამ არის, მაგრამ ზოგჯერ ეს ხდება.

კოდის ფრაგმენტის მაგალითი ლოგიკური ენის დამუშავების ვიკიმონაცემებში:

მასალები: მე მივცემ აქ რამდენიმე ლინკს თანამედროვე ლოგიკური პროგრამირების ენაზე Answer Set Programming - გირჩევთ მის შესწავლას:

• http://peace.eas.asu.edu/aaai12tutorial/asp-tutorial-aaai.pdf
• http://ceur-ws.org/Vol-1145/tutorial1.pdf
• https://www.youtube.com/watch?v=gVQ0bP8zyHw
• https://www.youtube.com/watch?v=kdcd7Je2glc
• https://potassco.org/book/
• http://potassco.sourceforge.net/teaching.html
• https://www.cs.uni-potsdam.de/~torsten/Potassco/Tutorials/fmcad12.pdf

წყარო: www.habr.com