Hi, Robert Sanderson <[log in to unmask]> wrote: > c) I've never used a Topic Maps application. (and see (a)) How do you know? > There /are/ challenges with RDF [...] > But for the vast majority of cases, the problems are solved (JSON-LD) or no > one cares any more (httpRange14). What are you trying to say here? That httpRange14 somehow solves some issue, and we no longer need to worry about it? >> Having said that, there's tuples of many kinds, it's only that the >> triplet is the most used under the W3C banner. Many are using to a >> more expressive quad, a few crazies , for example, even though that > > ad hominem? really? Your argument ceased to be valid right about here. I think you're a touch sensitive, mate. "Crazies" as in, few and knowledgeable (most RDF users these days don't know what tuples are, and how they fit into the representation of data) but not mainstream. I'm one of those crazies. It was meant in jest. >> may or may not be a better way of dealing with it. In the end, it all >> comes down to some variation over frames theory (or bundles); a >> serialisation of key/value pairs with some ontological denotation for >> what the semantics of that might be. > > Except that RDF follows the web architecture through the use of URIs for > everything. That is not to be under-estimated in terms of scalability and > long term usage. So does Topic Maps. Not sure I get your point? This is just semantics of the key dominator in tuple serialisation, there's nothing revolutionary about that, it's just an ontological commitment used by systems. URIs don't give you some magic advantage; they're still a string of characters as far as representation is concerned, and I dare say, this points out the flaw in httpRange14 right there; in order to know representation you need to resolve the identifier, ie. there's a movable dynamic part to what in most cases needs to be static. Not saying I have the answer, mind you, but there are some fundamental problems with knowledge representation in RDF that a lot of people don't "care about" which I do feel people of a library bent should care about. >> But wait, there's more! [big snip] > > Your point? You don't like an ontology? #DDTT My point was the very first words in the following paragraph; >> Complexity. And of course I like ontologies. I've bandied them around these parts for the last 10 years or so, and I'm very happy with RDA/FRBR directions of late, taking at least RDF/Linked Data seriously. I'm thus not convinced you understood what I wrote, and if nothing else, my bad. I'll try again. > That's no more a problem of RDF than any other system. Yes, it is. RDF is promoted as a solution to a big problem of findable and shareable meta data, however until you understand and use the full RDF cake, you're scratching the surface and doing things sloppy (and I'd argue, badly). The whole idea of strict ontologies is rigor, consistency and better means of normalising the meta data so we all can use it to represent the same things we're talking about. But the question to every piece of meta data is *authority*, which is the part of RDF that sucks. Currently it's all balanced on WikiPedia and dbPedia, which isn't a bad thing all in itself, but neither of those two are static nor authoritative in the same way, say, a global library organisation might be. With RDF, people are slowly being trained to accept all manners of crap meta data, and we as librarians should not be so eager to accept that. We can say what we like about the current library tools and models (and, of course, we do; they're not perfect), but there's a whole missing chunk of what makes RDF 'work' that is, well, sub-par for *knowledge representation*. And that's our game, no? The shorter version; the RDF cake with it myriad of layers and standards are too complex for most people to get right, so Linked Data comes along and try to be simpler by making the long goal harder to achieve. I'm not, however, *against* RDF. But I am for pointing out that RDF is neither easy to work with, nor ideal for any long-term goals we might have in knowledge representation. RDF could have been made a lot better which has better solutions upstream, but most of this RDF talk is stuck in 1.0 territory, suffering the sins of former versions. >> And then there's that tedious distinction between a web resource and >> something that represents the thing "in reality" that RDF skipped (and >> hacked a 304 "solution" to). It's all a bit messy. > > That RDF skipped? No, *RDF* didn't skip it nor did RDF propose the *303* > solution. You can use URIs to identify anything. I think my point was that since representation is so important to any goal you have for RDF (and the rest of the stack) it was a mistake to not get it right *first*. OWL has better means of dealing with it, but then, complexity, yadda, yadda. > http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14 > And it's not messy, it's very clean. Subjective, of course. Have you ever played with an inference machine that slurps up millions of RDF triples and then try to map what resources are representing? You need a large wallet and a fat pipe to get that right. Sure, caching, yadda, yadda, but in practical terms it's a kludge which could have been solved with a better framework for identification (well, ontological commitments of persistent identification, really) and some global agreement to what the semantics of that might be. W3C were that global entity, but they didn't do it. I've suggested the library world be that, though; authoritative and dedicated, and well worth funding for the future of digital knowledge representation. > What it is not, is pragmatic. URIs are > like kittens ... practically free to get, but then you have a kitten to > look after and that costs money. Thus doubling up your URIs is increasing > the number of kittens you have. [though likely not, in practice, doubling > the cost] Indeed. Cheers, Alex Cheers, Alex -- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps http://shelter.nu/blog | google.com/+AlexanderJohannesen | http://xsiteable.org http://www.linkedin.com/in/shelterit