RDFa and Many-to-Many Relationships

 

Forward

 

It is rare that meta data from one application will fit neatly into the definitions of another application.  When seeking a “round-trip”, it is fairly easy to fall into an itterative “solution” which can modify or delete troublesome meta data.  This is the case with Personally Identifiable Information, where a single field in one application might have none or several PII Properties <http://purl.org/pii/terms/>.

 

Methods

 

In particular, we would like to be able to mechanically transform RDF/XML in this form:

 

<rdf:Description rdf:nodeID=”X1”>

   ...

  <rdf:type ref:resource=”uriT1” />

  <rdf:type ref:resource=”uriT2” />

  <rdf:type ref:resource=”uriT3” />

</rdf:Description>

...

 

to this

 

<rdf:Description rdf:about=”uriT1”>

   <rdf:type ref:resource=”uri(X1)” dct:isReferencedBy=”nodeID(X1)” />

</rdf:Description>

<rdf:Description rdf:about=”uriT2”>

   <rdf:type ref:resource=”uri(X1)” dct:isReferencedBy=”nodeID(X1)” />

</rdf:Description>

<rdf:Description rdf:about=”uriT3”>

   <rdf:type ref:resource=”uri(X1)” dct:isReferencedBy=”nodeID(X1)” />

</rdf:Description>

 

This column-wise pivot is difficult to do in a data base (e.g. with SQL), but the XSLT at <http://www.rustprivacy.org/meta/lookup.xsl> can be used.  The three “T” uri's in the first represent types of PII as a list of CURIEs.  The nodeID of “X1” comes from the <http://www.rustprivacy.org/meta/names.rdf> file.  The “T” uri's are annotated with a description  from the PII RDF Schema.

 

Two result examples are given here (OpenOffice User Data) and here (Dublin Core Elements).

 

In this way, not only can one group be compared to another, but nodeID's representing elements in different name spaces can be grouped for comparison.  At present, only a limited number of elements (from Modzilla, Thunderbird, etc. Address Books, W3C namespaces and the OpenOffice applications etc.) are available in <names.rdf>.  However there is no reason that Profile data from other sources, like Social Networking sites for example could not be added.  That might, in turn, enable a theoretical basis for comparison in the probability of “re-identification” (taking  personal information from different sources and re-assembling it to make an identification).

 

When nodeID lists from two different name spaces are joined, the lists of types can be used to build ontologies step-wise using <skos:closeMatch> (see: SKOS Reference Example 75 [W3C]).  Of course some fields cannot be matched in this way.  What this is teling you, of course, is that some information will be lost in a “round trip”.  An example of this sort of convolution is here.  This represents a convolution of WinMail and OpenOffice User Data.

 

The “Chinese Menu” analysis syntax (skos:semanticRelation/skos:mappingRelation) is fairly simple.  With two elements in two name spaces (A,B), there are five cases.  Each of these have entailments (see: SKOS Reference) to make your markup look suitably wonkish.  

 

  1. 1.<A> skos:closeMatch <B> ; skos:relatedMatch <http://purl.org/pii/terms/> 

  2. 2.<A> skos:broadMatch <B> ; skos:relatedMatch <http://purl.org/pii/terms/> 

  3. 3.<A> skos:narrowMatch <B> ; skos:relatedMatch <http://purl.org/pii/terms/> 

  4. 4.<A> skos:inScheme <http://purl.org/pii/terms/> 

  5. 5.<B> skos:inScheme <http://purl.org/pii/terms/>