Re: ISSUE-89

Mark Birbeck wrote:
> Hi Ivan/Johannes,
> 
>>  Eagle eye: I think you are right...
> 
> Yes, Johannes is exactly right. Damn...
> 

:-(

[snip]

> to appear in the triples, but of course that was triggered by the
> @rel="dbp:citizenship" element, and not the @property elements. If I
> comment out that block I get exactly the problem Johannes describes.
>
> :(
> 

As an aside... I wonder whether we have a test case that relies on 
@property only to complete the triples. As the experience shows:-), such 
a test case is useful...

[snip]

> 
>>  I believe this is really an editorial issue, though it is on the
>>  borderline of technical. The intention is that, in 'human' terms, if an
>>  element does not include any of the RFDa attributes (well, the @content
>>  and @datatype are put aside here) then everything should simply 'flow'
>>  through. AFAIK, all implementations do that. It was raised in the
>>  discussion several times that one way of documenting this in the
>>  processing steps is to define a separate clause in the processing steps
>>  for this alternative and get it over with, so to say; but then it was
>>  decided that this alternative would be incorporated into the main flow.
>>  And that is where the it went wrong, at least I believe...
> 
> We've discussed this before, and it's not quite as simple as that. We
> can't simply ignore any element that doesn't contain an RDFa
> attribute, since we still need to process namespace and language
> attributes, placing that information into the evaluation context that
> is passed on.
> 

And I agree, obviously. What I was thinking of doing is to spawn off a 
branch after the evaluation context is updates with those.


> But if we complete any incomplete triples on every child that is
> recursed into we get lots of duplicates.
> 

Yeah:-(

My implementation of course does not care, because the underlying RDF 
system (RDFLib) takes care of the 'set' aspect, ie, the duplicate do not 
appear in the output. I could imagine that for others this may become a 
royal pain if they want to filter those out from the output. Of course, 
another approach is to leave the duplicates in the generated result...

[snip]

> 
> I'm going to try to solve this, but I have a feeling that I'm not
> going to be able to crack it in such a way that it's a merely
> editorial change. Therefore, as far as I can see the change that has
> the least impact (the lesser of the various evils) is to not have
> @property set the skip flag. We'll end up with duplicates of certain
> triples, but as Ivan says, it's not so terrible.
> 

You mean: the skip flag is not set if @property is around, right?

Ivan

> Regards,
> 
> Mark
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf