For tomorrow's super session ( on ISSUE-78 and ISSUE-73 )

My writeup of the other day[1] was trying to gather the state of the issue. To move ahead the discussion, this is how I see the various issues today.

1. I believe we need a default profile, containing prefixes and terms. For practical reasons I am also in favour of having only one such profile for all RDFa host languages.

2. The default profile should have one, fixed, non dated URI. We may also set up a structure whereby that default URI dereferences a 'latest version', and those have dated URIs. Essentially, copying the W3C TR publication structure. But the RDFa recommendation would refer to a single, non-dated URI.

3. The default profile's content is _not_ frozen, but extended over time, and those changes are not dependent on the update of the RDFa specification. The RDFa WG does not have to define the frequency of the changes, nor the exact policy of changes, just request W3C to establish such a policy and mechanism for default profiles. 

4. The RDFa document should include guidelines on the publication of profiles (in general, not only for the default profiles) which encourage caching. Something like:

- profile file publishers are strongly encouraged to use the "Expires" response header to specify the life-span of their respective profile files
- clients are strongly encouraged to cache profile files locally using the Expires header
- profile publishers are required to publish this RDF graph in an RDFa file, and they may also choose to publish it in other RDF serialization formats. If they choose to do so, they should set up a proper content negotiation mechanism for the various serializations.

That is it.

RDFa clients may then implement a caching of the profiles trusting the 'Expires' response header; I guess browser/ECMASCript may also have to use the upcoming client-side storage of HTML5, for example.

As for the management of the default profile, the way I envisage it for now is:

- publish a profile file with the requirements above at W3C
- initially, we could choose an expiration rate of, say, 6 months; I would expect the frequency would go down, eventually to, say, a year or two
- we would set up an xpointer registry like mechanism that would lead to an update of the default profile at the agreed-upon rate; any change should also be announced on, say, the swig mailing list or some dedicated mailing list, plus, possibly, some RSS feed. (Ie, some applications may decide not to implement caching just to update the profile file manually at those times.)



Ivan


[1] http://www.w3.org/mid/CE0A4FB1-73AA-4C99-B8A9-7402D9643B3D@w3.org

----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf