Another way of putting it is the divide between the XML crowd and the Web 2.0 crowd. In Sean McGrath’s closing keynote, thankfully written up by Jeremy Keith, he talked about navigating the path between the document web and the programmable web, and the danger of tipping the balance too much in either one way or the other. XTech provides a great service in providing that balance, and of giving those of us with feet in both camps a home.

Particularly encouraging for me was to see some of the principles of the programmable web filtering into sites such as the Guardian and the BBC which aren’t part of the Web 2.0 vowel-deprived clique. It gives me hope for the public information sector, in which I happily find myself.

So many many thanks to Edd and to everyone who supplied me with alcohol, deprived me of sleep, and talked to me about tech. I can’t wait until next year.

Anyway, I was just browsing through the schedule and it struck me how few women they were speaking. Looking at the speaker list, out of the 64 speakers, just three are women. Three! That’s not even 5%!

Looking back at last year, it was a little better, at nine out of 94, which is getting towards 10%. It wasn’t much better at XML 2007, where nine of the 82 speakers (11%) were female. At Extreme 2007, eight of the 60 speakers (13%) were women.

I wonder whether there are a low proportion of women attending these conferences generally, or whether women attend in higher proportions but don’t submit papers, or whether they submit papers but a smaller proportion are accepted.

Anyway, if you’re a woman who’s going to XTech 2008 and you want to get together to talk about kittens, drop me a line.

Developer * XSLT * XML * Schemas * JavaScript * XHTML * CSS.

Global retail organisation and household name is looking for 2 (two) Front-End/User Interface Developers to work on a major consumer e-commerce portal.

MAIN TASKS/REQUIREMENTS:

• Development of enterprise solutions
• Development of Consumer driven applications
• Adherence to Software Development Methodology

ESSENTIAL SKILLS:

• XSLT & XML
• XML schemas
• JavaScript
• XHTML
• Cross browser and platform CSS positioning
• Accessibility

DESIRABLE (not essential) SKILLS:

• Understanding of web design
• JavaScript, including AJAX & DHTML
• OO JavaScript

These roles represent the opportunity to consult for a global multi billion global organisation.

The roles will pay £400 to £450 per day and they are 3 to 6 months contracts.

The role is based in Welwyn Garden City in Hertfordshire.

It is a 15 to 20 minute walk from the train station and there is a company service bus every 15 minutes at peak times from the station to the campus.

naturally there is loads of parking space for cars.

• who made the statement
• when the statement was made
• what evidence that led to the statement being made
• licensing information about the reuse of the statement
• (if we go with the rating idea) what ratings the statement has been given
• (if we allow editing of statements) what changes have been made to the statement over time

and so on. In short, all the metadata that you’d want to associate with resources you’d also want to associate with statements.

I’d anticipated using reification to associate metadata with statements. Something like this

<rdf:Statement rdf:about="#statement1">
  <rdf:subject rdf:resource="/people/CharlesDarwin" />
  <rdf:predicate rdf:resource="/ontology/event-roles/passenger" />
  <rdf:object rdf:resource="/events/BeagleVoyage" />
  <dc:creator rdf:resource="/users/JeniT" />
  <dc:date rdf:datatype="xsd:date">2008-04-11</dc:date>
  <g:certainty rdf:datatype="xsd:decimal">1.0</g:certainty>
  ...
</rdf:Statement>

or using rdf:ID, although this does limit the URI of our statements to hash-URIs:

<rdf:Description about="/people/CharlesDarwin">
  <r:passenger rdf:ID="#statement1" rdf:resource="/events/BeagleVoyage" /> 
</rdf:Description>
<rdf:Description about="#statement1">
  <dc:creator rdf:resource="/users/JeniT" />
  <dc:date rdf:datatype="xsd:date">2008-04-11</dc:date>
  <g:certainty rdf:datatype="xsd:decimal">1.0</g:certainty>
</rdf:Description>

(Please feel free to correct my RDF, RDF-folks!)

We can embed this information into our web pages using RDFa:

<div about="#statement1" instanceof="rdf:Statement">
  <p class="statement">
    <a rel="rdf:subject" href="/people/CharlesDarwin">
      Charles Darwin
    </a>
    was a
    <a rel="rdf:predicate" href="/ontologies/event-roles/passenger">
      passenger
    </a>
    on the
    <a rel="rdf:object" href="/events/BeagleVoyage">
      <span about="/people/CharlesDarwin" 
            rel="r:passenger" 
            resource="/events/BeagleVoyage">
        Beagle Voyage
      </span>
    </a>
  </p>
  <dl class="metadata">
    <dt>Author:</dt>
    <dd>
      <a rel="dc:creator" href="/users/JeniT">
        Jeni Tennison
      </a>
    </dd>
    <dt>Date:</dt>
    <dd property="dc:date" datatype="xsd:date" 
        content="2008-04-11">
      11 Apr, 2008
    </dd>
    <dt>Certainty:</dt>
    <dd property="b:certainty" datatype="xsd:decimal"
        content="1.0">
      <img src="stars5.gif" alt="five stars" />
    </dd>
  </dl>
</div>

Note that I’ve incorporated both the reified statement and the statement itself into the RDFa. If I’m correct in my mental parsing of RDFa, I think this leads to the set of triples from the RDF/XML in the above examples plus the triple:

</people/CharlesDarwin> r:passenger </events/BeagleVoyage> .

But then the other day, I was reading the tutorial How to publish Linked Data on the Web, which says

We discourage the use of RDF reification as the semantics of reification are unclear and as reified statements are rather cumbersome to query with the SPARQL query language. Metadata can be attached to the information resource instead, as explained in Section 5.

Jumping to Section 5, I find

Metadata: The representation should contain any metadata you want to attach to your published data, such as a URI identifying the author and licensing information. These should be recorded as RDF descriptions of the information resource that describes a non-information resource; that is, the subject of the RDF triples should be the URI of the information resource. Attaching meta-information to that information resource, rather than attaching it to the described resource itself or to specific RDF statements about the resource (as with RDF reification) plays nicely together with using Named Graphs and the SPARQL query language in Linked Data client applications…

There are some examples of what this looks like within the tutorial. The first is an “authoritative description” found at http://dbpedia.org/data/Alec_Empire after a 303 redirection from http://dbpedia.org/resource/Alec_Empire.

# Metadata and Licensing Information
<http://dbpedia.org/data/Alec_Empire>
    rdfs:label "RDF description of Alec Empire" ;
    rdf:type foaf:Document ;
    dc:publisher <http://dbpedia.org/resource/DBpedia> ;
    dc:date "2007-07-13"^^xsd:date ;
    dc:rights <http://en.wikipedia.org/wiki/WP:GFDL> .

# The description
<http://dbpedia.org/resource/Alec_Empire> 
    foaf:name "Empire, Alec" ;
    rdf:type foaf:Person ;
    rdf:type <http://dbpedia.org/class/yago/musician> ;
    rdfs:comment
        "Alec Empire (born May 2, 1972) is a German musician who is ..."@en ;
    rdfs:comment
        "Alec Empire (eigentlich Alexander Wilke) ist ein deutscher Musiker. ..."@de ;
    dbpedia:genre <http://dbpedia.org/resource/Techno> ;
    dbpedia:associatedActs 
      <http://dbpedia.org/resource/Atari_Teenage_Riot> ;
    foaf:page <http://en.wikipedia.org/wiki/Alec_Empire> ;
    foaf:page <http://dbpedia.org/page/Alec_Empire> ; 
    rdfs:isDefinedBy <http://dbpedia.org/data/Alec_Empire> ;
    owl:sameAs <http://zitgist.com/music/artist/d71ba53b-23b0-4870-a429-cce6f345763b> .

The second is a non-authoritative description found at http://sites.wiwiss.fu-berlin.de/suhl/bizer/pub/LinkedDataTutorial/ChrisAboutRichard:

# Metadata and Licensing Information
<>
    rdf:type foaf:Document ;
    dc:author <http://www.bizer.de#chris> ;
    dc:date "2007-07-13"^^xsd:date ;
    cc:license <http://web.resource.org/cc/PublicDomain> .

# The description
<http://richard.cyganiak.de/foaf.rdf#cygri> 
    foaf:name "Richard Cyganiak" ;
    foaf:topic_interest <http://dbpedia.org/resource/Category:Databases> ;
    foaf:topic_interest <http://dbpedia.org/resource/MacBook_Pro> ;
    rdfs:isDefinedBy <http://richard.cyganiak.de/foaf.rdf> ;
    rdf:seeAlso <> .

Note that rdfs:isDefinedBy does not necessarily point to the data you get when you retrieve the resource, but to an (presumably there can be more than one) authoritative description of the resource. It’s also associated with a particular resource rather than a particular statement.

To know which metadata applies to a particular statement, an application must know where it got the statement from. In effect, a statement here has four parts: subject, property, object and location (with the possibility that multiple statements with the same subject, property and object might have different locations and therefore different metadata). This is similar to assigning an ID to a statement, as with rdf:ID, but restricts the statement’s identifier to being the location where it was found.

So what does that mean for the genealogical web app? Well, in the app we’re going to find any given statement by a particular user quoted on lots of pages. I was intending to RDFa them all but that would mean lots of duplicate statements from different locations, potentially bloating applications that were harvesting the data.

I can’t work out whether I like or loathe the Linked Data concept of associating metadata with the document in which you find triples. In some ways it seems very natural — look for information about a resource at the URI for the resouce — but the metadata mechanisms restrict where you can place statements on the web (or at least assign semantics to their location which aren’t necessarily intended), and that seems like a Bad Thing. On the other hand, perhaps I’m just being overly influenced by the desire to use RDFa, which does lead one to want to mark up data wherever it appears.

I’d welcome any advice.

The Xpath for accessing a particular part’s title would be /law/part[2]/title so the PRESTO URLs would need some kind of convention.

[snip]

Now, I am not sure I understand the issues well enough to say which system for indexing is absolutely best. But I think the advantage of http://www.eg.com/law/part2/title over http://www.eg.com/law/part2/title is that it is probably a more common case that your system is interested in /law/part[2]/title rather than all titles of parts /law/part/title. But it is a matter of the particular use case and the consequent virtual schema.

This has particular interest to me because I’ve recently been involved in putting some of the UK’s legislation online. We don’t expose the parts/sections and so on as individual documents at the moment (although this is something that you get with the Statute Law Database, albeit with an awful URL scheme).

Anyway, we do have anchors for parts/sections within the main legislation which follow a similar scheme to the one that Rick suggests here. But they have a drawback: at least for consolidated legislation (which reflects the “current state” of legislation that has been amended by later legislation), the anchors don’t reflect the semantics of the numbering scheme used by the document. For example, see Section 5A of the Rent Act 1977, whose URL is:

http://www.opsi.gov.uk/RevisedStatutes/Acts/ukpga/1977/cukpga_19770042_en_2#pt1-pb2-l1g6

As you can see, the URL ends in a 6 rather than 5A because it’s the 6th Section that appears in the document.

The thing is that generic, position-based XPaths into content are seldom the ones that make most sense semantically. A friendly XPath to Section 5A would look like:

/part[1]/group[2]/section[3]

and even if you just counted sections it would be:

//section[6]

when what you really want is the equivalent of:

//section[number = '5A']

Given this, I wonder if a “striped” URL scheme would be better, by which I mean something that follows the general pattern /name/identifier/name/identifier. For example:

/part/I/section/5A

There are several advantages to this. The resulting URLs are more semantically meaningful than those based on positions. They are more robust to changes in the document (which naturally happen with consolidated legislation). They also provide a neat method of returning all the sections in a particular part, such as:

/part/I/section

(though you could get this advantage with a position-based scheme as well, depending on how you map from XPath to URL).

The main disadvantage is that you have to provide a custom mapping from XPath to URL, because it’s not immediately obvious what identifier to use for a given element: it might be a <number> element child for one kind of element, but an id attribute for another element, and the position of the child for some other element. Of course you could add annotations to your schema to indicate what acts as the identifier for that particular element type, but it does raise the implementation barrier.

• a tokeniser that uses regular expressions to add markup to plain text
• a gazetteer that uses a lookup to add markup to plain text
• an annotater that adds attributes to existing elements based on their context/content
• a grouper that adds markup around sequences of existing markup
• a stripper that removes markup
• a general purpose transformer that uses XSLT to do just about everything else

The “grouper” is the most interesting and difficult of these. It needs to act like a tokeniser, except use regular expressions over markup rather than over text. For example, say I had:

<number>06</number><punc>/</punc><number>03</number><punc>/</punc><number>08</number>

I want to be able to create a rule that says “any sequence that looks like a number element that contains a two-digit number between 1 and 31, followed by a punc element that contains a slash, followed by another two-digit number between 1 and 12, followed by a punc element that contains a slash, followed by another two-digit number should be wrapped in a date element”.

Now this is something that XPath is really bad at. Try writing an expression that selects, from a sequence of elements that may contain other <number> and <punc> elements as well as other elements, only those sequences of elements that match the pattern I just described. It’s something like:

number[. >= 1 and . <= 31 and string-length(.) = 2]
      [following-sibling::*[1]/self::punc = '/']
      [following-sibling::*[2]/self::number[. >= 1 and . <= 12 and string-length(.) = 2]]
      [following-sibling::*[3]/self::punc = '/']
      [following-sibling::*[4]/self::number[string-length(.) = 2]]
  /(self::number, following-sibling::*[position() <= 4])

which is fiddly and messy and only works in this particular example because I know precisely how many elements there are supposed to be in the group.

In fact, it’s even difficult to do this kind of grouping using XSLT, even with <xsl:for-each-group> because the grouping is designed around elements either returning the same value or starting or ending with a particular kind of element, rather than grouping together a sequence that has a particular internal structure.

The language that is designed to describe sequences of elements is RELAX NG. Obviously RELAX NG is really useful as a schema language, but it’s really all to do with defining regular expressions over XML structures. We can use RELAX NG to describe the pattern of elements we want to match:

<group>
  <element name="number">
    <data type="integer">
      <param name="minInclusive">1</param>
      <param name="maxInclusive">31</param>
      <param name="pattern">[0-9]{2}</param>
    </data>
  </element>
  <element name="punc">
    <value>/</value>
  </element>
  <element name="number">
    <data type="integer">
      <param name="minInclusive">1</param>
      <param name="maxInclusive">12</param>
      <param name="pattern">[0-9]{2}</param>
    </data>
  </element>
  <element name="punc">
    <value>/</value>
  </element>
  <element name="number">
    <data type="integer">
      <param name="pattern">[0-9]{2}</param>
    </data>
  </element>
</group>

or, in compact syntax:

element number { 
  xs:integer { minInclusive = "1" maxInclusive = "31" pattern = "[0-9]{2}" }
},
element punc { "/" },
element number { 
  xs:integer { minInclusive = "1" maxInclusive = "12" pattern = "[0-9]{2}" }
},
element punc { "/" },
element number { 
  xs:integer { pattern = "[0-9]{2}" }
}

As a language, RELAX NG is really good at this. You could even imagine adding attributes to name subexpressions which you could then do things with (in the same way as you can get the substring matching a subexpression when you use a regular expression over text).

So I think a “grouper” component should use RELAX NG to identify sequences to be marked up. But I have no idea if there are RELAX NG libraries out there that can be used in this way: to identify and extract matching sequences rather than to validate entire documents.