Specifications

This page is about specifications for tags to be used for tag based trading. At the moment the only specification discussed here is the proposal for the URN namespace "trade". Feel free to add your own proposals, either for the structure of that namespace or for something different. Also, don't hesitate to add already existing specifications or links to specifications concerning tag based trade.

The URN namespace "trade"

What follows are proposals for specifying a URN namespace with the identifier "trade". As long as this namespace is not formalized, URNs with the namespace identifier "trade" should never be used. Instead, the name space identifier "X-trade" should be used: It marks the namespace as experimenal (cf. RFC3406). If you add a new proposal for a specification, please make sure that your experimental URNs don't clash with other experimental URNs. We recommend that you do this by making your URNs have the following format:

with:

When comparing branches and versions, case is relevant. The string "$branch.$branch_version" is called the version of the specification.

Branch a

• Version a.0.1
• Version a.d (development version, in flux)
• Discussion

The ontology tagtrade.org/Ontology/trade.owl

• Discussion

Ideas for specifications

Some random ideas concerning specifications:

• Microformats look like an interesting possibility for making up tag trade related content in HTML. One of the advantages is that they're easy to integrate into HTML and that they can be created and combined at will, which makes them evolve evolutionary. For content not in HTML one has several options:
  • Include a URL that points to a marked up HTML document.
  • Attach marked up HTML content, for example in an email.
  • Specify extensions to the non-HTML format in way that they can be mapped to Microformats.
  Various questions currently without an answer in this wiki:
  • What Microformats are available that could be helpful?
  • How can one somehow sign information encoded in Microformats, and how can one easily verify signatures?
• One may agree on a standard for tagging messages with a simple static specifier, e.g. a short string "T$T" (short for Tag Trade) in the subject of an email. Users may look for these strings and then find more information behind a more sophisticated additional tag.
• Instead of adding URN tags to messages, one could add URL tags:
  • By associating messages with URLs, one doesn't need to go through the procedure of applying for a formal URN namespace. Instead, a domain name serves as a name space identifier, and a domain name is very easy to register. OTOH, a formally registered URN name space may raise inititial acceptance, precisely why it has gone through an application process during which it was peer reviewed by experts. Another advantage of a URN based solution is that once a specification has been formalized, it is there forever, and people may use it even if the organization that originally created the specification breaks apart.
  • A URL based system could work as follows:
    1. A user writes creates a message, in whatever format he desires, for example in the markup used in phpBB fora.
    2. The user copies the message into a form, say at tagtrade.org. Using this form, he also specifies certain metadata such as how much he intends to pay for the task, and what is the tasks tag trade URL. The user also has the possibility to generate a has code from the message plus the meta data. This has code he can then PGP sign using a tool running on his computer.
    3. Once he clicked submit, a short URL tag is created, e.g. <url:http://tagtrade.org/tag/dfe324>.
    4. The user inserts the tag somewhere into his message and submits it to a forum.
    5. When someone loads the page behind the URL, then he is provided with information concerning the trade message. Furthermore, serving that page makes the server at tagtrade.org assume that the message has likely made its way into the public. As long as the page has not been requested, the message is assumed to have been discarded and it won't appear in the database at TagTrade.org.
  The advantage of this method is that it seems to be easy to understand and also to be quite user friendly. Also, the Internet doesn't need to be crawled by tag trade database backends in order to find messages. The disadvantage is that the data is stored centrally, which may be problematic if the organization behind the storage space becomes disrupted.
  As a compromise avoiding centralized, perhaps one should get rid of the idea of having a centralized domain based name space: Instead people just put meta information anywhere they like, e.g. on their own home page. Optionally they may put links to this information on web sites functioninig as hubs. To make it easy to identify tag trade related information, one may mark up URLs e.g. as follows: <tagtrade-URL:http://my-web-site/tt/asf24>.
  • In fact, a URL based system could be integrated with a URN
• I presented rough ideas for a pretty complex system in a talk that I gave at the conference Open Source and Sustainability 2006. I called this system the heavy weight solution. Due to it's complexity and due to liability problems, however, I don't think that it is feasible. - feklee
• One may want to use claimid or openid for giving people an identity.
• One may want to embed technology for filing e.g. requests for software extensions right into applications, in order to make things as simple as possible. For example, users may be given the possibility to click a button in a dialog of an application. This button redirects them to a forum where they can discuss feature extensions with other users, and where they can pledge money. Moderators, may help define a precise specification, collect the money, and redirect it to the developer who did the best job.
• It may be a good idea to include support for certificates (e.g. the ones by the LPI) into the system. A certificates should be signed by the organization that filed it, in order to make sure that it really belongs to the given user. Certificates serve at least the following two purposes:
  • When somone wants someone else to pursue a task, he may limit the people who he'll pay to the ones with a certain certificate.
  • People may document their personal success in acquiring new knowledge / learning by making their certificates public.

Advice for writing specifications

For advice concerning writing a specification for a formal URN namespace see the page on applying for a formal URN namespace.

<< Goals | Systems | Applications >>