Re: Metadata about single triples

Hi Carsten,

I agree with the comments below.  I think what Bob is suggesting is that you include a non-ontology Core (DCMI for example).

Three critical classes are Language, Jurisdiction and (not included in DCMI) Currency (or portable value).  That would be ISO 639-2, ISO 3166 and ISO 4217.  These are easy enough to keep, in total, on a thumb drive (I am sure they are made in "UN Blue") to be used off line, or put on an inexpensive eBook reader.  I've thought for a long time that data needs a laissez-passer rather than a Copyright, which is effectively a Passport.  If you are ambitious, all three ISO Standards have "User Defined" code values, which could be scrambled (to another unambiguous state) rather than encrypted, or MIME encoded to fool a casual "over the shoulder" observer.

Language: ISO 639-2 :http://www.rustprivacy.org/2012/urn-lang/
Jurisdiction (ISO 3166) and Currency (ISO 4217) : http://www.rustprivacy.org/2012/cctld/

These data bases are not exactly what you would require, but very close.  They are licensed cc-by-sa, but I'd have no trouble providing a UN Refugee version Copyright if that's what it took to invoke a workable laissez-passer [1,2].


Regards,
Gannon (J.) Dick

[1] I am a huge admirer of Raoul Wallenberg, and

[2] http://www.w3.org/egov/IG/slides/2012-02-21.pdf   Slide 33 "Bureaucracy is Pervasive"  Truer words were never spoken.






________________________________
 From: Bob Ferris <zazi@smiy.org>
To: public-lod@w3.org 
Sent: Wednesday, February 22, 2012 5:21 AM
Subject: Re: Metadata about single triples
 


Hi Carsten,

On 2/22/2012 12:02 PM, CarstenKeßler wrote:
> Dear LODers,
> 
> we are currently working on a project for the United Nations Office
> for the Coordination of Humanitarian Affairs (OCHA) in Geneva to
> develop a Humanitarian Exchange Language (HXL). Some information about
> the project is available at https://sites.google.com/site/hxlproject/.
> 
> One of the core components of HXL will be an RDF vocabulary to
> annotate the data that are exchanged between humanitarian
> organizations. The current draft is available at
> http://hxl.humanitarianresponse.info. It is far from complete, but I
> think it already shows where we want to go with this. Any feedback on
> the vocabulary draft is very welcome, of course.

At a first glance, your ontology looks very interesting and well designed.

> 
> The aspect we are currently working on is a metadata section that will
> include classes and properties to state who has reported a certain
> piece of information, when it was reported, whether it was approved
> (and at which level), and so forth. The current idea is to create
> named graphs that can be described by these metadata elements. I'd
> like to hear your comments on this approach, since this will lead to a
> situation where we can have the same triple in several named graphs
> For example, graph A with all data reported on Januar 20, 2012 by an
> OCHA information officer in Suda, graph B with all data approved by
> the OCHA regional office on January 21, and graph C with all data
> approved by OCHA in Geneva on January 22. The rationale is  to be able
> to query based on these metadata elements via SPARQL, e.g., "give me
> all figure about refugess in Sudan from January 2012 approved by OCHA
> Geneva". Note that the regional office may only approve some of the
> triples originally reported, and OCHA Geneva may only approve a subset
> of those approved by the regional office. So basically we need to be
> able to attach those metadata elements to every single triple.
> 
> We will probably run into a situation where we can have the same
> triple in 10–20 graphs at the same time. Likewise, we will have a
> pretty large number of named graphs in our store, and I'd like to know
> whether you think this approach is problematic (e.g. in terms of query
> performance), and whether you see an alternative approach?

I investigated some thoughts on this topic as well in the past. This is also a topic of the current RDFWG Graphs TF (See [1]).
I think, you exactly pointed out the problems with duplicated triples and single triple named graphs. So there might be the (rather old) need for statement identifiers, i.e., a URI (or maybe also a bnode) for identifying a  single triple and to be able to describe external context information. You can find my proposal at the RDFWG comments mailing list, see [2].

Cheers,


Bo


[1] http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs
[2] http://lists.w3.org/Archives/Public/public-rdf-comments/2011Jan/0001.html