Extensibilitate eXtreme (XML Schema de proiectare pentru web-ul semantic)

Original: http://www.xfront.com/eXtreme-eXtensibility.html


de Roger L. Costello
25 ianuarie de 2003

Problemă: cum putem concepe o schemă XML, astfel încât îl plasează fără restricții cu privire la vocabularul că documentele instanță folosesc, și care facilitează creșterea de date într-o manieră extrem de distribuit?

Folosește de model eXtreme extensibilitate design
Acest document descrie un mod de proiectare Scheme XML care permite ca datele să fie colectate (și stocate ca XML) în, mod independent distribuit, și fără restricții cu privire la vocabularul XML. Modelul de proiectare care este prezentat este utilă în special în situațiile în care:

  •     ați dori să colecteze date despre ceva (și stoca date ca XML), și
  •     doriți, pentru a permite ca datele să fie colectate de către diverse persoane (care este, datele sunt colectate într-un mod distribuit), și
  •     doriți pentru a permite date neprevăzute (care este, nu există limite cu privire la vocabularul XML angajat), și
  •     ai vrea să fie în măsură pentru a agrega toate datele distribuite pentru a genera o imagine consolidată.


Iată câteva exemple de situații care ar putea beneficia de acest model de design:

  •     Descriind o de resurse geografica: de exemplu, pot exista mai multe echipe independente de oameni de stiinta care colectează date despre un vulcan activ. Ar fi benefic pentru a permite fiecărei echipe de a publica datele în mod independent, și apoi într-un moment mai târziu agregat toate datele. Un alt exemplu în această categorie este colectarea de date cu privire la un râu. Voi folosi acest lucru ca exemplul meu de-a lungul acestei lucrări.
  •     Furnizarea de date de identificare despre o persoană: de exemplu, să presupunem că ești responsabil de o mica echipa de oameni însărcinate pentru a colecta date biografice despre Albert Einstein. Acest model de design schemă este ideal, deoarece permite fiecărui membru al echipei de a lucra și să publice în mod independent.
  •     Intelligence Colectarea: prin natura, colectarea de date de informații este o activitate distribuite. Acest model de design schemă susține că activitatea de colectare a datelor.


Acestea sunt doar câteva utilizări ale modelului de design schemă care vor fi prezentate în această lucrare. În general, ori de câte ori doriți de colectare de date, precum și activități de publicare pentru a profita de mediul web, atunci acest lucru este un model de design bun. În mod evident, utilizarea sa este limitat doar de imaginatia ta.

XML Schema clasică de design
Design Schema XML clasic este prescriptiv. Că este, schema identifică un tip de resursă și prescrie ceea ce este permis de date pentru acest tip de resursă. De exemplu, ia în considerare aceste date despre Yangtze River China:

<River id="Yangtze">
     <Length>6300 kilometers</Length>
     <StartingLocation>western China's Qinghai-Tibet Plateau</StartingLocation>
     <EndingLocation>East China Sea</EndingLocation>
</River>

Design clasic schemă ar declara un element River, format dintr-o secvență de elemente copil – Lungime, StartingLocation, și EndingLocation. De exemplu, aici este o schemă XML care urmează abordarea design clasic:

<element name="River">
    <complexType>
        <sequence>
            <element name="Length" type="string"/>
            <element name="StartingLocation" type="string"/>
            <element name="EndingLocation" type="string"/>
        </sequence>
        <attribute name="id" type="ID" use="required"/>
    </complexType>
</element>


Deficiențe ale clasică schemă de design într-un mediu Web
Documente instanță XML și, implicit, schemele XML sunt destinate a fi utilizate într-un mediu Web. Cu toate acestea, un design clasic XML Schema este în contradicție cu mediul Web, după cum vom vedea mai jos.

Abordarea Web a datelor – eXtreme extensibilitate!
Să presupunem că creați o pagină Web care conține date despre Yangtze River. Independent de tine, și fără știrea dvs., pot crea o pagină Web care conține alte date despre râul Yangtze. Și pot lega pagina mea de web la pagina dvs. de Web. Pagina Web adaugă valoare pagina mea de web și vice-versa. O a treia persoană poate crea un alt pagină Web care conține mai multe date despre fluviul Yangtze, și se leagă-l la ambele paginile noastre web. Un web bogat de date despre fluviul Yangtze este în curs de dezvoltare.

Notă caracteristicile acestei abordări Web pentru furnizarea de date cu privire la Yangtze River:

  1.     Datelor distribuite: datele despre râul Yangtze este distribuită pe mai multe pagini web.
  2.     Vocabular nelimitat: bogăția și cantitatea de date care sunt disponibile pentru a descrie râul Yangtze este limitat doar de imaginatia designerilor de pagini web.
  3.     Neordonată: nu există nici o ordine a datelor despre râul Yangtze. Paginile web hyperlink cuprinde o colecție neordonată a datelor.
  4.     Agregare: datele totală suma despre fluviul Yangtze este obținut prin agregarea datelor disparate pagina web.


Web-ul este un exemplu clasic de ceea ce Dee Hock se referă la o “chaord” (un sistem care are un amestec de haos și ordine).

Clasic Schema XML abordare a datelor
Un Schema tipică XML pentru definirea structurii și tipul de date admisibile despre fluviul Yangtze este prezentat aici:

<element name="River">
    <complexType>
        <sequence>
            <element name="Length" type="string"/>
            <element name="StartingLocation" type="string"/>
            <element name="EndingLocation" type="string"/>
        </sequence>
        <attribute name="id" type="ID" use="required"/>
    </complexType>
</element>

Schema XML specifică ceea ce este permis de date (“iti poate da lungimea fluviului, StartingLocation sa, iar EndingLocation ei”), și în ce ordine. Dacă creați o pagină Web XML, și pagina conformitate cu schema de mai sus, atunci acesta trebuie neapărat să fie limitată la tipul de date dictate de schema, de exemplu:

<River id="Yangtze">
     <Length>6300 kilometers</Length>
     <StartingLocation>western China's Qinghai-Tibet Plateau</StartingLocation>
     <EndingLocation>East China Sea</EndingLocation>
</River>

Dacă am crea o pagină Web XML, atunci pagina mea va arata la fel. Și dacă o terță persoană creează o pagină Web XML prea va arata la fel. Schema impune uniformitatea, reglementate, design de date controlat.

Să observăm caracteristicile clasice de abordare XML Schema pentru definirea date despre Yangtze River:

  1.     Datelor centralizate: chiar dacă nu pot fi mai multe site-uri web care conțin date despre fluviul Yangtze toate contin aceleasi date (vocabular). Astfel, există în mod eficient unul, date centralizate.
  2.     Vocabular limitat: bogăția și cantitatea de date care sunt furnizate pentru a descrie râul Yangtze este strict limitată de Schema XML. Modalități neprevăzute de a descrie râului Yangtze nu este activat.
  3.     Comandat de: există comanda strictă a datelor despre râul Yangtze.
  4.     Colectia: datele totală suma despre fluviul Yangtze este obținută prin a merge la oricare dintre site-uri Web și de colectare a datelor.

Recapitulare: Web Design Date Raport Classic XML Schema de date de proiectare
Mai jos este un tabel care rezumă discuția de mai sus.

XML Schemas Web
creșterea controlată a datelora creștere anarhic de date
date centralizate Date de distribuite
colecta date agregate de date
Design de date vertical design de date lateral


Utilizarea eficientă a XML și schemele XML într-o lume Web
Pentru a face XML, și implicit schemele XML, utilizabile într-o lume Web necesită o schimbare în modul în care noi de design Scheme XML și în modul în care ne gândim despre date.

Mai jos sunt cerințele cu privire la o schemă XML pentru descrierea râului Yangtze unde am face utilizarea eficientă a mediului Web:

  •     Vocabular nelimitat: Nu poate fi nici o restricție cu privire la conținutul elementului River. Acest lucru va permite de date neprevăzute. Orice vocabular că schema prevede ar trebui să fie considerate ca fiind doar un punct de plecare.
  •     Neordonată: Nu poate fi nici o restricție pe ordinea datelor

[Nota: anarhia completă ar plasa absolut nici o restricție cu privire la conținutul elementului River. De exemplu, aceasta ar permite elementului River să conțină o “fuselajului” elementul. Nu vrem anarhie completă. Vrem să permită orice elemente, atâta timp cât ele au sens pentru un râu.]

Următor vom vedea cum de a proiecta o schemă care să ia în considerare aceste cerințe.

XML Schema de proiectare pentru eXtreme extensibilitate!
Iată cum de a proiecta o schemă care îndeplinește cerințele de mai sus:

<element name="River">
    <complexType>
        <sequence>
            <any namespace="##targetNamespace" maxOccurs="unbounded"/>
        </sequence>
        <attribute name="id" type="ID" use="required"/>
    </complexType>
</element>
<element name="Length" type="string"/>
<element name="StartingLocation" type="string"/>
<element name="EndingLocation" type="string"/>

Să sublinieze caracteristicile cheie ale acestei scheme:

  •     Nu există nici o restricție cu privire la conținutul River, altele decât să spun că conținutul trebuie să aparțină acest spațiu de nume (cu alte cuvinte, vreau doar pentru a permite ca elemente de conținut care fac sens pentru elementul River).
  •     Un vocabular initial – Lungime, StartingLocation, EndingLocation – este prevăzută pentru utilizare în conținutul elementului River. Acest vocabular poate fi extins, după cum vom vedea.


Să ne întoarcem la exemplul celor trei oameni construirea de pagini web: vă creați o pagină Web care utilizează XML doar vocabularul prevăzut în schema:

<River id="Yangtze"
       xmlns="http://www.geodesy.org/river">
     <Length>6300 kilometers</Length>
     <StartingLocation>western China's Qinghai-Tibet Plateau</StartingLocation>
     <EndingLocation>East China Sea</EndingLocation>
</River>

Este important să rețineți că nu există nici o restricție privind ordonarea elementelor în cadrul River. Mai mult, nu există nici o restricție cu privire la numărul de apariții ale unui element (vom vedea un exemplu în acest sens de mai jos). Astfel, aceasta este o tehnică generală pentru a permite conținutul unui element să apară în orice ordine, și cu orice număr de apariții! Rețineți că această tehnică are similitudini cu <toate> element, dar este mult mai puternic!

Apoi, aș dori, de asemenea, pentru a crea o pagină Web XML cu privire la fluviul Yangtze, dar aș dori să furnizeze diferite de date – date despre celebrul barajul Three Gorges. Iată pagina mea de web XML:

<River id="Yangtze"
       xmlns="http://www.geodesy.org/river"
       xmlns:d="http://www.geodesy.org/dam">
     <Dam>
         <d:Name>The Three Gorges Dam</d:Name>
         <d:Width>1.5 miles</d:Width>
         <d:Height>610 feet</d:Height>
         <d:Cost>$30 billion</d:Cost>
     </Dam>
</River>

Elementul Dam nu este unul din vocabularul inițial că, schema XML declară, așa că va trebui să completeze vocabularul inițială prin crearea de propriul meu schemă care declară elementul Dam:

<include schemaLocation="River.xsd"/>
<import namespace="http://www.geodesy.org/dam"
        schemaLocation="Dam.xsd"/>

<element name="Dam">
    <complexType>
        <sequence>
            <any namespace="http://www.geodesy.org/dam" maxOccurs="unbounded"/>
        </sequence>
    </complexType>
</element>

Declarația pentru elementul Dam spune că conținutul său este nimic, atâta timp cât elementele provin din spațiul de nume http://www.geodesy.org/dam. Schema, Dam.xsd, definește ca spațiu de nume. Iată Dam.xsd:

<element name="Name" type="string"/>
<element name="Width" type="string"/>
<element name="Height" type="string"/>
<element name="Cost" type="string"/>

În cele din urmă, a treia persoană dorește să furnizeze date cu privire la diferitele nume care fluviul Yangtze a dobândit-a lungul timpului:

<River id="Yangtze"
       xmlns="http://www.geodesy.org/river">
     <Name>Dri Chu - Female Yak River</Name>
     <Name>Tongtian He, Travelling-Through-the-Heavens River</Name>
     <Name>Jinsha Jiang, River of Golden Sand</Name>
</River>

Deoarece această a treia persoană este de asemenea, folosind vocabular care nu este prezent în lista inițială de vocabular schemă, el / ea trebuie să completeze vocabularul inițială prin crearea unui schemă:

<include schemaLocation="River.xsd"/>

<element name="Name" type="string"/>

Rețineți că, deoarece elementul River pus nici o restricție cu privire la conținutul său, suntem capabili de a utiliza elementul Nume repetat.

Recapitularea Exemplul
Exemplul de mai sus a arătat cum o schemă XML poate fi proiectat pentru a permite fiecărei pagini Web XML să fie proiectate în mod independent și fără nici o restricție asupra a ceea ce sau cat de mult de date este prevăzut pentru râul Yangtze. Aceasta demonstrează un organism tot mai mare de informații cu privire la râul Yangtze. Instrumente agregator poate aduna toate piesele disparate de date (XML structurat) pentru a prezenta o imagine consolidată a râului Yangtze. Frumos!

Caracteristicile acestui model de proiectare
Aceasta lucrare a prezentat un mod de proiectare scheme care permite ca datele să fie colectate (și reprezentanți folosind XML) în, mod independent distribuit, și cu nici o restricție cu privire la vocabularul XML. Este important să se evidențieze caracteristicile cheie ale schemelor care folosesc acest model de design:

  1.     Scheme sunt mici: folosind acest model de design vă creați unul schemă pentru fiecare resursă (de exemplu, de a crea o schema pentru un râu), și oferă un set inițial de vocabular care poate fi utilizat cu această resursă (de exemplu, Lungime, StartingLocation, și EndingLocation) . Dacă aveți o resursă diferită (de exemplu, vulcan), atunci ar crea o schemă diferită (și furnizează un set inițial de vocabular care poate fi utilizat cu resursa vulcan).
  2.     Spațiu de nume = Clasa: cu acest model de design targetNamespace schema este definirea, în esență, o clasa (eg, targetNamespace pentru exemplul River a fost: http://www.geodesy.org/river Acest lucru poate fi interpretat ca “această schemă este definitorie. clasa râu “)


Agregare
Mai devreme m-am referit la capacitatea unui instrument de a agrega bucăți disparate de date și de a prezenta o imagine consolidată. Să ne acum uita-te la modul în care pentru a agrega datele disparate Yangtze River.

În exemplul am avut trei oameni care au creat date despre Yangtze River. Am terminat cu 3 scheme și 3 documente exemplu:

Cele 3 scheme
River.xsd: declarat elementul River, și a declarat setul initial de vocabular care poate fi utilizat pentru a popula elementul River – Lungime, StartingLocation, și EndingLocation.

River2.xsd: această schemă completează vocabularul inițial cu un element Dam.

River3.xsd: această schemă completează, de asemenea, vocabularul inițial cu un element de nume.

Cele 3 Instanță Documente
Yangtze.xml: acest document instanță a arătat lungimea, StartingLocation, și EndingLocation al râului.

Yangtze2.xml: acest document instanță a descris râului barajul Three Gorges.

Yangtze3.xml: acest document caz enumerat diferitele nume care râul a dobândit.

Punerea datele împreună
Un instrument agregator va asambla diferite date despre raul, pentru a crea un singur document:

<River id="Yangtze"
       xmlns="http://www.geodesy.org/river"
       xmlns:d="http://www.geodesy.org/dam">
     <Length>6300 kilometers</Length>
     <StartingLocation>western China's Qinghai-Tibet Plateau</StartingLocation>
     <EndingLocation>East China Sea</EndingLocation>
     <Dam>
         <d:Name>The Three Gorges Dam</d:Name>
         <d:Width>1.5 miles</d:Width>
         <d:Height>610 feet</d:Height>
         <d:Cost>$30 billion</d:Cost>
     </Dam>
     <Name>Dri Chu - Female Yak River</Name>
     <Name>Tongtian He, Travelling-Through-the-Heavens River</Name>
     <Name>Jinsha Jiang, River of Golden Sand</Name>
</River>

Astfel, acest document exemplu este un compozit de toate datele disparate despre râul Yangtze!

Pentru a valida documentul exemplu compozit instrumentul agregator trebuie compun toate declarațiile schemă într-un singur fișier. Iată schema rezultat:

<import namespace="http://www.geodesy.org/dam"
        schemaLocation="Dam.xsd"/>

<element name="River">
    <complexType>
        <sequence>
            <any namespace="##targetNamespace" maxOccurs="unbounded"/>
        </sequence>
        <attribute name="id" type="ID" use="required"/>
    </complexType>
</element>
<element name="Length" type="string"/>
<element name="StartingLocation" type="string"/>
<element name="EndingLocation" type="string"/>
<element name="Dam">
    <complexType>
        <sequence>
            <any namespace="http://www.geodesy.org/dam" maxOccurs="unbounded"/>
        </sequence>
    </complexType>
</element>
<element name="Name" type="string"/>


Astfel, vocabularul, care este acum disponibil pentru a descrie un râu este – Lungime, StartingLocation, EndingLocation, Dam, și Numele!

 


Puterea acest model de design este faptul că împuternicește fiecare persoană pentru a descrie în mod independent Yangtze River fără limitats pe vocabularul (de exemplu, etichetele XML), care este utilizat pentru a descrie râul (mai degrabă, vocabularul trebuie aparțin toate http: //www.geodesy.org/river namespace).

Cu acea putere vine potențialele probleme atunci când agregarea datelor disparate. De exemplu, să presupunem că două persoane (în mod independent) care doriți să descrie Dam râului. Fiecare crea propria lor schema care declară un element Dam. Totul e bine. Fiecare persoană poate valida separat datele lor instanță. Cu toate acestea, atunci când un instrument agregator scade Toate datele exemplu, și toate declarațiile de scheme, atunci va fi o problemă – schema va avea două (cel mai probabil diferite) declarațiile de Dam. Asta-i o problemă.

Care este soluția? Iată câteva idei pe care am (Salut alte idei oameni pe aceasta):

  1.     Valida Separat, bine-alcatuire colectiv: fiecare persoană poate valida individual datele lor. În cazul în care datele sunt agregate nu deranjez cu validare (ceea ce este punctul?). Pur și simplu a verifica bine formate. Bănuiesc în 99% din cazuri această abordare este perfect în regulă.
  2.     Wrap dubluri: atunci când există duplicate, cum ar fi elemente Dam duplicat, înveliți fiecare dintre ele într-un element unic. Faceți acest lucru atât în ​​documentul instanță, precum și schema. În mod evident, acest lucru va necesita un instrument mult mai inteligent agregator.

Recomandare
După cum am văzut, acest model de design (eXtreme extensibilitate) Schema XML orientate-ul este util ori de câte ori există o dorință de a se dezvolta un corp de informații, mai ales atunci când doriți să crească un corp de date într-un mod distribuit. Exemplul de mai sus Yangtze River este un exemplu perfect de unde, în timp, pe care doriți să crească un corp de date cu privire la râu. Schemelor XML pentru caracteristici geografice este un bun candidat pentru acest model de design. Schemelor XML pentru colectarea de informații despre o persoană este, de asemenea un candidat bun (de exemplu, dacă doriți să creați o biografie a lui Albert Einstein poate doriți să “crească” aceste date într-un, moda independent distribuit). Există multe, multe alte exemple în care acest model de design este util. Imaginația ta este cu adevărat limita.

Scopul web-ul semantic este de a permite oricine, oriunde, oricând pentru a furniza date cu privire la o resursă. Folosind modelul de proiectare prezentate în această lucrare va aduce datele în aliniament cu viziunea web-ul semantic.

Relația cu RDF?
“Acest lucru suna foarte mult ca sigur o RDF -.? Identificarea o resursă (de exemplu, Yangtze River), furnizarea de date (perechi proprietate / valoare) pentru resursa ce” fals “cu schemele XML ce nu folositi” lucru real “.. . RDF? ”

Observație dumneavoastră este în întregime corectă. În mod ideal, noi, probabil, ar trebui să utilizeze RDF. Cu toate acestea, RDF este o mai bine înțeles de către comunitatea XML, nu oferă același nivel de control care schemele XML oferă tip, și există mai puțin sprijin pentru el din punct de vedere instrumente. Deci, abordarea de mai sus este o soluție temporară. Folosind aceasta abordare va ajuta la a face pasul de a RDF (și web-ul semantic) mai puțin dureros.

Unificarea schemele XML și RDF
Cel mai bun dintre toate lumile posibile ar fi de a face documentele exemplu utilizabil atât prin instrumente Schema XML, precum și instrumente de RDF. Interesant, doi dintre instanță documentele din exemplul fluviul Yangtze, de asemenea, documente perfect fine RDF:

<River id="Yangtze"
       xmlns="http://www.geodesy.org/river">
     <Length>6300 kilometers</Length>
     <StartingLocation>western China's Qinghai-Tibet Plateau</StartingLocation>
     <EndingLocation>East China Sea</EndingLocation>
</River>

as well as this one …

<River id="Yangtze"
       xmlns="http://www.geodesy.org/river">
     <Name>Dri Chu - Female Yak River</Name>
     <Name>Tongtian He, Travelling-Through-the-Heavens River</Name>
     <Name>Jinsha Jiang, River of Golden Sand</Name>
</River>

The other instance document, however, is not good RDF:

<River id="Yangtze"
       xmlns="http://www.geodesy.org/river"
       xmlns:d="http://www.geodesy.org/dam">
     <Dam>
         <d:Name>The Three Gorges Dam</d:Name>
         <d:Width>1.5 miles</d:Width>
         <d:Height>610 feet</d:Height>
         <d:Cost>$30 billion</d:Cost>
     </Dam>
</River>

Motivul este că RDF încearcă să trateze elementul Dam ca o proprietate. Elementul Dam este de fapt o clasă (și denumirea, Latime, Inaltime, și cost sunt proprietăți ale clasei). Soluția este să-și încheie elementul Dam:

<River id="Yangtze"
       xmlns="http://www.geodesy.org/river"
       xmlns:d="http://www.geodesy.org/dam">
     <RiverStructure>
         <Dam>
             <d:Name>The Three Gorges Dam</d:Name>
             <d:Width>1.5 miles</d:Width>
             <d:Height>610 feet</d:Height>
             <d:Cost>$30 billion</d:Cost>
         </Dam>
     </RiverStructure>
</River>


Acum, acest document exemplu este, de asemenea RDF bine!

Având în vedere că lumea se îndreaptă către o Semantic Web este logic foarte bun pentru a da datele cu dublă utilizare – utilizabile atat de instrumente XML Schema, și prin instrumente de RDF. (Un sfat prietenesc)

Problema de agregare menționat mai sus nu este prezent cu RDF
În secțiunea de mai sus asupra agregării am observat o problemă cu agregarea declarațiilor schemei disparate într-o singură schemă, atunci când există mai multe declarații diferite ale aceluiași element (exemplul l-am dat a fost de două persoane declarate în mod independent, un element Dam). Aceasta este o problemă inerentă cu schemele XML.

RDF, cu toate acestea, nu are această limitare. Oricine, oriunde, oricând și la poate defini aceleași proprietăți, și atunci când acestea sunt agregate nu va fi o problemă.

Mulțumiri
Aș dori să confirm cu recunoștință următoarelor persoane pentru intuiții lor excelente, sugestii, și sfaturi:

  •     Dave Case
  •     David Jacobs
  •     Frank Manola

Comments are closed.