Re: Reviving the features draft?

[Aristotle Pagaltzis <pagaltzis@xxxxxx>]

* Paul Denning <pauld@xxxxxxxxx> [2008-05-01 18:00]:
>     <collection href="...">
>       <a:title>foo</a:title>
>       <accept>...</accept>
>       <a:category scheme="http://example.org/scheme1"; term="http://.../a"; />
>       <a:category scheme="http://example.org/scheme2"; term="http://.../b"; />
>       <e:f />
>     </collection>
>
> How would I know that scheme1 is a scheme about "features", but
> scheme2 is a scheme about some other aspect of the collection?

By the definition of http://example.org/scheme1 and
http://example.org/scheme2.

>     <collection href="...">
>       <a:title>foo</a:title>
>       <accept>...</accept>
>       <a:category scheme="http://example.org/scheme1"; s:type="feature" 
> term="http://.../a"; />
>       <a:category scheme="http://example.org/scheme2"; term="http://.../b"; />
>       <e:f />
>     </collection>
>
> (Then you need a registry of scheme types (s:type), as opposed
> to a registry of schemes).

Too meta and doesn’t add any information. If two schemes are
semantically similar enough that you can usefully do something
with the information s:type gives you, then you might as well
just look for those scheme URIs directly. While s:type may allow
you not to hardwire those URIs, you just push the problem out to
hardwiring the s:type value. Either way you have to put knowledge
about the semantics of the schemes of that type into your client.
But the more specific those semantics are, and thus the more
useful, the smaller the group of schemes it is applicable to,
so the more types have to be hardcoded.

There is no real difference between atom:category/@scheme and
s:type and you gain nothing from adding it.

Besides, you propose a simple string value, as opposed to a URI.
That will hamper decentralised consensus and removes the
possibility of making the value self-documenting insofar as you
can make a URI derefernce to eg. an HTML page that describes its
meaning.

> Looking at RFC 5023 section 7, there does not appear to be a
> way to categorize a category document. To avoid the need for a
> registry, I was thinking that if I dereference the @scheme IRI,
> I could get a category document, then I could look inside it to
> see what type of category document it is (is it a category
> document that defines categories of Atom "features"?).

Be careful; you’re running out of oxygen.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>