Documents and More Documents
As expected, today was spent documenting, only it was a little more intense. I provided examples for owl:SymmetricProperty, owl:TransitiveProperty, owl:FunctionalProperty and owl:InverseFunctionalProperty, as well as testing each, and documenting them all.

If nothing else, I got more practice writing RDF-XML, which is something I sorely need. During this process, and with a little help from SR, I discovered some of the answers to the questions I had about namespaces yesterday.

When I was using xmlns in a tag, it was being lost by the fact that the tag was already declared as being in the rdf namespace. So it was doing nothing for me.

I also discovered that using rdf:about to identify nodes picks up the base namespace of the document, xml:base, and simply tacks the name onto the end. For this reason, all the names I use in this way have to be prepended by #. On the other hand, using rdf:ID tells the parser that this is a fragment, so it automatically uses a # to separate it from the namespace.

The rdf:resource attribute seems to interact with namespaces similarly to rdf:about, so it is necessary to either fully qualify its domain, or else prepend with a #.

Still, it can be confusing with so many ways to represent the same thing, and with me only having a half of an idea of how it works. For instance, why would I want to choose:

<shutter-speed rdf:parseType="Resource">

Instead of:

<rdf:Description rdf:about="#shutter-speed">

There's probably some important difference, but for the examples I'm doing it doesn't seem to make a difference.

On the subject of important differences, I recall a conversation explaining something about the differences between rdf:about and rdf:ID, but I haven't been able to find it (not that I've looked too hard yet). From memory, there is something more significant than namespaces. It might have had something to do with referencing things outside of the current domain. This might be why rdf:about is preferred for declarations, as their visibility may be affected.

Sets and Differences
I think I have a better idea of what we need in order to do a difference now, and why NOT (or SELECT) wasn't working for us. I don't have time just now, but I'll try and explain it on Monday night.

In the meantime, AN has been able to send me his 3 level query which he thinks will produce an effective difference query. I'm not convinced, but subqueries can be complicated little beasts, so I won't judge it until I've had time to examine it properly. Either way, I still think we need a proper difference operation. If it is not possible to do a difference with multiple levels of subquery, then we need to implement it just for the sake of completeness. If it is possible, then we still need to implement it for the sake of efficiency, and also because the queries end up so complicated that they are almost impossible to understand.