Mason,
Thanks for the thoughts - I think it would certainly be an idea to change the name of the element. I'd personally prefer to go down the path of suggestion 1 (interest), as opposed to an "attention" element, which could get rather repetitive.
Everyone wondering what the context of Mason's remarks are:
At a meetup between a few interested APML parties in San Francisco, we discussed some changes to get APML toward 1.0. The primary topic of discussion was to migrate APML from being a standalone document to an Atom-embeddable content. The move toward a stream-based approach has a number of benefits:
- It makes it exceedingly clear that attention is an entity that changes over time;
- The updated and from attributes are no longer necessary, because these are inferrable from more standard Atom tags (such as id, published, updated);
- The container elements are no longer required, eliminating potential noise from the specification;
On top of this, it was widely felt that simplifying down to a single XML element (with a name under discussion below) with a "type" attribute indicating the ontology to which the attribute belongs. The element would also have (as per discussions on this previously on list), an optional uri attribute. A natural language text element would always be the required subject of the element, but the URI would make it possible for source systems with a richer ontology to support providing this information in a richer form.
The general theme of these changes is that APML should be as easy as possible to create; and consumers should be able operate at various levels of intelligence. Simple consumers will be able to make a number of assumptions about the stream that may lead to their data to be slightly inaccurate (but not so much as to be useless); whilst more complex consumers will be able to track the data in a more rigid way, and thus derive more from the stream. It is generally agreed that in terms of where effort should be expent, it is far better for a consumer to do slightly more work, since the consumer will always be the application with the most to gain from APML compatibility (whereas a producer has far less motivation to provide the information if it is difficult to construct).
A stream-based approach certainly has its challenges - but the synergies with other stream based data sources present an opportunity too good to ignore. A number of details for interpreting the stream have been considered and discussed, but I'd prefer to leave these details for the updated specification I plan to publish in the next week or so (if only to ensure that I can phrase them in a clear enough manner).
Thanks,
Paul.
--
You received this message because you are subscribed to the Google Groups "APML.Public.General" group.
To post to this group, send email to apml-...@googlegroups.com.