Dear colleagues,
back from ESWC 2011, here is a brief report of what happened. Almost all the conference and the annexed summer school was focused on the success of Linked Open Data (aka the "web of data"): how much simple is to publish LOD, how many dozens of billions of triples are in LOD, LOD has finally "killed" ontologies, US and UK Governments' interests in LOD, etc. etc. To me, this confirms that we should move on this direction trying to be compatible with the LOD approach.
Introducing my poster, the first issue I faced and clarified was that the introduction of our "structured" identifiers does not violate the "URI opaqueness principle" (a longstanding issue finally solved:). In fact, XRIs are converted into URIs, that the legacy software can still see as opaque. Nevertheless these URIs can be still interpreted as identifiers for subjects, predicates and objects of a given graph (the feature we want to port from XDI to RDF), by using the traditional RDF reification dictionary, see below for details on how to.
I had the chance to speak with Prof. Chris Bizer, Free University of Berlin, inventor of DBPedia and one of the founder of the LOD project. He admitted that our proposed approach is compatible with the existing LOD infrastructure ("it doesn't break"), but he added that at the present time they do not have yet figured out meaningful use cases requiring to address single elements (nodes and links) inside graphs and statements, as we do in XDI. I proposed him few possible use cases that our approach could natively solve (link contracts, versioning, avoiding misuse of owl:sameAs), etc.
Then I discussed with Dr. Denny Vrandecic, Karlsruhe Institute of Technology (KIT), one of the founder of the semantic media wiki project; he suggested that the benefits presented in my paper could have been achieve through a "wise" usage of reification, without introducing any "structure" inside identifiers. We then elaborated a bit on this. Actually this is true, but if Danny's approach was used, then we would need
0- a name for the graph (G)
1- a name for each triple in the graph (T)
2- a statement saying that a given triple T is part of a graph G
3- a name for subject (S), predicate (P) and object (O) of each triple T
4- three statements saying that S, P and O are subject, predicate and object of the triple T
This is computationally expansive when multipled by several billions of triples in LOD!
Another guy from KIT suggested that many RDF triple stores allow to automatically assign numeric identifiers to triples, subjects, predicates and objects (_:triple123, _:subject456, _:predicate789, _:object0123, etc.), without the need of explicitly stating (2) and (4). However, these numeric identifiers are internal ("local"), and in general not "understandable" by the rest of the world; on the contrary the open nature of LOD should drive toward facilities for "global" access (disambiguating sameness, introducing link contracts, etc.) and our structured identifiers could fit this goal better than numeric identifiers.
Regarding the demo, it was working also with cross references (great Mike!); however, people unfamiliar with XDI perceived our usage of symbols (instead of nouns) as a bit too complex to learn.
Take home message: so my final impression was that our proposed XRI<->URI compatibility mechanism now works fine and seems to have been understood properly, but we still need to spend time on better presenting our use cases, if we want a strong point for the adoption of XRIs and structured identifiers by the semantic community (in particular by the LOD community). Any volunteer for this? I'm offering a cohautorship for the next pubblication... :)
Best Regards,
Giovanni
----------------------------------------------------------------
Invito da parte dell'Ateneo:
Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del
tuo aiuto. Dona il 5 x mille all'Universita' di Roma Tor Vergata
codice fiscale: 80213750583
http://5x1000.uniroma2.it---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php