W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > March 2008

Re: ISSUE-89

From: Ivan Herman <ivan@w3.org>
Date: Tue, 04 Mar 2008 16:43:11 +0100
Message-ID: <47CD6E0F.7010004@w3.org>
To: Mark Birbeck <mark.birbeck@x-port.net>
CC: Johannes Koch <koch@w3development.de>, public-rdf-in-xhtml-tf@w3.org

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



> 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...


>>  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.


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...


> 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?


> 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

Received on Tuesday, 4 March 2008 15:43:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:55 UTC