Sunteți pe pagina 1din 29

despre afirmaii contextuale

1
Ce sunt afirmaiile contextuale?

Afirmaii contextuale = afirmaii pentru care prezumia de adevr


e limitat la un context (la anumite condiii)

Exemple (cuvintele colorate sugereaz un context):


Afirmaii subiective (asociate unei "surse de cunotine"):
George believes that Peter is the brother of Andrew.
The source of the statement "James Cameron directed Terminator" is
IMDB.
- Afirmaii constrnse de spaiu sau timp:
Mary works for the ABC company, in Cluj.
Mary will work for the ABC company (timpul viitor, sugerat
gramatical).
- Afirmaii cu evaluri:
The Sun orbits the Earth is a false statement.
Earth orbits the Sun with 30 km/s. 2
Avertisment
Nu confundai contextul cu afirmaii despre obiecte sau despre
proprieti
http://expl.at#Mary http://expl.at#CompanyABC
http://expl.at#worksAt
http://expl.at#location

http://expl.at#Cluj
Acest exemplu corespunde afirmaiei:
Mary works for the ABC company, which is located in Cluj.
(aici compania e n Cluj, nu e clar dac i Mary!)

http://expl.at#Mary http://expl.at#CompanyABC
http://expl.at#worksAt

http://expl.at#location

http://expl.at#Cluj

Acest exemplu corespunde afirmaiilor:


Mary works at Company ABC. Everyone who works, works in Cluj.
3
(proprietile unei proprieti se aplic peste tot unde folosim acea proprietate!)
Soluii de reprezentare a afirmaiilor contextuale

Soluia1. Relaii de aritate mare (cu mai muli participani), modelate cu ajutorul
unui nod anonim ce conecteaz laolalt toi participanii (aici persoana, angajatorul,
locaia... ar putea fi i altele):

http://expl.at#Mary
http://expl.at#worker

_:workRelation
http://expl.at#location
http://expl.at#employer
http://expl.at#Cluj

http://expl.at#CompanyABC

Turtle:
@prefix : <http://expl.at#>.
[:worker :Mary; :employer :CompanyABC; :location :Cluj].
Soluii de reprezentare a afirmaiilor contextuale

Soluia2. Reificarea ("afirmaii despre afirmaii"): seamn cu relaiile de aritate mare,


dar folosete nite termeni standardizai pentru a descrie afirmaia despre care se fac
afirmaii.

rdf:Statement

rdf:type http://expl.at#Cluj
http://expl.at#hasLocation
_:x

rdf:subject
rdf:object

http://expl.at#Mary rdf:predicate
http://expl.at#CompanyABC

http://expl.at#worksAt

Turtle:
fix : <http://expl.at#>.
fix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
Statement; rdf:subject :Mary; rdf:predicate :worksAt; rdf:object :CompanyABC; :hasLocatio
Soluii de reprezentare a afirmaiilor contextuale

Soluia3. Grafurile identificate permit gruparea de afirmaii ntr-un graf ce devine


apoi termen n alte afirmaii (avantaj: mai concis dect reificarea sau relaiile de
aritate nalt)

http://expl.at#City http://expl.at#Romania

Se pot aduga apoi "metadate"


rdf:type http://expl.at#locatedIn
(afirmaii despre graf)

http://expl.at#Cluj

http://expl.at#worksAt
http://expl.at#Mary http://expl.at#CompanyABC

Se pot aduga apoi i alte fapte


(afirmaii) care au loc n Cluj

TriG:
prefix : <http://expl.at#>.
uj {:Mary :worksAt :CompanyABC}
Cluj a :City; :locatedIn :Romania} 6
Soluii de reprezentare a afirmaiilor contextuale

Soluia3. Eventual, graful identificat poate primi un identificator lipsit de semnificaie,


care s fie apoi ataat mai multor contexte separate de coninutul grafului:

http://expl.at#City http://expl.at#Romania

rdf:type http://expl.at#locatedIn

http://expl.at#Cluj http://expl.at#Past
TriG:
refix : <http://expl.at#>. http://expl.at#place
aph1 {:Mary :worksAt :CompanyABC} http://expl.at#time http://expl.at#Robert
raph1 :place :Cluj; :time :Past; :source :Robert.
j a :City; :locatedIn :Romania} http://expl.at#source
http://expl.at#graph1

http://expl.at#worksAt
http://expl.at#Mary http://expl.at#CompanyABC

7
Exemplu cu afirmaii subiective
Afirmaii subiective: cnd dorim ca anumite afirmaii s fie caracterizate ca
aparinnd unei anumite surse/persoane subiective i dorim s permitem clienilor s
filtreze rezultatele interogrilor dup surs (de ex. n funcie de credibilitatea sursei):
Mary believes that Anna is the mother of Andrew and Peter, but does not believe that
Peter is the father of George.

http://expl.at#graph1

http://expl.at#isMotherOf
http://expl.at#Anna http://expl.at#Peter
http://expl.at#graph2

http://expl.at#isMotherOf

http://expl.at#Andrew http://expl.at#isFatherOf

http://expl.at#believes http://expl.at#doesNotBelieve
http://expl.at#George
http://expl.at#Mary 8
despre termenii folosii n
afirmaii

9
Termenii afirmaiilor pot fi
URI (majoritatea) i, n funcie de provenien, pot fi de urmtoarele tipuri:
Proprii = creai de creatorul bazei de cunotine
pe baza propriei adrese de domeniu, un termen e creat ad-hoc la prima apariie ntr-o afirmaie
Standardizai = creai de W3C, se recomand adoptarea lor
pentru a permite oricui s ne interogheze cunotinele
pentru a permite deducii automate fr intervenie uman
Controlai = creai de diverse organizaii (Facebook, Microsoft etc.), se ncurajeaz adoptarea lor
pentru a beneficia de diverse funcionaliti (de ex., importarea unui site n lista de preferine Facebook cu
butonul Like)
Generai = apar atunci generm automat grafuri RDF din surse tradiionale
de ex., generarea de grafuri din tabele MySQL va produce URI din numele coloanelor concatenate cu numele
tabelelor i cu o adres de domeniu
VALORI SIMPLE
Pot fi numere, booleene, date calendaristice etc.
se folosesc tipurile predefinite din XML Schema, plus tipul suplimentar rdf:XMLLiteral pentru cod XML oarecare
(dar bine format conform XML)
Pot apare doar pe poziie de obiect
deci NU se pot face afirmaii despre valori simple
NODURI ANONIME
Sunt lociitori (temporari sau permaneni) pentru un URI
Pot fi la nevoie substituii cu un URI, dar de obicei nu prezint interes identitatea lor, doar poziia n graf
Pot apare doar pe poziie de subiect sau obiect
Proprietile NU pot fi anonime
De ce termenii afirmaiilor se
bazeaz pe URI?
1. URI au un caracter universal
pot identifica orice lucru, adresabil sau neadresabil
sunt mai generali dect alte sisteme de identificare (de ex. CNP se aplic doar
la oameni i doar n Romnia, ISBN doar la cri etc.)
2. URI indic proveniena ntr-un mod controlabil
ncep cu o adres de domeniu unic n Internet, deinut de cineva anume
3. URI sunt structurai i flexibili
proprietarul adresei de domeniu poate defini un numr infinit de termeni,
folosind extensiile permise de un URI (unul sau mai multe slash-uri, maxim un
hash):
http://buchmann.ro/Maria
Hash doar o dat, la ultima particul!
http://buchmann.ro#Maria
http://buchmann.ro/persoane/Maria
http://buchmann.ro/relatii/frate
http://buchmann.ro/vocabular1/relatii#frate
atenie la prefixare n ultimul exemplu! doar ultima particul rmne dup
prefix:
@prefix : <http://buchmann.ro/vocabular1/relatii#>. va permite s folosim
termenul :frate
...n schimb...
De ce termenii afirmaiilor se
bazeaz pe URI?
4. URI asigur distincia n cazul conflictelor de termeni
termeni similari se pot diferenia dup prefix/provenien:
http://expl.at#Maria Dou persoane Maria au primit identificatori similari de la
http://other.at#Maria organizaii diferite, din coinciden, dar se pot diferenia
dup provenien!

http://buchmann.ro#sugar
Conceptele "zahr" i "sugar" au primit identificatori similari
http://expl.at#sugar derivai din limbi diferite, dar se pot diferenia dup
provenien!

http://buchmann.ro/companii#Volkswagen
Dei au aceeai provenien, compania i modelul
http://buchmann.ro/modele#Volkswagen
Volkswagen
se pot diferenia datorit structurii URI

http://buchmann.ro/marimiFizice/masa
Omonimul "masa" se poate diferenia datorit
http://buchmann.ro/mobilier/masa structurii URI

http://buchmann.ro#PopMaria1
Aici presupunem c avem dou persoane. Sub nici o form
http://buchmann.ro#PopMaria2
nu trebuie folosit acelai URI pentru resurse diferite!
Dac proveniena e aceeai i dorim s pstrm structura
URI,
trebuie s form diferenierea n ultima particul a
termenului
De ce termenii afirmaiilor se
bazeaz pe URI?
5. La nevoie URI pot fi folosii ca URL-uri: dei exist URI care ncep cu ftp:/, mailto:, urn: se
recomand cei care ncep cu http://, din motivele urmtoare:
Pentru resursele adresabile, devine convenabil ca URL s fie i URI (identificatorul va
permite i obinerea fiierului respectiv prin HTTP)
:MichaelJackson :arePagina <http://michaeljackson.com>.
Acest termen e identificator de persoan (neadresabil) Acest termen e simultan identificator (de site) i adr
site!
Pentru resursele neadresabile, se pot implementa mecanisme HTTP pe server care s
trateze situaia n care un URI este folosit ca un URL (de ex. un URI tastat n browser).
Exemplu de scenariu:

Presupunem c folosesc termenul http://buchmann.ro#MichaelJackson (ca identificator al


persoanei Michael Jackson)

Ce doresc s se ntmple dac cineva tasteaz acest termen n browser? Posibiliti:


1. Nu e OBLIGATORIU s se ntmple ceva. Serverul poate returna o eroare
2. Se recomand implementarea unui mecanism de derefereniere URI = cnd serverul
accept un URI i returneaz "ceva util":
2a. Serverul poate prentmpina situaia printr-o redirectare HTTP spre site-ul oficial
Michael Jackson, sau spre pagina sa de Wikipedia
2b. Serverul poate prentmpina situaia rspunznd cu un fiier RDF ce conine toate
afirmaiile disponibile pe server despre acel termen
2c. Serverul poate prentmpina situaia rspunznd cu o pagin HTML care ofer unele
De ce termenii afirmaiilor se
bazeaz pe URI?
6. La nevoie, o aceeai resurs poate primi mai multe URI (de obicei de provenien
diferit): Exist o probabilitate mare ca organizaii diferite s foloseasc termeni diferii cu
aceeai semnificaie, ori ca persoane diferite s aib identificatori diferii n organizaii diferite!

http://anaf.ro#PopMaria O persoan poate primi identificatori diferii n baze de


cunotine diferite,
http://univie.ac.at#PopMaria
aparinnd unor organizaii diferite!

http://buchmann.ro/vocabular#frate
Conceptul de frate poate s apar cu aceeai semnificaie
http://other.at/voc#brother n vocabulare diferite, de provenien diferit!

Important de reinut!
O resurs poate avea mai muli URI (de obicei de provenien diferit), dar un
acelai URI nu poate identifica mai multe resurse! (adresele de domeniu previn n bun
msur acest risc)!
Nu exist obligativitatea n adoptarea termenilor, nici mcar a celor standardizai!
(fiecare poate face afirmaii cu proprii termeni i propria adres de domeniu, ignornd
existena altor baze de cunotine sau a termenilor creai deja de altcineva)

7. URI au un caracter internaional


se mai numesc i IRI, subliniind astfel faptul c pot fi scrii cu orice caractere
Analogia URI-URL
Asemnri URI-URL:
Nu pot exista dou site-uri cu acelai URL
n schimb un site poate avea mai multe URL-uri (eventual
redirectate ntre ele)
URL-ul e format din:
O adres de domeniu controlat de proprietarul su
Informaii adiionale ataate sub form de foldere, fiiere, ancore n scopul accesrii a diverse
elemente dintr-un site (fiiere, paragrafe, servicii Web etc.), de exemplu:
http://www.mysite.com/folder/file.doc
http://www.mysite.com/DaVinciCode#Chapter1
Deosebiri URI-URL:
Scopul URI este identificarea, nu accesarea
URI trebuie vzui ca "identificatori" (similar cu CNP, ISBN etc.), nu ca "adrese"
Totui la nevoie, un URI poate fi folosit ca URL dac pe server s-a programat un mecanism de
derefereniere URI

Un URI identific orice, un URL identific o resurs adresabil


(fiier, paragraf etc.)
Un URI este un "cuvnt" (termen) al unei afirmaii RDF
Teoretic pentru orice cuvnt din limbajul natural se poate inventa un URI 15
De ce s nu folosim URL-uri
existente pe post de URI?
Teoretic Web-ul ofer numeroase surse de identificatori lipsii
de ambiguitate:
Wikipedia aloc o pagin (deci un URL distinct) pentru numeroase
concepte i instane;
Reelele sociale (Facebook, LinkedIn) aloc o pagin distinct fiecrei
persoane, organizaii, eveniment etc.;
Totui se recomand s se evite reutilizarea de URL-uri pe post
de URI. Motiv: o persoan i pagina sa Web NU sunt acelai
lucru.
Persoana e neadresabil i are anumite proprieti (nume, data naterii
etc.);
Pagina Web e adresabil i are cu totul alte proprieti (autor, data
publicrii etc.)
Dou resurse distincte nu trebuie identificator! Dou resurse
echivalente trebuie s aib exact aceleai proprieti!

Concluzie: vom utiliza URL-uri pe post de URI doar cnd


16
facem afirmaii chiar despre resurse adresabile (despre
Ce se ntmpl dac exista deja URI
pentru lucrurile care apar n afirmaii?

1. Dac aflm la timp, e bine s-i reutilizm pentru a permite


i altora s interogheze afirmaiile noastre
Nu e o eroare s folosim doar URI proprii, dar atunci doar noi (creatorul
acelor URI) poate crea interogri i aplicaii client (care s-i interogheze)
Utilizarea de URI standardizai sau controlai vor aduce o serie de beneificii
2. Dac aflm trziu,i nu mai putem modifica URI (deoarece ar
afecta aplicaii aflate deja n funciune), putem include n baza
de cunotine o ontologie de aliniere:
De obicei e vorba de un "dicionar de echivalene" = afirmaii care declar
ntr-un mod standard echivalena mai multor URI care s-au creat pentru
acelai lucru/resurs
Un astfel de dicionar va permite interogrilor s acumuleze cunotine din
mai multe surse, despre acelai lucru
3. Posibile surse de URI existeni:
Terminologii standardizate (RDF/S, OWL)
Terminologii controlate (FOAF, Facebook OpenGraph, DBPedia)
17
Baze de cunotine ale unor organizaii partenere cu care dorim s
Granularitatea URI
Ct de apropiat trebuie s fie un URI de cuvintele din limbajul
natural?
Ct de detaliat?

Exemplu:
Anna has the age of 20.

A. C.
Versiuni intuitive: Versiunea http://expl.at#Anna
preferat:
http://expl.at#Anna http://expl.at#has

http://expl.at#hasAge
http://expl.at#theAgeOf20

20
B.
http://expl.at#Anna http://expl.at#has

http://expl.at#Age
http://expl.at#value
20
18
Probleme cu varianta A.
Trebuie s ne gndim la posibilii clieni, la posibilele interogri ce vor veni de la acetia.

De exemplu, sunt destul de probabile urmtoarele scenarii:


c numrul 20 va trebui obinut separat (de exemplu pentru a calcula o medie ntre
mai multe vrste)
c vom dori s definim semnificaia proprietii "hasAge", fcnd afirmaii despre
aceasta independent de valoarea 20

http://expl.at#Anna http://expl.at#has

http://expl.at#theAgeOf20

n aceast variant, niciunul din aceste scenarii nu e posibil fr un efort suplimentar


din partea clientului (ar fi necesar conversia URI n string, apoi extragerea numrului
20 prin procesare de stringuri .a.m.d.)

19
Probleme cu varianta B.
Presupunem c n viitor vor trebui declarate mai multe vrste

Prin reutilizarea termenului Age, afirmaiile vor fuziona ntr-un mod care nu mai
permite calculatorului s discearn care vrst este a cui:

40
http://expl.at#Anna http://expl.at#value

http://expl.at#has
http://expl.at#Age

http://expl.at#has
http://expl.at#value 20
http://expl.at#John

n conceperea bazelor de cunotine trebuie s ne punem i ntrebarea: care


noduri din afirmaii vor trebui reutilizate?
20
Consecin: Varianta C. e
recomandat
Acum se poate reutiliza proprietatea vrst fr a crea ambiguitate
Acum se pot interoga valorile vrstelor separat de restul informaiei
Acum se poate descrie proprietate vrst separat de valoarea sa

http://expl.at#John 40
http://expl.at#hasAge
http://expl.at#measuredIn
http://expl.at#Anna http://expl.at#years

http://expl.at#hasAge http://expl.at#measuredIn

20
Observaie: afirmaia despre proprietatea hasAge, dei n imagine apare de dou ori, n sintaxele concrete se va scrie
o singur dat (o afirmaie se scrie o singur dat ntr-un graf):

@prefix : <http://expl.at#>.
:John :hasAge 40. :Anna :hasAge 20. :hasAge :measuredIn :years.

Cu alte cuvinte:
Descrierea unei proprieti e independent de afirmaiile n care se folosete acea proprietate (n sensul c
utilizarea proprietii trebuie s in cont de semnificaia sa, nu invers!)
Descrierea unei proprieti e separat de afirmaiile n care se folosete acea proprietate (n sensul c o proprietate
e descris o dat, apoi semnificaia sa e valabil peste tot unde se reutilizeaz acea proprietate!)
Deci nu se va face distincie ntre proprietatea hasAge a lui John i cea a lui Anna. Dac dorim distincie, nseamn
c dorim s avem proprieti diferite, cu semnificaii diferite, i prin urmare trebuie s le dm URI diferii! 21
Granularitatea termenilor
Nu trebuie s exagerm cu granularitatea. De exemplu...

Anna was born on 12.12.2000.

...ar putea lua forma: http://expl.at#Anna

http://expl.at#hasBirthyear http://expl.at#hasBirthday

http://expl.at#hasBirthmonth
2000 12 12

Totui, deoarece majoritatea mediilor de programare pot s descompun uor o dat


calendaristic i exist deja un tip XML Schema pentru acest gen de valori, nu e nevoie s o
descompunem att de mult.

Putem pstra o singur valoare simpl, deci o singur proprietate:

:Anna :birthDate "2000-12-12"^^xsd:date.


22
Granularitatea termenilor
Alteori ns are sens descompunerea, pentru a permite interogarea separat a
mai multor cmpuri dintr-o structur de date complex. Exemplu:

Anna lives in Wien, Brunnerstr. 72, Ap. 200.

http://expl.at#Anna
http://expl.at#hasResidenceAp
http://expl.at#hasResidenceCity

http://expl.at#hasResidenceNr
http://expl.at#Wien http://expl.at#hasResidenceStreet 200

20
http://expl.at#Brunner

Exist i alte tehnici, bazate pe noduri anonime (vom reveni ulterior)

23
Granularitatea termenilor
Spre deosebire de slide-ul precedent, aici avem o singur
proprietate:
se va face efort mai puin la descrierea semnificaiei
proprietilor (e una singur de descris, :livesAt)
n schimb la interogare nu mai putem distinge ntre ora, strad
etc. dect dac adugm nite afirmaii suplimentare (despre
Wien, Brunner etc.)
http://expl.at#Anna
http://expl.at#livesAt
http://expl.at#livesAt

http://expl.at#livesAt
http://expl.at#Wien http://expl.at#livesAt 200

20
http://expl.at#Brunner

24
Recomandri privind URI
Se recomand ca URI de proprieti...
s fie uor de difereniat fa de non-proprieti
s sugereze cititorului uman direcia n care are loc relaia

<http://expl.at#Anna> <http://expl.at#Mother>
<http://expl.at#Mary>.

Dei e corect pentru calculator, acest exemplu ridic probleme unui cititor
uman:
Este Anna mama lui Mary sau invers?
Termenul :Mother reprezint conceptul de mam (mulimea tuturor
mamelor, clasa mamelor) sau relaia de a fi mama cuiva?
Pentru evitarea confuziilor se recomand ca URI de proprieti s se extind
n mod sugestiv:
<http://expl.at#hasMother>
25
sau
Recomandri privind URI
Se recomand ca fiecare URI s aib ataat un string (nume,
etichet, titlu) ce va fi folosit la afiri n interfaa cu
utilizatorul:
Resurse cu Stringuri
identitate (denumiri,
(persoane, locuri) etichete)
Persoane diferite cu acelai nume

:Mary1 :hasFullName "Mary Smith".


:Mary2 :hasFullName "Mary Smith".
:Austria :hasName "Austria"@en, "Autriche"@fr.

Nume diferite n limbi diferite, asociate aceluiai lucru (ara


Austria)

26
Recomandri privind URI
URI se supun unor principii mai rigide:
Trebuie s aib forma impus de URI (cu prefix i extensiile permise, discutate deja, dar i
unele limitri privind caracterele permise)
Asigur identitatea global a lucrurilor (nu trebuie s existe dou lucruri distincte cu acelai
URI)
Nu sunt legai de o limb anume, sunt doar nite coduri de identificare (se recomand totui
s poat fi citii i de utilizatori umani)
Pot exista mai muli URI pentru acelai lucru (cu posibilitatea de echivalare n astfel de
situaii)
Apar adesea ca subiecte n afirmaii RDF
Nu trebuie s fie vizibili n interfaa cu utilizatorul final (acesta nu trebuie s i dea seama
dac aplicaia sa folosete n spate RDF sau MySQL sau alt tip de back-end)
Sunt nrudite cu URL-urile i de aici deriv unele consecin (posibilitatea de derefereniere
URI, posibilitatea de a folosi URL-uri ca URI pentru resurse adresabile)
Stringurile n schimb se supun unor principii mai relaxate, fiind considerate "nume" sau
"etichete":
Pot conine orice caractere, fr s aib o structur impus (nu e obligatoriu s semene cu
URI crora le sunt ataate)
Nu asigur identitate global (de exemplu pot exista mai multe persoane cu acelai nume)
Pot fi legate de o limb anume, caz n care li se ataeaz coduri de limb (acelai lucru
poate avea denumiri diferite n limbi diferite)
Pot exista mai multe nume pentru acelai lucru, dar nu se pot stabili echivalri ntre nume
Nu pot servi ca subiecte n afirmaii RDF (nu se pot face afirmaii despre valori simple!)27
Recomandri privind URI
Se recomand ca un URI s aib ataat mcar un URL al
unei pagini Web ce poate oferi detalii suplimentare despre
acea resurs
Aa cum stringurile devin importante la afiarea rezultatelor interogrilor n
interfaa utilizatorului final, astfel de URL-uri pot sta la baza afirii de
hyperlinkuri
Se asigur astfel o distincie clar ntre resursele adresabile i cele neadresabile,
ntre URL i URI, pstrnd totodat relaii interogabile ntre acestea
Scenariu:
Andrew are o pagin personal cu propriul domeniu (http://www.andrew.at)
Andrew dorete s publice o descriere RDF cu afirmaii despre el nsui
Pentru a asigura distincia ntre site i persoan, Andrew va evita s reutilizeze
URL-ul existent, va crea un URI puin diferit i va crea o relaie interogabil ntre
cele dou:
<http://www.andrew.at#Andrew> <http://www.andrew.at#isRepresentedBy>
<http://www.andrew.at> .
(identificatorul persoanei Andrew) (relaia URI-URL) (pagina Web a lui Andrew)
i invers, codul HTML al paginii lui Andrew va trebui s ncorporeze aceast
28
afirmaie
Recomandri privind URI
Se recomand ca URI s fie suficient de detaliai nct s se
poat interoga ct mai uor informaii relevante:
:Mary :eCopilDinPrimaCasatorieALui :JohnSmithDinClujNapoca.
Avem aici un exemplu corect (bine format) dar dificil de interogat.
Variante recomandate (am omis prefixele):
A. Variant bun, permite interogri rafinate prin B. Variant mai puin bun (dar mai bun
includerea unor noduri anonime* care nu erau dect cea iniial):
menionate, ofer o distincie i o relaie clar ntre
dar sunt implicite (RDF nu are rolul de a JohnSmith i ora
"traduce" propoziii permite obinerea copiilor (pe baza
din limbaj natural,_:x
ci de a le reflecta relaiei :copilulLui), cnd nu conteaz din ce
semnificaia!) :primaSotie _:y cstorie sunt
:copilulLui
:aDouaSotie
:Mary :copilulLui
:JohnSmith :Mary :JohnSmith
:copilulLui
:locuiesteIn :dinPrimaCasatorie
:locuiesteIn
*exist i alte moduri de a
exprima :ClujNapoca :ClujNapoca
ordinea dintre soii, vom reveni!

S-ar putea să vă placă și