« Data, Models, Metamodels, Cosmologies | Main | SMS URI Scheme Update »

Wednesday, August 05, 2009


Feed You can follow this conversation by subscribing to the comment feed for this post.


I'm a novice at this stuff, but my experience with intellectual property and things meant to be mixable is that provenance and authenticity in any slightly-complicated mixed thing (be it a "store" or whatever) is exceedingly hard. I hesitate to say anything more, really, given how little I know... but maybe "stores" of RDF triples should just be banned? :)


@joe, thanks a lot for your comment. from your perspective, i guess the most troubling issue here is that RDF's world view of "one giant global graph" often implies that there is some entity that has the authority (or at least the opportunity) to give you that graph. so for the government data use case, the centralized approach is that you take whatever the government gives you as a triple store (often it's access to a SPARQL endpoint), and then whatever you get through that one access point is whatever you're supposed to get. to me, this seems to be as intransparent as things can get if there is not a lot of provenance and identity and authenticity and integrity information associated with what you're getting there, and there usually isn't. so i'm looking forward to your efforts to look at "transparency" from a technical angle, because it seems to me there currently is too much use of that term, with too little agreement of what it means, and how it can be implemented in a meaningful way.


Interesting article and good Semantic Web critics that are still valid today (the early 2011). As pointed out, provenance is the most important issue here, which is needed to close the information flow life cycle (push back updates of information resources to their origin information providers). One can view a triples store of a federated information service as a kind of cache or more generally as an intermediary which has to process information resources in both ways:

- from the origin information provider (or at least consumed information provider) to the information consumer of the federated information service
- from the information consumer (which is generally also an information service and act then in its role as information provider) via the federated information service to the origin information provider (or at least intermediary information provider, where the federated information service retrieved the information resource from)

Treating named semantic graph URIs as namespace URIs is not a good thing. I think, generally the relation between a named semantic graph and the triples (statement) it contains should also be loosely coupled. For that matter, if it necessary or useful to reuse a statement also in another named semantic graph, then I should be able to that. Thereby, one possibility is, to directly insert a reference of that statement, the statement identifier, in the name semantic graph. Another option is, to copy the triple, assign it with a new statement identifier and generate a description which has as subject the statement identifier and relates the new statement identifier to the statement identifier of the triple, where the information comes from.
This and further thoughts are also manifestated in a comment I recently sent to the comments mailing list of the new formed RDF WG, see http://lists.w3.org/Archives/Public/public-rdf-comment/2011Jan/0001.html).

The comments to this entry are closed.