Re: RDF-ISSUE-5 (Graph Literals): Should we define Graph Literal datatypes? [RDF Graphs]

Richard,

First, I have to say, look at the subject "RDF-ISSUE-5 (Graph Literals): 
Should we define Graph Literal datatypes?". All I've said is: Yes, I 
think we should, I would find that most useful. I'm not sure why that's 
such an issue? if you think no, then fair enough, I'm sure others think 
no too, but let's not make mistakes here, I didn't raise the issue, nor 
am I the only person who thinks it would be a useful addition.

In-line from here:

Richard Cyganiak wrote:
> On 5 Mar 2011, at 17:53, Nathan wrote:
>> Named graphs are layered on to the RDF Model, not in or part of it, and they already just "existed", stick some rdf on the web and you've got a named graph, a name (uri) associated with a graph.. it wasn't exactly a case of "we have a need for this, let's do something about it" and people serendipitously coming to the same conclusion.
> 
> [boring history lesson on named graphs]
> 
> Well, once an idea is widely accepted, it's easy to dismiss it by saying, “yeah it was obvious, nothing new there, it's not like anyone had to do any work for that.”
> 
> The mainstream opinion in 2004 was that provenance in RDF is handled by reification, which had been put into the official W3C specs for that very reason.
> 
> The point of view that reification is a big mistake, and that something very different is needed, was mostly dismissed at that point. Why use something else if the official W3C spec already has a feature supporting the use case?
> 
> The only people who put RDF on the web back in 2004 were the FOAF folks. There was probably no one outside of the TAG who was familiar with both REST and RDF. The most popular Semantic Web framework of the day, Jena, didn't have anything resembling named graphs; if you wanted to retain provenance information in your models, you'd most likely reify everything (or keep everything in separate models, but then you couldn't query across them).
> 
> It required lots of hard work by many people to get the idea of named graphs off the ground. All the following stuff happened around 2004 and 2005, all outside of W3C working groups:
> 
> http://portal.acm.org/citation.cfm?id=1060835
> http://www.w3.org/2004/03/trix/
> http://www4.wiwiss.fu-berlin.de/bizer/TriG/
> http://www4.wiwiss.fu-berlin.de/bizer/TriQL/
> http://www4.wiwiss.fu-berlin.de/bizer/ng4j/
> 
> This laid the groundwork for named graphs becoming sufficiently accepted that Andy and the DAWG could put it into SPARQL in 2006 or so.

I certainly didn't mean to undermine that work, and apologies if I did. 
It took some time to connect the dots, it always does, and I'm glad they 
were (although I'm quite sure Jeremy Carroll was suggesting them in 2003 
as being quite appropriate, more so than quads and quints even). 
Personally, I find Named Graphs most useful, and have many many use 
cases for them, even more than I do for graph literals.

One just hopes this isn't an OR thing, we can have one or the other, not 
both.

>>> The problem we face is that the specs are several years behind what's actually deployed and in active use. I'd prefer to see this WG spending its time on dragging the specs forward to catch up with reality as deployed and in active use. This WG is simply the wrong venue for speculating about the one feature that would make the whole world embrace RDF if it was added. If you have an opinion on that, then by all means round up some like-minded people and get busy coding/writing it up. That's R&D, and it's an extremely important part of advancing our case; in fact, I know that many members of this WG spend a lot of their non-WG time on this sort of activity. But standardization has to *follow* successful R&D. It cannot lead it.
>> but yes, I agree with the principals of standardization, there must be something that needs standardized.. like say rdf, sparql, n3, amord in rdf ... would they be good examples?
> 
> RDF and SPARQL are already standards, so I don't know why you bring them up here.

Because they aren't aligned.. I'm not the only one who's said that, I'd 
even thought there was a general sentiment of wanting to align them as 
much as possible.. also thought that group graph pattern {...} was part 
of the sparql notation? perhaps I'm wrong.

> The community reaction to N3 was to throw away the non-RDF bits and to retain the RDF-compatible subset. That subset has become wildly popular. Many prefer it over the official W3C recommended syntax. In all these years, the extra bits of N3 have caught on only with a handful of people.
> 
> AMORD in RDF is certainly interesting. Looks like it's been around for two years. How much uptake has it seen?

Well on both counts, if you've got a stack of software which has been 
heavily invested in and deployed, centred around a format which can't / 
doesn't support these features, it's hardly surprising their use isn't 
widespread, it also makes you wonder why these things were created, if 
the they aren't needed by someone..

> Nathan, you think that you know what people need. You think that you can predict the future. To you it's obvious that if only we standardized X, then RDF adoption would skyrocket. But I don't trust your judgement on this, nor anyone else's crystal ball gazing. I believe that our work in this WG should be guided by the available deployment+uptake experience: implementations with happy users; companies that have put their money where their mouth is; the millions of files that actually have been put on the Web; the threads on jena-dev or Semantic Overflow where dozens and dozens of RDF newbies stumble over the same problems.

Not quite sure what to say to that, but I'll confirm that I don't think 
I know what people need, can't predict the future, and afaict haven't 
claimed that I know any secret that would make RDF adoption skyrocket. 
I'm not sure what prompted the personal comments about me directly, but 
apologies for anything I may have said out of turn Richard, didn't mean 
to offend.

There's a whole list of things that /could/ be in RDF, and if somebody 
will use them, and they don't conflict with other features, then my 
personal view is, let's have them, named graphs, quoted graphs, graph 
literals, literal subjects, bnode predicates, changes of scope for bnode 
identifiers (to the graph name no less!), alignment of plain 
literals/xsd:string, alignment of sparql,n3,turtle syntax, the list goes 
on. I understand the point of standardization (tis why I'm here), of 
constraining things so users get expected functionality, and of leaving 
enough scope for, and considering, evolution. I'll firmly advocate all 
of these things (and do what work I can), whether it's on behalf of 
somebody else, or myself (i.e. things you want/need, things others do, 
and things I do), and for each one that makes it in to the rec, I'll 
give a little cheer.

None of these things are magic keys which will make RDF adoption 
skyrocket - if that's the goal let's just clump together and pay some 
"rock-star devs" to plug the hell out of RDF - but each of these 
features will make my days of working with RDF (what few there are now) 
easier, will clean something up, or just makes sense.

> We have a charter that cuts out the work for us. Most of it is rather boring -- agreeing on terminology and syntax; updating RFC references; sorting out shitty details like the scope of blank nodes and so on.

Ack, perhaps I'm a bit of a freak, bar the terminology bit, I rather 
like all those shitty details :)

> Can we please just do that stuff and leave the crystal balls over on semantic-web or public-lod?

Indeed, can we leave our normal balls there too?

Best,

Nathan

Received on Saturday, 5 March 2011 20:46:14 UTC