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

On 16 April 2012 13:55, Michiel de Jong <michiel@unhosted.org> wrote:

> 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:
>

Hi and awesome that you're trying to reuse some of the ideas in webcredits.

The actual definitions are taken from the web commerce schema.


>
> - the fields need to be URIs (this part is already clear from the spec)
>

source and destinations do specifically say you should use URIs

first class objects are identified on the web using a URIs, conversely, if
you DONT identify something with a URI, you're not on the web


> - 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)
>

thanks for pointing this out, yes it does become clear when you're familiar
with linked data, but perhaps in consideration to the target audience, I
can try and make this point more understandable


> - 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).
>

this is a good point ... it's no coincidence that the same people that
brought us the web commerce vocab, are working hard on both JSON LD and the
HTML5 data layer family (rdfa, rdfa lite, schema.org, microformats) ...

perhaps manu may have had similar feedback on this one?

let's work out the best way we can explain things well to a wide audience


> - 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 the case of mailto this makes sense ... ive not considered very possible
uri scheme at this point ... it's probably quite an advanced use case, but
it's will be great if we can flesh it out as so many people use email today

tel: and xmpp: are are other interesting schemes where this applies


> 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).
>

sounds good!


>
> 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! :)
>

thanks so much for the feedback, I'll update the spec in line with these
comments and other feedback that I have had

I've even put an entry in my linked data calender to remind me! :)

I am keen to keep the spec short and simple, and some details are covered
in other specs.  But I'm sure I can make an improvement on the first draft
based on some excellent feedback.  Thanks!


>
>
> Cheers,
> Michiel
>
>