Meeting summary 23 July 2007
The meeting covered a lot of ground in a short time this week as we checked off a few open issues that needed looking at to allow progress on the Description Resources document.
First of all it was resolved to define an RDF predicate for use in DRs that allows one descriptive block to include another. In RDF terms that means that the Descriptors Class can have predicates that 'include' other Classes. This will be useful for reducing the amount of repeated data in a set of DRs that describe larger web properties.
We then, at last, agreed what to call the descriptive block: we will use hasDescriptors to link to a Class called Descriptors. N.B. The group skipped any discussion about whether to link the Resource Set or the DR itself to the Descriptors - the issue isn't fully resolved and discussion is continuing.
The group spent a little time considering how an organisation that creates a lot of DRs might make its repository available in bulk in as compact a form as possible. An RDF dump of a large number of DRs will, for example, include a lot of similar triples with the foaf:maker predicate have an identical object. There doesn't appear to be a strong case to devise an inheritance model (which would be relatively complex and error prone) so it was decided that the most likely way to reduce the size of the data would be to use simple entity declarations. One issue - can you encode an entity within an entity? For example, can you do this:
<!ENTITY foo "http://www.example.org?this=that&the=other">
since it includes the & entity? If not, this imposes a small restriction on what can be done to reduce the number of bytes needed to encode the data. It is, of course, true that the XML serialisation of RDF is highly verbose. N3 and Turtle being much more terse. Since we have resolved that we will also produce an XML Schema against which DRs may be validated, this may or may not not be applicable.
The next topic was 'the protocol part' of the Protocol for Web Description Resources. In particular, establishing a system through which an agent may find the DR for a particular resource without having the GET the resource itself. The group discussed ideas such as defining a new MIME type that could be used in an HTTP Accept header, or a new HTTP Header to be used specifically to request DRs - even a new URI scheme like powder://www.example.org, but it was felt (quite strongly) that such steps were not warranted by the use cases. Rather, it was resolved that we would encourage the encoding of links from resources to DRs in HTTP Link Headers (the HTTP equivalent of the HTML <link rel="...> element. Thus a HEAD request would yield the URI of the relevant DR (or DR package). A full GET request of the resource would be necessary to extract the link to its DR (assuming it was present) if there was no HTTP Link header. Either way, crawlers would be able to identify DRs for given URIs without needing to recognise any new headers or MIME types.
Finally, the group spent a short time discussing an updated version of the Use Cases and Requirements document. One issue remains unresolved but it is expected that next week's meeting will be able to resolve to publish an updated version of the UCR. It is also hoped that the Description Resources document will be sufficiently advanced to allow a transition request to first public working draft status.