2006/11/2, Henry Story:
On 2 Nov 2006, at 12:19, Thomas Broyer wrote:
>
>> [[
>> The "term" attribute is a string that identifies the category to
>> which the entry or feed belongs. Category elements MUST have a "term"
>> attribute.
>> ]]
>>
>> nowhere is there mentioned a IRI there,
>
> IRIs are not forbidden either, and Andrew's description makes me think
> the "concept URI" *is* the "term".
The question is: how does this help any of us? It may look like it is
a "term", but what is a client meant to do with all this information?
Nothing.
A client is not meant to do anything with atom:category elements other
than for categorizing the entry or feed.
So if Tim Bray uses
<category scheme='http://www.tbray.org/ongoing/What/'
term='Places' />
Then what am I meant to do with this info?
You can tell the reader that the entry is in the "Places" category,
you can provide a "show other entries within this category" feature,
you can group entries by their category (in a treeview: root nodes are
the list of schemes, their child nodes are the list of terms,
presented using the provided @label; if there are different @label
used, you can default to the latest and provide a tooltip or other
contextual info such as "a.k.a. Locations, Where"), etc.
Since scheme is a URL I can presumably go there to find something. But what?
Some people also want to dereference XML Namespaces' URIs.
Term is not defined to be a URI, and in the above example it is not,
and so why should I do anything with the term below?
<category
scheme="http://my.scheme.net/my-vocabulary/";
term="http://my.concept.net/my-vocabulary/13745";
label="cats"
/>
There's no reason you would do anything with it either.
What I am proposing is that we put forward some best practice to
formalize a useful and RESTful way to publish this information, so
that clients can use it. With APP we could do something like this: we
could define for example that when entries are published and they
contain categories that have a scheme that is accepted by the
collection, then the entry will be found in the feed that is to be
found either by appending scheme+term or in the catid location I
mentioned previously.
-1
But you can still do it yourself in your own implementation,
eventually with the use of an f:feature to communicate the feature to
clients.
So if Tim Bray posts an entry containing
<entry>
...
<category scheme='http://www.tbray.org/ongoing/What/'
term='Places' />
</entry>
and his collection manages the <http://www.tbray.org/ongoing/What/>
scheme, as defined perhaps in the service document, (and perhaps we
can place the list of available categories at that scheme location!)
then his client will know that the entry will also be found in the
<http://www.tbray.org/ongoing/What/Places> collection.
I don't see how this is useful, but you might have good reasons.
Now this would be useful for an APP publishing client, and it would
be useful for an APP reader, because it could find some useful
information at these various locations,
I understand the need to provide a "category URI" in some scenarios
but that should be an extension to the atom:category element or a
"mapping mechanism" communicated by a feed-level or entry-level
extension, but please no "global assumption".
and it would save us having
to define an unending number of link relations that parallel the
categories we have, when it is in fact clear that everybody intends
to use scheme+term as a uri.
Do you mean scheme+term, scheme+"/"+term or scheme+"#"+term?
or maybe scheme+"/"+term+".atom"? or scheme+"/tags/"+term?
--
Thomas Broyer
