Comments on: RDF 2 Wishlist

By: RDF Steps Carefully Forward « Decentralyze – Programming the Data Cloud

Fri, 15 Apr 2011 00:54:06 +0000

[...] months ago, when Ivan Herman and I began to plan a new RDF Working Group, I posted my RDF 2 Wishlist. Some people complained that the Semantic Web was not ready for anything different; it was still [...]

By: infomisa.net» Blog Archive » Map and Territory in RDF APIs

infomisa.net» Blog Archive » Map and Territory in RDF APIs — Tue, 21 Sep 2010 22:36:25 +0000

[...] formulas. With the RDF next steps workshop coming up and Pat Hayes re-thinking RDF semantics Sandro thinking out loud about RDF2, I'd like us to think about RDF in more traditional terms. The scala programming language [...]

By: Luxcommons » Blog Archive » “les petites cases” sur les linked data

Wed, 10 Feb 2010 09:55:14 +0000

[...] 2.0″ et RDF syntaxes 2.0. Sur le même sujet, je vous conseille ausssi la lecture de ce billet de Dave Beckett, développeur de redland, inventeur de turtle et grand avocat des technologies du Web [...]

By: Kjetil Kjernsmo

Kjetil Kjernsmo — Tue, 03 Nov 2009 11:37:38 +0000

Nice list!

Well, I’d like XML to die, or at least become less relevant to RDF than it is today, but clearly, it is a long way to go.

Also, I consider lists and sequences as a bigger issue than merely editorial, I feel we need to come up with a radically better solution.

Finally, I think RDF has a serious shortcoming with respect to units of numerical literals. Almost all numbers have units, and this is an issue that is orthogonal to the datatype, but today we have no way to do this well.

Expressing uncertainty would also be nice.

By: Olivier Rossel

Olivier Rossel — Mon, 02 Nov 2009 00:09:01 +0000

RDF/XML weakness:
RDF/XML does not provide a way to mix several named graph together in the same XML structure, *while* keeping graphtriple information (i.e graph provenance).

LOD solution:
This can be circunvented in LOD where you rely on SPARQL and HTTP and all that on top of RDF/XML.

LOD!=RDF:
But LOD is just an architecture of RDF data exchange.
Whereas RDF/XML is a standard spec of a serialization format. It must stay agnostic of the surrounding architecture. And try to circunvent its own weaknesses by itself.

To take another example, HTML spec does not rely on HTTP to circumvent its own shortcomings. These are different businesses.

Back to RDF/XML, and conclusion:
IMHO, the lack of semantic for named graph and triple IDs must be adressed at the spec level, not with some “one size fits all” architecture. (basically because you must not tighten all the possible usages of a spec).

PS: i think this triple ID will also permit to solve a lot of issues about provenance. Whereas (current) LOD proposes no good solutions for that.

By: sandhawke

sandhawke — Sat, 31 Oct 2009 12:55:37 +0000

I don’t see any problem with a thousand (or a googol) named graphs, since (1) while it’s best practice, you don’t HAVE to serve a representation of the graph at URI, and (2) the webserver certainly doesn’t have to use a file for each graph. In particular, you can have http://example.com/graph/NNN query the quadstore for graph number NNN and serve up its contents. You say “basically you need a reference on that triple” and yes, absolutely, but that’s what an IRI is. There’s an engineering design tradeoff between identifying triples and identifying sets of triples, but I think identify sets of triples (some of which contain only one triple) is okay.

I’m not sure what to say about rdf:ID, except that I think the community generally considers it harmful, and it probably should be deprecated, both on subjects (use rdf:about instead) and on predicates (avoid rdf:reificiation).

By: Olivier Rossel

Olivier Rossel — Sat, 31 Oct 2009 11:02:38 +0000

…as the creation of ___rdf:Statement___ triples, alongside the original triple…

By: Olivier Rossel

Olivier Rossel — Sat, 31 Oct 2009 11:00:14 +0000

A remark concerning named graph and how to handle them in the RDF/XML world.
COnsidering that a named graph should map to a document is absolutely bad. What if you have to manage a thousand named graphs, each containing a single triple . Then what? A thousand tiny files?
And more importantly, how to manage that a given triple is in several named graphs at once?
Ah ah back to the reification issue, where you want to address the same triple multiple times, without duplicating it.

Basically you need a reference on that triple.
Which is perfectly available in RDF/XML through the rdf:ID attribute on properties.
Unfortunately there is no equivalent in other dialects of RDF.

So please please please consider the idea that RDF describe triples, and their reference (== RDF should have 4 fields per triple).

PS: most implementations of RDF systems store the triple as quads. To be able to adress them unarily.

PPS: i would appreciate clarification concerning the implementation of rdf:ID on properties, in RDF/XML. As far as I know, this (crucial) feature is implemented as the creation of … triples, alongside the original triple. If this assumption is correct, it is absolutely UGLY, completely denies the fact that RDF implementations are already quad stores (i.e would map natively with that rdf:ID stuff). Any clarification?