Re: Why empty named graphs make sense

On Wed, 2012-05-16 at 17:33 +0100, Andy Seaborne wrote:
> 1/ Scenario:
> 
> A site publishes a page, in RDFa, with triples in it.
> 
> The site replaces that page, with one saying, "changes in progress, 
> please come back later" with no triples.
> 
> Recording this seems like a reason to have empty named graphs.

I agree it's useful, I just don't know how to make it work with
partial-graph semantics.   See "subset semantics" in recent message,
http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0650.html

If 
     <g1> { }
and
     <g1> { :a :b :c }
entails
     <g1> { :a :b :c }

then information was the first graph conveying?   I think it was
conveying that <g1> had at least no triples, which isn't conveying much
at all.

I think this use case could be addressed with a vocabulary instead of
syntax, as you suggest I think for dealing with quadstores.  That is,
instead of allowing in a dataset:

   <g> { }

we could put in the default graph something like:

   <g> a rdf:EmptyResource.

It's certainly not as elegant, though.   (and not compatible with
existing SPARQL systems.)

Oh.   I guess with partial-graph semantics (aka subset semantics) one
could also make it complete with a count of the triples.  So

   <g> { :a :b 1,2,3 }.
   <g> rdf:tripleCount 3.

would tell us <g> has those three triples and ONLY those three triples.
With that, the complete-graph-semantics dataset:

   <g> { }

could be conveyed by the partial-graph-semantics dataset:

   <g> rdf:tripleCount 0.

Still not elegant, but it might be about as simple as possible.

    -- Sandro

   
> 2/ The default graph can be empty.
> 
> 3/ A point made has been that N-quads can't represent an empty named graph.
> 
> A syntax fix could be:
> 
> _ <http://space> .
> 
> or other style indicate a space name.
> 
> 
> To my reading, the spaces document works if "quads" are removed, not 
> that I'm suggesting that.
> 
> How about defining as a convenience of useful vocabulary rather than 
> core definition?
> 
>  Andy
> 
>

Received on Wednesday, 30 May 2012 00:41:59 UTC