Re: My no-longer pseudo code, the way I understand it:-)

I have run the tests that are marked as 'approved' either explicitly
under the heading

"Review and Approval 2007-08-02"

of http://www.w3.org/2006/07/SWD/wiki/RDFaTC or in the series of mails
of Ben at the end of last week. After some smallish bugs here and there
that I had to handle:-(, this implementation passes all of these:

0001, 0006, 0007, 0008, 0009, 0010, 0011, 0012, 0013, 0014, 0018,
0029, 0030, 0031, 0032

:-)

Ivan

Ivan Herman wrote:
> Hi everybody,
> 
> I had some further fun with what I talked about in [1]: it is now
> operational. I tested in on some of my own files on my machine. I still
> have to go through the formal tests on RDFa (I hope to be able to do
> that next week, because I will be out after that).
> 
> The URI I had in [1], namely [2], is no longer valid. To make things
> clearer and more manageable, I have indeed separated some
> functionalities in separate Python modules, so I have a small Python
> package instead, consisting of few files; you can look and download them
> in [3]. The core of the processing is the file 'Parse.py'; 'Literal.py'
> implements the agreement we have based on [4]; and 'State.py' takes care
> of namespace, xml:base, language, etc, handling for a specific node.
> 
> 'Parse.py' implements that current agreement we, I believe, have, namely
> [5]. I am very curious to see how this matches the understanding of
> others. B.t.w., even if you do not 'speak' Python, I hope the code is
> understandable by itself, I tried to make it readable and commented.
> 
> Of course, one of the good features of such exercise is that it reveals
> some edge cases and questions.
> 
> - I see it as a good sign that the core processing can be done in a
> relatively short and straightforward code. I think having RDFa doable
> easily _is_ a very important issue and, if this implementation as well
> as the other up-to-date ones (eg, Ben's) are o.k., we should begin to
> resist any new feature that would complicate implementations too much:-)
> 
> - I did *not* implement any kind of CURIE type processing (I mean,
> handling '[' and ']' characters in the references). For @href, @resource
> and @about I simply considered those as URI-s; for @rel, @instanceof,
> @property, @rev, I just considered them as essentially qnames.
> Essentially, because I do not check anything on syntax and I just use
> the qname structure to concatenate strings. After all, this is all that
> RDF requires. I do not think we need anything else at the moment
> (remember that I am not particularly interested in having the _:123 kind
> of feature for bnodes, I think we _can_ live without those).
> 
> - I know we found some side-effects with Ben on @about that were
> strange, and one possible approach was to take out @about from [5]. In
> fact, that was my first implementation, but I then decided to stick to
> [5] (for now). We will have to see what it leads to with the test cases
> and whether it is worth the trouble to do something more complicated.
> 
> - I implemented the container and collection handling as I described it
> in [6]. It just works:-)
> 
> - I am not sure that whether we decided on what should happen with
> @rel="", @instanceof="", etc. My proposal is: nothing. Eg, if @rel=""
> happens then the algorithm for determining a new subject for enclosed
> elements, as described in [5], kicks in, but no triple is added to the
> graph because the property URI is empty.
> 
> This has an interesting and (very!) positive side-effect. You may
> remember I had the problem of how to generate:
> 
> <> foo:bar [
>    a rdf:Seq;
>    rdf:_1 [ q:p "something" ].
> ]
> 
> which led to my proposal on "_:" for an anonymous blank node. Well, if I
> say:
> 
> <ul instanceof="rdf:Seq">
> <li instanceof=""><span property="q:p">something</span></li>
> </ul>
> 
> this is exactly what is generated. Why? The rules in [6] say that the
> <ul> above is a shorthand for
> 
> <ul instanceof="rdf:Seq">
>  <li rel="rdf:_1" instanceof="">
>   <span property="q:p">something</span>
>  </li>
> </ul>
> 
> The rules in [5] dictate that a blank node must be generated for the
> <li>, but with the additional rule above it also says that no triple for
> rdf:type is added to the graph because @instanceof="". Voilà! Ie: I
> hereby withdraw my proposal for "_:" (if we accept the rule above, that
> is:-)!
> 
> If you want to install it and test it (you are welcome to do so!), be
> sure you have rdflib[7] installed. Be warned, however: it seems that
> both the 'pretty' xml serialization and the turtle serialization in
> RDFLib has some problems (the default, pure "xml" works). The 'pretty'
> RDF/XML leads to bugs in some cases (notably for Lists), whereas the
> turtle is overzealous in defining @prefix statements and this produces
> some pretty unreadable code in some cases.
> 
> Sorry for the long mail (again)
> 
> Cheers
> 
> Ivan
> 
> 
> [1]
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Aug/0000.html
> [2] http://www.w3.org/2007/08/rdfa.py
> [3] http://dev.w3.org/2004/PythonLib-IH/pyRdfa/
> [4] http://www.w3.org/2006/07/SWD/wiki/RDFa/LiteralObject
> [5]
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Jul/0209.html
> [6]
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Jul/0174.html
> [7] http://rdflib.net
> 
> 

-- 

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