Re: PROPOSAL to close ISSUE-40: no triples for empty elements

Manu Sporny wrote:
> If there are no objections to this proposal in 14 days, we will close
> ISSUE-40: no triples for empty elements.
> 
> http://www.w3.org/2010/02/rdfa/track/issues/40
> 
> We have traditionally gone to great lengths to not generate useless
> triples. This is in that same vein - an attempt to not generate useless
> triples. Having a triple like the following is mostly useless:
> 
> <> foo:bar "".
> 
> While one could make the argument that the existence of the triple could
> trigger some sort of behavior, the much stronger counter-argument is
> that, due to templating engines and lazy programming, there will be far
> more useless triples generated than useful triples.
> 
> I propose that we change the RDFa Core processing rules such that an
> element that contains a @property attribute, no @content attribute, and
> no text content will not generate a triple.

I can't see how this addresses or makes any difference - given the 
counter-argument above of templating engines and lazy programmers, then 
(using Richards example) this:

   <span property="foo:bar">{$templatevar}</span>

is just as likely as this:

   <span property="foo:bar" content="{$templatevar}" ...

where $templatevar = "" in both cases.

If { <> foo:bar "" } is a valid triple in RDF, then it must be able to 
be serialized in RDFa.

It really feels like these empty elements should generate triples, 
generally it's going to be programmers who write the scripts that 
consume / process RDFa and if they feel like adding a line that throws 
away all triples with empty elements then it's hardly a big job.

This said, I guess the only way to get anywhere close to something that 
will always produce expected results is to add in a keyword or symbol 
which is taken to mean 'no-content' or 'empty-string'.

note:
I'd hope that we'll all be moving to including datatype restrictions in 
ontologies in the near future which will cover whether a given value is 
valid for a given property or not, perhaps this along with processors 
which understand restrictions is the long-term-fix that addresses this 
and similar issues.

Best,

Nathan

Received on Sunday, 5 September 2010 19:19:20 UTC