apml-1-0---proposed - APML.Public.General

The current issues are up for discussion in the workgroup. Public discussion is also welcomed, along with inline comments with the items. No removal of items please!

Concepts as URIs - probably the largest issue of late, a decision needs to be arrived at as to how to best semantically enable entities represented in the APML.
- PaulJones: Personally, I believe that if URIs are introduced, we will need to continue to keep simple entries available in the APML, lest introducing additional complexity in actual interpreting the document.
- DannyAyers: I\\46#39;m pretty sure URIs can be used without introducing significant complexity. Simple string names within a doc can be appended to the source or a base URI (as with HTML anchors and XML namespaces), we just need to decide on the appropriate conventions. The value-add in terms of Web-interop is potentially huge.
- EliasBizannes: It seems we are more concerned about making APML human readable, rather than machine readable. When I export my contacts from an application, I dont care how it does it, I just want it compatible with my new application. I think we should be giving much more importance to the URI of the term rather than the term description because at the end of the day, the APML file
- ChrisSaad: It will also be important to clarify in the spec notes that concepts should be considered as data points rather than search queries. While the URI/Semantic representation will help for fully-formed entries and SemWeb aware apps, the question of context can also be solved by ensuring that algorithms based on APML data take the whole Attention Profile into account and look for clusters/patterns rather than looking at any single interest in a vacuum.
  - I\\47d suggest that the ability to be unambiguous about concepts is mostly useful in the opposite direction to looking at single interests. It\\47ll be much easier and to merge profiles (e.g. those of a group or organization) if identical data points can be recognised across profiles. It\\47ll also be more reliable data - as a crude example, "chat" from "wikipedia.org" might be referring to http://en.wikipedia.org/wiki/Chat - "casual conversation" or http://fr.wikipedia.org/wiki/Chat - "un mammifère carnivore de la famille des félidés"
  - Mason Lee: To disambiguate between languages, (e.g. "chat/chat", "pain/pain"), an attribute of type xs:language can simply be added to the concept element. See http://www.w3.org/International/articles/language-tags/. The syntax and standard values for this tag are defined in RFC 4646, which is extensible.
- Mason Lee: Categorical disambiguation (as opposed to language choice, above) could be handled with another new optional element, something like "category". The value could be a URI (e.g. "http://ampl.org/categories/bands"), some standards could be suggested at APML.org, but it could be extended by anyone else, using their own URIs. (bands, restaurants, movies, songs, etc.). Another option, maybe not as good, is to use just the xs:language type attribute (mentioned above) and use the RFC 4646 "extension and private use" mechanism to provide for tag category spaces (e.g. language="en-US-x-bands"). At either rate, one advantage to using optional attributes to enable semantic interpretation rather than making concepts themselves URIs, is that an unsophisticated APML reader could more easily ignore attributes.
  
  gdupont : I disagree with the extension of language attribute (and moreover adding a new attribute), but agree with its standard use. APML will not redefines its categories, there are multiple applications that can do that. Having a URI will allow all the disambiguation we need. For presentation purpose the term should absolutely be kept and thus any system receiving APML can either : process it by retriveing URI a,d present it to the user by using terms (and let the user do the disambiguation itself).
Addition of new node types - a number of new node types have been proposed, specifically people and locations.

PaulJones: Again, I personally believe this will be a good opportunity to make an extension mechanism concrete, and implement these as extensions to the specification.
DannyAyers: yep, better to use an extension mechanism than cram everything into the core.
is for applications and not humans to read. Danny is right about the opportunity
EliasBizannes: People and locations are logical. Locations gets my support, because that adds an interesting dimention to attention. Like triggering profiles or concepts based on location, as well as giving context to where that concept relates to (politics in sydney is different from politics in Rome). People however adds another namespace without real need. Concepts should be any noun, be it proper or common nouns...if we use URI as proposed, there is no need to segment the concepts
ChrisSaad: Agreed that an extensibility model is very important, however I think the addition of People and Locations (on top of \\46#39;Concepts\\46#39; and \\46#39;Sources\\46#39;) rounds out the format very nicely. People = Who, Locations = Where, Concepts = What, Sources = How
- HenriBergius: Location attributes could follow XEP-0080 field definitions for maximum compatibility with various geo applications
Tim Schultz: Modifications to the Head UserEmail tag that allows for value to be hashed (ie. MD5). Plain-text email addresses may be a security concern for things such as Spambots/crawlers.

Microformats - making APML, or at least components of it, available to embed within other content is likely to help with proliferation. Whether the base specification should define the microformats or if this is a task asked of the microformats working group is an issue that will need to be decided.
- DannyAyers: the microformats process probably rules out microformats.org blessing, but I totally agree HTML-embedding is desirable (see also GRDDL)
- Brian Suda: there is the POSH option with mapping structured tag clouds to APML. Also the existing hReview maps nicely to APML interests already. So there might be alot of re-usability. I have created some XSL templates to experiment with this and it sees to work so far.
- Matthias Pfefferle: Perhaps it make sense to use XFN for the \\46lt;Author\\46gt;-tag or \\46lt;Source\\46gt;-tag (or perhaps the coming people tag) like: \\46lt;Author rel="friend met" key="Sample" value="0.5" from="GatheringTool.com" updated="2007-03-11T01:55:00Z" /\\46gt;
Tighter definition of from attribute - at the moment the from tag is a rather free-form entity. It has been suggested before that this should instead be a URI, and specifying it in this way would make the purpose of the field much clearer. It may also be useful in the context of point 1.
- DannyAyers: +1
- EliasBizannes: Semanically aware just opens up the world of APML to much more +1
Time-based attention - specifying attention items that are valid only for a given time (with start and end datetime attributes of an attention node).
- HenriBergius: This could be useful for example if I\\47m planning a trip to London in February I could be interested in that Location node only for the duration of my trip. This kind of timed attention data could be quite easily gathered from services like Plazes and Dopplr.
- EliasBizannes: Currently, an APML file gets recalculated periodically, so that only the most recent concepts appear, but having a history of old concepts is valuable. It could bloat the file, but I think the value outweighs the cost. Just because someone paid attention to a concept a year ago, doesnt make it irrelevant. +1
- GDupont: +1 for the value of time bounds, but the "updated" attribute on every concept should be enough. Then a mechanisms of requesting only the cpncept that have been updated since adefined date should be available (ie "i want the APML for concepts defined during the last month or year").
Copyright and licence - define "copyright" (as text) and "licence" (as URL) attributes or nodes.

Olivier D. alias ze kat: see my discussion. I would like add in my APML public profils that I\\47m not agree for commercial use.

Version:

SpgmvSM.html	Oct 6
XFjKrUmW.html	Sep 16
services-supporting-apml	Sep 3
apml-1.0-draft-1	Aug 8
apml-lite	Jul 31
services-indicating-intended-support	Jul 31
adoption	Jul 31
apml-json	Jul 31
extensions	Jul 31
apml-1-0---proposed	Jul 31