Meeting Summary 30 July 2007
The group's original Use Cases
and Requirements document, first published in May, has now been updated in the light of comments received and following various discussions amongst group members. As a result we're now seeking publication of it as a revised Working Group Note (subject to one final edit being made).
The group remains undecided on whether the Descriptors should be linked from the DR or from the Resource Set. This remains an open issue therefore but one that needs to be resolved as it has a substantial effect on the structure of DR. Those present were either uncommitted on this issue or in favour of retaining the link from the DR to the Descriptors. Those in the other camp need to show up to put the case!
Progress has been made on the Description Resources document. This is the one that sets out what a DR actually is, what it's structure should be and how it should be linked from content etc. However, insufficient progress has been made for it to be submitted for first public working draft and so it remains an editors' working draft for now.
After a brief discussion about forthcoming face to face meeting at the Technical Plenary in November, and scope for repeats of the stakeholder meeting held in Washington earlier this month, the meeting closed. The next telecon will be at the usual time on Monday 3rd September.
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.