Yes, I'm going to get sucked into this vi vs emacs argument for nostalgia's
From the linked, very outdated article:
> In fact, as far as I know I've never used an RDF application, nor do I
know of any that make me want to use them. > So what's wrong with this
a) Nothing. You would never know if you've used a CORBA application
either. Or (insert infrastructure technology here) application.
b) You've never been to the BBC website? You've never used anything that
pulls in content from remote sites? Oh wait, see (a).
c) I've never used a Topic Maps application. (and see (a))
> I find most existing RDF/XML entirely unreadable
Patient: Doctor, Doctor it hurts when I use RDF/XML!
Doctor: Don't Do That Then. (aka #DDTT)
Already covered in this thread. I'm a strong proponent of JSON-LD.
> I think that when we start to bring on board metadata-rich knowledge
monuments such as WorldCat ...
See VIAF in this thread. See, if you must, BIBFRAME in this thread.
There /are/ challenges with RDF, not going to argue against that. And in
fact I /have/ recently argued for it:
But for the vast majority of cases, the problems are solved (JSON-LD) or no
one cares any more (httpRange14). Named Graphs (those quads used by
crazies you refer to) solve the remaining issues, but aren't standard yet.
They are, however, cleverly baked into JSON-LD for the time that they are.
On Tue, Nov 5, 2013 at 2:48 PM, Alexander Johannesen <
[log in to unmask]> wrote:
> Ross Singer <[log in to unmask]> wrote:
> > This is definitely where RDF outclasses almost every alternative*,
> 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.
> 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.
> But wait, there's more! We haven't touched upon the next layer of the
> cake; OWL, which is, more or less, an ontology for dealing with all
> things knowledge and web. And it kinda puzzles me that it is not more
> often mentioned (or used) in the systems we make. A lot of OWL was
> tailored towards being a better language for expressing knowledge
> (which in itself comes from DAML and OIL ontologies), and then there's
> RDFs, and OWL in various formats, and then ...
Your point? You don't like an ontology? #DDTT
> Complexity. The problem, as far as I see it, is that there's not
> enough expression and rigor for the things we want to talk about in
> RDF, but we don't want to complicate things with OWL or RDFs either.
That's no more a problem of RDF than any other system.
> 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*
You can use URIs to identify anything.
The 303/httprange14 issue is what happens when you *dereference* a URI that
identifies something that does not have a digital representation because
it's a real world object. It has a direct impact on RDF, but came from the
TAG not the RDF WG.
And it's not messy, it's very clean. 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
> > * Unless you're writing a parser, then having a kajillion serializations
> > seriously sucks.
> Some of us do. And yes, it sucks. I wonder about non-political
> solutions ever being possible again ...
This I agree with.