- markup (52)
- xml (7)
- xslt (21)
- atom (8)
- overlapping markup (2)
- schema (9)
- creole (4)
- xforms (1)
- pipelines (7)
- coding (2)
- dtll (1)
- genealogy (3)
- gtd (1)
- hardware (1)
- legislation (1)
- ontologies (2)
- unicode (1)
- web (24)
- google (3)
- rdf (6)
- rest (3)
- wikis (1)
- work (1)
- xpath (1)
- xquery (1)
- xtech2008 (3)
- life (26)
- children (5)
- equality (6)
- environment (4)
- gadgets (5)
- software (3)
- xlinq (2)
- conferences (7)
- xtech (6)
- blog (7)
- drupal (3)
Re: Web 2.0 project: RDF and uncertainty
Historically, privacy has been a significant concern for genealogy research. Aside from problems arising from ‘who to filter’, there is the more obvious problem (that you allude to) of actually maintaining privacy.
So far as I’m aware, there’s no foolproof way to completely privatize current information about an individual, other than hoping that programs abide by protocols of decency and either implement filtering on their own or abide by the filtering rules established by others (to be fair, it’s more that filtering rules are applied to GEDCOM files before they are submitted, by tagging records as private).
GEDCOM (Or perhaps an extension of it. I’m not entirely clear.) also supports embedded encryption of data (albeit just the textual values) that depends on having the proper key to decrypt some data. I’m not entirely sure that RDF has a similar mechanism other than… say… through some external agreement that the object of some enc:encryptedData property is to be interpreted as decryptable RDF triples that may only be inserted into the data store if it’s able to decrypt it.
It still doesn’t solve issues with potentially making a local triple store public while containing data that violates privacy (again without some sort of implicit agreement implemented in the SPARQL endpoint to prevent certain triples from being returned).