HTML

Szemantikus web

A HTML alapú web elérkezett a határaihoz, itt az ideje a technológiai és szemléletváltásnak! A blogban megjelent írások szerzője Hidvégi Gábor, a bemutatott ötletek és megoldások jogtulajdonosa.

Friss topikok

  • fodor balazs: Az XSLT tényleg egy okos állatfaj, csak elég kevés esélyt látok az elterjedésére én is. Ehelyett i... (2011.03.19. 20:13) Szemantika a HTML-ben
  • Hidvégi Gábor: @arsen: az Apple-t a saját érdekei vezérlik, például a HTML5-öt azért favorizálja, mert nagyobb ko... (2011.03.16. 23:39) Mire van szükségünk HTML 5 helyett?
  • Hidvégi Gábor: @hrgy: az oda-vissza gombok használata résztartalom-váltás esetén azért is problémás, mivel a docu... (2011.03.15. 22:11) A HTML oldalak gyorstárazása

Szemantika a HTML-ben

2011.02.28. 22:54 Hidvégi Gábor

Szemantika = jelentéstan, nézzük át, hogy a web alapvető adattárolási nyelvében, a HTML-ben milyen módon adhatjuk meg egy szöveg vagy szövegrész jelentését!

A HTML elemeknek van szemantikája, például van fejléc, lábléc, cikk (article) elem – jelezheti mindjárt néhány tájékozott olvasó, viszont ki kell ábrándítsam őket: ezek csak az adott szöveg logikai felépítését írják le, de a szöveg jelentéséről semmilyen információt nem tartalmaznak.

Itt van például ez a blogbejegyzés: a cím alatt található egy dátum, de igazából ránézésre nem lehet megmondani, hogy minek az időpontját mutatja. A cikk létrehozásának dátumát? Az utolsó mentés dátumát? A cikk élesítésének dátumát? Ha megnézzük a forráskódot, ott is csupán a class attribútum utalhat erre, de annak értéke "date", tehát nem vagyunk előrébb. Ez csak egy kiragadott példa, de körbennézve bármelyik weboldalon, ezer hasonló adatot találhatunk, amik „csak úgy vannak”, s bár mi, emberek ránézésre el tudjuk dönteni, mit jelentenek, gépileg ez a mai eszközökkel szinte lehetetlen, de mindenesetre rendkívül bonyolult mesterséges intelligencia szükséges.

A HTML klasszikusan a szöveg jelentésére csak két eszközt biztosít: a description és keywords meta tag-eket. Ezek használata rendkívül korlátozott, mivel a description az egész oldal leírására szolgál, míg a keywords-ben található kulcsszavak nem párosíthatóak az oldal tartalmában található tartalmi blokkokkal.

Az úgynevezett "web2" egyik legnagyobb újítása az volt, hogy magukat a tartalmi blokkokat jelölhetjük meg címkékkel, magyarul tag-ekkel. Ezáltal elvileg összeköthetővé válhatnának az azonos témájú tartalmak, nem csak egy oldalon belül, hanem akármilyen mennyiségű weboldalon.

Tehát csak ez a találmány forradalmasíthatta volna az internetet – legalábbis technológiailag, majd később egészében –, de ez elmaradt, köszönhetően az internetes szabványokat készítő W3C testület teljes nemtörődömségének. A címkézés olyan mérföldkő, amit azonnal be kellett volna emelni a HTML szabványba, persze a megfelelő kidolgozás után.

Gondoljunk csak bele! Először is meg kéne jelölni, hogy az adott címke melyik HTML tartalmi blokkra vonatkozik (például egy id-vel), hogy az könnyen azonosítható legyen. Második körben létre kéne hozni egy központi adatbázist, amiben a címkék feliratait tároljuk különböző nyelveken, hogy nyelvfüggetlenül összeköthessük az azonos témájú tartalmakat. Ha például arra keresek rá, hogy Fidzsi-szigetek, akkor valószínűleg a legtöbb és legrelevánsabb információt hindi nyelven találom meg (és az már legyen a fordítóprogram feladata, hogy a saját nyelvemen jelenítse meg a szöveget). Az internetes oldalak hirtelen egy nagy, összefüggő masszává válnának, jóval relevánsabb találatokkal.

E fejlesztés nélkül korlátozzuk magunkat az anyanyelvünkre, valamint az általunk beszélt egy-két idegen nyelvre, de a világ internetes tartalmának jórészét gyakorlatilag nem tudjuk így elérni.

A 2014-ben megjelenő HTML 5-ben erre a problémára a W3C egy megoldást ad: a linkeknek megadhatunk egy olyan attribútumot, hogy "tag", azaz kb. így néznek majd ki:

<a rel="tag" href="http://domain/link">Fidzsi-szigetek</a>

Én ezt a következőképp tudnám elképzelni, feltételezve, hogy a korábbi bekezdésben említett központi adatbázis nyelve angol:

<div id="fiji_szigetek">A Fidzsi-szigetek leírása ...</div>
<a tag="fiji" tag-content-id="fiji_szigetek" href="http://domain/link">Címke</a>

A HTML5 ajánláson dolgozó csoport tagjai olyan nagy cégek, böngészőgyártók, akik nagy befolyással vannak mindennapjainkra, mind például a Mozilla, az Apple, Microsoft, Google stb. Nem elég, hogy lassan dolgoznak (a HTML verzióváltására tizennégy évet kell összességében várni), még a valós problémákat is képtelenek felismerni és azokra választ adni. Ehelyett az aktuális divatirányzatoknak szeretnének megfelelni, nem törődve azzal, hogy mekkora kárt okozhatnak ezzel hosszú távon.

A probléma igazából a HTML-lel van, pontosabban azzal, hogy nem a helyén kezeljük. Tisztázni kell: a HTML se több, se kevesebb, mint adatok megjelenítésének leírónyelve. A kulcsszó a „megjelenítés”, tehát leegyszerűsítve azt a feladatot kell ellátnia, hogy az adatok milyen színnel és milyen méretben jelenjelenek meg. Magukat az adatokat teljesen külön kell választani a megjelenésüktől, ellenkező esetben a szemantikus keresés bevezetését nehezítjük meg, és - minden ellenkező híreszteléssel ellentétben - technológiailag továbbra is maradunk a web 1.0 szintjén.

Erre a szétválasztásra a mai technológiai eszközökkel már megvan a lehetőség, a következő lépés az internetes fejlesztők szemléletváltása. A HTML5 bevezetésével csak a jelenlegi állapotokat konzerváljuk – az eddigiekből kiindulva újabb másfél évtizedre –, és mivel ezzel a nyelvvel amúgy sem nyerünk sokat – tehát a legtöbb „újítása” helyettesíthető már létező eszközökkel –, a szabványosítás folyamatát véleményem szerint azonnal le kell állítani, és ki kell dolgozni egy olyan életképes módszert, amivel minél hamarabb szemantikus alapra helyezhetjük az internetet.

13 komment

Címkék: html szabvány jelentés w3c szemantika html 5

A bejegyzés trackback címe:

https://szemantikus.blog.hu/api/trackback/id/tr412699886

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

arsen 2011.03.16. 13:28:15

Nekem is a tagcloud a kedvenc példám, vicces, hogy épp az ellenkezőjét bizonyítom vele.

Egészítsd ki a példát csak annyival, mint ahogy itt a bloghun is szokott lenni, hogy a betű mérete attól függ, hogy milyen gyakran szerepel a címke. Ezt a feladatot strict MVC-ben lehetetlen megoldani, valahol mindenképp össze fog keveredni a logika és a megjelenítés.

Másik amit nem értek, hogy persze, hogy a html egyben van. De miért gond ez? Minden kérés a szervernek megy, ami azt ad vissza, amit akar. Egyáltalán nem kötelező az egész lapot kiadni, AJAX-os válaszokban nyilván csak az a blokk lesz, ami épp frissült vagy kell.

Abban értek egyet veled, hogy szerintem is szemléletváltásra lenne szükség, csak pont nem arra. :) Szerintem kukázni kéne az MVC-t, be kellene látni, hogy nem vált be, mert nem csak egy tagcloudban, hanem a weben sehol NEM független a tartalom a megjelenésétől. Épp ellenkezőleg, olyannyira összefügg vele, hogy azzal válik teljessé a szemantika.

Hidvégi Gábor · http://szemantikus.blog.hu/ 2011.03.16. 13:37:35

@arsen: A szemantikus.blog.hu/2011/02/23/a_html_oldalak_gyorstarazasa bejegyzésemben leírom, hogy milyen előnyökkel járna, ha a HTML több darabból állna: a különböző szekciók más-más időközönként frissülnek, mivel más tartalom van bennük. Ha eleve adatblokkokban gondolkodnánk, jelentősen csökkenhetne az internetes adatforgalom és gyorsulhatna az oldalak megjelenítési sebessége.

A mostani weblap alapú szemlélet következménye, hogy összefügg a megjelenés és a tartalom, aminek persze az az előnye, hogy könnyű létrehozni márkasite-okat, de hátránya, hogy a felhasználó olyan adatokat is kap, amit nem kért.

arsen 2011.03.16. 14:27:37

Szerintem nem gyorsulhatna semmit, viszont biztos hogy lassítaná a fejlesztés ütemét.

Ha lassú egy oldal, azon rengeteget lehet optimalizálni. Meg ha csak adatokról van szó (szöveg), ott nem szabad gondnak lennie a .sebességgel Valahol máshol van a gond, ha mégis.

A második részét nem értem, XML+XSLT már nem weblap alapú szemlélet? Akkor annak mi a kimenete?

De szerintem amúgy tévedsz, az ok nagyjából a mondásból ered, hogy "a stílus maga az ember". A weblap (vagy alkalmazás) meg maga a design. :)

arsen 2011.03.16. 14:31:09

És még egy hiba, nem hiszem el, bocsánat:
a design maga a weblap (vagy alkalmazás), ezt akartam írni.

Hidvégi Gábor · http://szemantikus.blog.hu/ 2011.03.16. 14:54:06

@arsen: végy egy portált, és próbáld meg sebességre optimalizálni. Ezer különböző adat, egyszerűen lehetetlen, nem fog menni, vagy csak olyan áron, amit nem fizet meg senki.

Az XML + XSLT már nem weblap, hanem adat alapú szemlélet, az más kérdés, hogy a kimenet HTML esetünkben, de ez amiatt van, hogy a böngészők és a keresők is fel tudják dolgozni. Viszont így könnyebbé válik a gépi feldolgozás, tehát ezt nyertük vele.

Ha az elejétől elolvasod a blogon leírtakat, akkor meg fogod érteni, hogy erre miért van szükség, és miért előremutatóbb az XML alapú web, mint a HTML alapú.

arsen 2011.03.16. 21:04:29

Hogy mi a célja, és miért tartod előremutatóbbnak, az világos. Az érvelést nem értettem helyenként, de azt most sem, hogy elolvastam az összes cikket.

Nem abba kötök bele, hogy itt is HTML a kimenet, hanem azt írtad, hogy a weblap alapú szemlélet következménye, hogy összefügg a megjelenés és a tartalom. Szóval akkor adat alapú szemléletben nem függ össze? Ez az, ami nem igaz szerintem.

De egyszerűen meg tudsz győzni, ha megcsinálod a tagcloudos példámat, vonok vissza mindent azonnal.

Hidvégi Gábor · http://szemantikus.blog.hu/ 2011.03.16. 23:30:59

@arsen: az egész elmélet célja, hogy a gépi feldolgozást megkönnyítsük, amikor egy keresőrobot ellátogat az oldalunkra, értse is, hogy mi van odaírva. A következő dolog az összefüggések megkeresése, és akkor már sokkal relevánsabb találatokat kaphatunk.

A HTML humán fogyasztásra készült, azaz adatainkat jobbára grafikusan jeleníti meg, de emiatt rengeteg fölösleges információt tartalmaz, amire a gépi feldolgozás során nincs szükség.

Tegyük fel, hogy van a következő adatstruktúra:
<szamitogep>
<processzor>AMD 3200</processzor>
<videokartya>NVidia 4340</videokartya>
<merevlemez>Seagate 500GB</merevlemez>
<ar>150000</ar>
</szamitogep>

A webshopod oldalán ezt megjeleníted szép, táblázatos formátumban, a látogató elolvassa és rákattint a Megveszem! feliratú gombra.

Valahol a világban egy random emberke kitalálja, szeretne egy számára megfelelő konfigurációt venni, ezért megnyitja azt a webes szolgáltatást, amelyik a PC-kre szakosodott. Ez a szolgáltatás annyit csinál, hogy összegyűjti azokat az oldalakat, ahol <szamitogep> objektumok vannak (hogy milyen módon, az most lényegtelen), és különböző szempontok szerinti szűrést tesz lehetővé, például a merevlemez kapacitása vagy a konfiguráció ára alapján.

Ez utóbbi esetben az emberkénket nem érdekli a te oldalad kinézete, hogy milyen csillivilli táblázatba pakoltad bele a fenti számítógép adatait. Őt az érdekli, hogy 300 gigabájtnál nagyobb legyen a merevlemez mérete, de az ára legyen 120 000 forint alatt.

Tehát nincs szoros összefüggés az adat és a megjelenés között, így érthető? Az XML + XSLT erre nyújt egyfajta megoldást.

Hidvégi Gábor · http://szemantikus.blog.hu/ 2011.03.16. 23:33:03

@arsen: ha valahol nem érthető az érvelésem, kérlek téged és kérek mindenkit, hogy jelezze. Rengeteg gondolat jár a fejemben, és lehet, hogy amit leírok, az számomra evidens, mert egy bizonyos logika alapján gondolkozom, de nagy valószínűséggel nem mindenki ugyanúgy fogja látni.

arsen 2011.03.17. 12:50:36

@Hidvégi Gábor: igen, így már értem. És szomorúan látom, hogy olyasmire keresel megoldást, ami nem is probléma. HTML mellett is lehet XML, ha erre van igény. Tudom, hogy csak példát írtál, de boltgyűjtő szolgáltatást legalább három van már (depó, árukereső, olcsóbbat), és jóval többet tudnak, mint simán listázni. Valahogy csak megoldották...

Meg ha nincs külön XML (nem partner), lehet parse-olni a html-t is akár, miért ne? Szolgáltatás is van rá, de lehet írni saját parsert is, ha valakinek erre van szüksége.

Általánosan ezt nem lehet bevezetni. El se tudnám képzelni azt a szabványt, ami ezeket az objektumelnevezéseket rögzítené. És ki tartaná be? XHTML Strictet se sikerült megugrani szerintem a szájtok 10%-nak sem a legnagyobb hype idején sem. És a HTML5 lazult hozzá képest, ezért is ilyen közkedvelt. Esélytelen most egy még sokkal szigorúbb szabványt betartatni.

Egyedi esetekben talán lenne helye, de akkor ezeket meg kell találni, hogy milyen feladatra ez a minden szempontból legjobb megoldás.

Hidvégi Gábor · http://szemantikus.blog.hu/ 2011.03.17. 13:59:34

@arsen: a probléma létezik, legfeljebb nem fogalmaztam érthetően.

Megnéztem az általad említett oldalakat, mindegyiknél egy általuk megkövetelt adatformátumban kell feltölteni az adataidat, és úgy jelennek meg az ő rendszerükben. Ezzel szemben én azt mondom, hogy magukon a weboldalakon eleve a "nyers" adatok legyenek fenn, egységes formátumban, így gépileg jóval egyszerűbb lesz az összegyűjtésük és feldolgozásuk.

Lehet a HTML-t is parse-olni, de jelen pillanatban - mivel a HTML-t arra használjuk, hogy emberi fogyasztásra tervezték és használjuk - ugyanaz az adat millió és millió formában jelenik meg, mert az egyik oldalnak ilyen a HTML kódja, a másiknak olyan. Ezért minden egyes weboldalhoz külön parsert kell írni, pedig ha mondjuk az előző hozzászólásomban mutatott példában szereplő számítógépek mind ilyen formában kerülnének a világon a weblapokra:

<szamitogep>
<processzor>AMD 3200</processzor>
<videokartya>NVidia 4340</videokartya>
<merevlemez>Seagate 500GB</merevlemez>
<ar>150000</ar>
</szamitogep>

akkor rendkívül egyszerű lenne ezeket összegyűjteni. Jelenleg korlátokba ütközünk, és ezek a HTML korlátai, mivel az csak szöveges információ megjelenítésére alkalmas, és ebből kifolyólag a keresők is csak erre alkalmasak. Adatok keresésére nem.

"Általánosan ezt nem lehet bevezetni. El se tudnám képzelni azt a szabványt, ami ezeket az objektumelnevezéseket rögzítené."

Pedig már léteznek ilyen adatbázisok, ajánlom a következő oldalakat elolvasni:
www.w3.org/standards/semanticweb/
dbpedia.org/About

És egy példa:
dbpedia.org/page/Category:Luxury_vehicles
dbpedia.org/data/Category:Luxury_vehicles.rdf

A Google tavaly vásárolta meg a Metaweb nevű céget, ami pont ilyen szemantikus adatbázist épít, bár az inkább személyes kapcsolatokat és médiainformációkat tárol.
gigaom.com/2010/07/16/google-gets-semantic-buys-metaweb/

Tehát a szemantikus webre és az adatok jelentésének megadására szükség van. Viszont ennek nyílt alapokra kell épülnie, nem szabad magáncégek kezébe adni, mert azok visszaélhetnek vele, pont a Google botrányairól írtam már egy bejegyzést, kecskére nem bízunk káposztát.

"XHTML Strictet se sikerült megugrani" - erre csak azt mondom, hogy hulljon a férgese, nem kell annyi embernek webes fejlesztéssel foglalkozni.

Nekem már van működő weboldalam, ami erre az elméletre épül, sőt, egy csomó más nyalánkság is van benne, és be is fogom mutatni, de előbb a problémát szerettem volna az első bejegyzésekben vázolni, hogy minél érthetőbb legyen.

arsen 2011.03.18. 01:53:25

Dehogyis tervezték emberi fogyasztásra, legalábbis gondolom, ezt a hozzászólást se a forrásban olvasod. :) Az a weblap. A html-t azt böngészőknek tervezték.

Ilyen apró csúsztatásokon el lehet menni rendesen...

Utópia a szemantikus web szerintem, fejlesztői ábrándozás, idealizmus, elméleti programozás... ezzel egyedül azok járnának jól, akik egy ilyen keresőn vagy gyűjtőszolgáltatáson dolgoznak. Mindenki másnak csak költség.

De nem akarom elvenni a kedved. Meg lehet, majd annyira tetszeni fog majd az oldalad, hogy meg leszek győzve azonnal.

fodor balazs 2011.03.19. 20:13:42

Az XSLT tényleg egy okos állatfaj, csak elég kevés esélyt látok az elterjedésére én is. Ehelyett inkább valami RDFa, mikroformátumok, vagy valami hasonló futhat be esetleg. Bár ennek az XSLT-s mókának jobban örülnék. Minap amúgy belefutottam egy olyan oldalba, ahol ezt használják. Valami WoWos oldal volt, egyik ismerősöm az egyik karakterét mutogatta.