Buzzwords repository
I was thinking too about Web Services.
Here's what I'd like to do: an RDF database (queried using RDQL or SPARQL) with a SOAP interface. The big point is WSDL.
Some thoughts on XMLNS's XHTML version...
My previous post was not that clear about the relations between XPDL and DOAML's XMLNS. First of all, when I say "XMLNS" here, I mean "the XHTML version of the XMLNS", or, more precisely "the XHTML document you get if you point your browser to the namespace URI and request a MIME-type different from application/rdf+xml".
Secondly, this document must present briefly the main facts about the ontology, its goals, and the ways to get in touch with the community. This, for sure, must be done using existing RDF documents. It would be a perfect example of what can be acomplished through the definition and use of metadata: automatic page generation and (somewhat) automatic page updates. We already have all the pieces to build this puzzle: a little bit of DOAP data, some OWL data from the ontology, and some DCMI metadata for the XHTML document in itself.
We just need to pick the right informations from the right document. But here begin the bad news. We don't have any way of querying an RDF document using the advantages of its XML serialization. We can use SPARQL to query RDF documents, or XQuery to query an XML document, or, last but not least, XSL to transform an XML document. I would like to see a language / document type / whatever that would mix up XSL advantages (producing XML documents without breaking the "all-XML" chain, eg), but use SPARQL (or any other RDF query language, maybe more XPath-like, but playing with triples) instead of XPath...
But we don't have it now. Then we must use XSL, in order to transform XML documents into other XML documents. This truely sucks, because XSL cannot handle well the unpredictable syntax of RDF, and cannot reason either on its meaning. But we admit that we have syntaxically consistant RDF documents (we do it ourselves!), and go on with XSL.
We have now a little pack of XHTML documents, invalid against the DTD for sure (no <head />, no <body />...), but that we will unite together into a unique, valid XHTML document, using XInclude. And here comes my previous post. In a few words, it says that make breaks the "all-XML" chain and that Ant Java sucks, whereas XPDL rocks the Holy Trout.
Why I want XPDL for DOAML's XMLNS representation
[Follow-up of this post]
I think I know what I want to do on this page. I want an XHTML summary of DOAML, as provided in its DOAP document, informations about the ontology, extracted from the OWL data present in the RDFS, and finally, a quick list of the classes and properties defined by DOAML, and maybe some data I provide in XHTML - with, of course, the "look'n'feel" of the rest of the DOAML website.
I can make it using a Makefile, that will generate each chunk of data, ie apply stylesheets on the RDFS and the DOAP documents in order to generate XHTML documents, then put them along in the final XHTML document using XInclude, without forgetting to <link /> DOAML website's CSS, and pass it through tidy.
But... well, call me an <xml:geek/>, but I want to specify this in XML! And call me an extremist, but I can't stand Java, since it nearly screwed my last year's TPE (I have coded long-to-run programs, for example a PHP stuff that read the 50 Megs of a transcription of the X chromosom, but I have never coded such a long-to-start program: I had to launch it 10 minutes before the beginning of my oral exam!... anyway.), therefore I won't use Ant. Furthermore, Ant is somewhat too generalist.
But here comes the XML Pipeline Definition Language. I simply love it! But... yeah, you guessed it, Sun has implemented it... in Java, of course (well, that sounds logical when you know that Norman works at Sun Microsystems... why, but whyyyyy???). But save the last dance for me: implementing it in C, using libxml2, is simple as ABC... if only I knew C.
Well, in principle, that does not sound that difficult: the processdefs give you all the command-lines you have to call in order to execute what the user wants (although predefined ones, such as implementation.xslt-transform, or implementation.xinclude, implementation.schema-validate, etc, would be very useful... and maybe refering to them as URIs, too). You look at the dependencies (quite easy to my mind), and there you go, you launch the stuff... and it works.
libxml has all what we need, from XML Signatures verification to XSLT transformations, and also XIncludes, DTD Validation, etc. We may need some bits of external code (such as Tidy), but using the command-line form of the processdefs helps us with it.
Escape, yes, but don't forget the Archives!
Let's talk about Anouck. She is creating her FOAF document, but she receives tons of spam every day, and wouldn't like her new FOAF file to be one more way for spammers to get her mail address. Therefore she uses foaf:sha1sum in order to protect her privacy, but also to be identifyable within the Semantic Web. Her mail address is mailto:anouck@example.org, and its SHA-1 hash is 11a61224bc19649d4f3f2dec2406c88eff10c19e. Her FOAF document basically looks like this:
<foaf:Person> <foaf:name>Anouck</foaf:name> <foaf:mbox_sha1sum>11a61224bc19649d4f3f2dec2406c88eff10c19e</foaf:mbox_sha1sum> </foaf:Person>
But she hears about SHA-1 being broken. The FOAF community decide to create foaf:mbox_sha256sum, and Anouck immediately replaces her old SHA-1 checksum by the brand new SHA-256 checksum:
<foaf:Person> <foaf:name>Anouck</foaf:name> <foaf:mbox_sha256sum>a4b57c86f7efd0f7322ffe906c4e323b621f12df87006699b0728081ca092436</foaf:sha256sum> </foaf:Person>
And she thinks everything is perfect. Her mail address is perfectly protected from the spammers. Actually, it is, SHA-256 being - at the moment - resistant to the attacks. But what about archives ? What about old copies of her FOAF file, containing the same mail address, but hashed using SHA-1? There must tons of way to grab it! Google cache, Semantic Web crawlers, etc.
If the "go to high ground" technique is a very good way to save your life in case of a tsunami, it isn't is the case of protecting your mail address from spammers, just because of the archives... I wonder if there is a way to overcome this problem.
[Side note] The tsunami sign comes from a PDF by the Departement of Geology of the State of Oregon, USA.
[Edit] You can try to generate SHA-256 checksums with this page I created, based on a class I found on the Net. Remember that foaf:mbox_sha256sum does not exist yet!
