The other day I mentioned email addresses packaged in OPML, in order to do this, I’m thinking there needs to be an attribute to define the email value…just like the field “creator”, defines the value that is a persons name.
Other attributes in an OPML file are: “link” means a HTML URL (htmlUrl), “rss” means a feed URL (xmlUrl), “link” can also be used for an OPML URL (htmlUrl)…so what attribute do we use for an email address, maybe “email” or “mailto”. We want these email addresses in the outline to be clickable and open up a new email.
I tried this in OPML Workstation as a “link” item, and typed in email@example.com, but this didn’t work, as since it is a link attribute it whacked a “http://” in front of it, and I tried mailto:firstname.lastname@example.org, but this didn’t work either, so we need to define a new type attribute, unless there is a way I have tried using the “link”, attribute.
But regardless of this, it is a good idea to define, these attributes so they serve one type of value only…at the moment if you were to search for terms in the “link” field in an OPML engine, it would return items that are both HTML URL’s and also OPML URL’s, this is because OPML URL’s are also defined with the “link” attribute, whereas I think it needs its own attribute.
But we can’t just use the “link” attribute for all types of content, ideally it would just contain HTML links, for OPML URL’s there could be an attribute called “opml”, etc….
[ADDED: OPML2.0 spec is suggesting this be called type = inclusion]
This way when we search an OPML engine, it could be like a library OPAC , or journal database, where we can do fielded searches that are more targeted…and the reason we can get this precise output is because it has been input precisely, where every value can only be entered into one type of attribute.
Then we can actually describe the whole OPML URL by format, is it a Reading List, Link List, a manual, a book, a blog…and then we can even describe its “aboutness”, ie. subject topic.
So I’m suggesting an OPML engine that can search by attribute, search by type, search by subject/tag…and search the full-text of the outline…then even maybe search full-text of the URL’s of the items in the outline.
I know Bela at OPML search is tackling a few of these things, and another OPML pioneer has an OPML folksonomy around the corner…tags for reading lists.
I guess this is what the OPML2.0 spec is all about, defining the fundamentals but allow it to be openly used…similar to Dublin Core, I imagine this means this set of attributes is extensible, all you have to do is make up your own attributes.
But then these may clash with someone else who is using the same made-up attribute as you, but to them it is meant to mean something else…this is why we create namespaces. The namespace will have a URL which will define the meaning of the attributes you have created.
I have a post from a while back on this semantic web type of stuff, it even goes deeper into defining the values within these extended attributes or the values in the core set of attributes, eg. what controlled vocabulary do the values in the subject attribute come from…pointing to a webpage where the thesaurus for the controlled vocabulary lives. Also mapping attributes, eg. in my namespace “author” is the same as “creator” in your namespace, etc…I guess this really gets into semantics, RDF, ontologies, etc…but I digress.
So by having namespaces for your extended attributes (pointing to a URL that explains what these attributes mean)…and also pointing to a URL that explains where the values came from within a given attribute (sometimes this is obvious, but with the “subject” attribute, there are many vocabularies), allows for a decentralised way for the web (machine) to understand (I use this word lightly) stuff.
Then there is how the value string eg. Tropea, John or John Tropea eg. 14/03/05 or 03/04/05 or 140305, etc… how is this syntax correctly written, pointing to a URL that defines this.
So my question is when we use namespaces, and qualify ourselves by pointing to URL’s that define these attributes, and URL’s that define the values in the attributes…is that enough, does the machine know what to do, without this all being programmed into the machine itself, ie. can the machine follow directions and interpret them as we mean them to be interpreted.
Does the software or browser that reads/processes OPML file know what these extended attributes are by just going to the namespace URL and understanding it on the fly…I’m not sure, I think it needs to be explicitly coded into the software or the browser.
Or can we have a registry of OPML attributes…
Here’s a tutorial on OPML elements/attributes, courtesy of Adam Green:
OPML Tutorial: RSS elements
OPML Tutorial: Link elements
OPML Tutorial: Text elements
Creating an OPML 2.0 namespace
[ADDED: I also like the suggestion that processors ignore attributes they don’t understand, in this instance you could have an OPML URL with all different types of items, text, HTML links, RSS, OPML…but if you load it into an RSS Reader, it will just load in those items that are RSS feeds, and ignore the rest, ie. it will extrapolate a Reading List from your OPML.
This is great to know, since Adam Green made an annotated Reading List, I thought, well now it’s not really a Reading List because it contains non-feed items, how is an RSS Reader going to deal with this.]
[ADDED: I forgot about all the attention data attributes, this type of OPML is generated by a machine (based on your reading behaviour), here are some links:
[GEEK] Unified name space for aggregator extensions for OPML?
[GEEK] Preliminary notes on OPML for BlogBridge
Attention Streams vs. The Fire Hose
Attention.opml or Attention.rss?
OPML and the road to Attention data: Progress
Conversations on Attention, OPML and Attention.xml]