making the webcredits.org spec more strict about 'source' and 'destination' fields.

Hi,

I'm starting to use the webcredits.org spec, and after a conversation
with Melvin, discovered the following restrictions on the 'source' and
'destination' fields, that i was not previously aware of, but that we
all need to enforce if we want your app to work with my app to work
with every app on the web:

- the fields need to be URIs (this part is already clear from the spec)
- the URI should be the URL of either a fragment of a document (not an
entire document) or an interface (this part is obvious to linked data
experts, but not to mere mortals like me)
- if it's the URL of a document fragment, then that document fragment
should be either
    - a human-readable description of the source/destination agent,
like a paragraph in English about a person.
    - or a machine-readable description of the source/destination
agent of the IOU, like a foaf profile of the person.
    - or both (using e.g. html5 data layer or content negotiation, the
same document can be like 'holographic' and present the same contents
in multiple formats).
- if it's the URL of an interface, e.g. mailto:user@host, then it
should be a way to contact the source/destination agent of the IOU.

In my app (Opentabs, an #unhosted app to keep track of #unpaid
transactions), i will only use mailto: and xmpp: URLs for persons, but
i will use http URLs for abstract IOU agents, like for instance when
"Unhosted's travel budget" owes me money, i denote that in a web
credit with source something like
http://unhosted.org/budget.html#travel (and then i'll first put our
budget document on that URL, with the correct section labels so that
the fragments work).

Please update the spec with this info, because i'm sure i'm not the
only one for whom this is a really complicated part of the spec,
that's truly hard to wrap my head around. but i think i understood it
now. :)


This is the way i will interpret the current spec. let me know if i'm
doing it wrong! :)


Cheers,
Michiel

Received on Monday, 16 April 2012 11:56:29 UTC