RE: Requirements for a possible "RDF 2.0"

Hi, 

> >>> * improved support for named graphs - essentially bringing the
> >>> constructs included in SPARQL back into RDF core (including support
> >>> for named graphs in RDF/XML, done in a manner that would be
> >>> backwards-compatible if at all possible)
> >>
> >> I'm not really sure how that fits all together. If you dereference
> >> some URI,
> >> and get back a RDF/XML document that includes other named graphs,
> >> what then?
> >> Surely the grph URI of the document you fetched you be the URI you
> >> dereferenced.
> >
> > That's certainly the elegant intuitive approach. Maybe I'm making the
> > mistake of engineering for engineering's sake, but I suspect there is
> > a role for multiple graphs in a single document/at a single
> > dereferenceable URI (dunno, somehow reflecting default graph/other
> > named graphs in SPARQL).

> > I don't have any genuine use cases.
> 
> I do, backups (well, restores more importantly) of SPARQL stores. We
> use TriG syntax for that.

I have another one: triples about one resource aggregated from different
data sources, under different licenses.
At Uberblic we also use TriG to express that.

Cheers,
Georgi

--
Georgi Kobilarov
www.georgikobilarov.com