Re: Proposal: make more friendly for non-commercial usage

In GoodRelations, the notion of a compensation is

1. broad (in theory, it can include barter trade or "good karma" or "a smile") a d
2. optional, i.e. you can of course offer things for free, either by a UnitPriceSpecification of zero (explicit) or by omitting it entirely.

So there is no need to include the wording "in exchange". The essence is that you offer to transfer a bundle of rights on some object (sell a car, lease out a boat, disposing nuclear waste, ...) or carry out a certain activity on behalf of / to the benevolence of someone (cutting someone's hair, repairing a certain watch, ...).

In general I think that examples help in the wording, but they cannot substitute for a precise definition, and they must be chosen well.


On Sep 12, 2013, at 5:07 PM, Karen Coyle wrote:

> On 9/12/13 7:42 AM, Dan Scott wrote:
>> On Thu, Sep 12, 2013 at 11:14:10PM +1000, Renato Iannella wrote:
>>> Thanks for that Dan...some feedback...
>>> "" include "rights", "service" and is probably missing
>>> "product"....but I wonder if it is better to define Offer more on the
>>> process rather than the list of things that can be offered. We seem to
>>> use the generic "item" for perhaps a cleaner definition
>>> could be: "To present an item for consideration".
> We also batted around something using the term "exchange" - that would mean essentially "offer A in exchange for B". But that, too, had some problems for free goods and services, where there is no quid pro quo.
>> Right. It took me a while to figure out why "item" seems to have special
>> meaning in the docs, but I eventually realized that the usage
>> of "item" is more generally tied to the semantic types being marked up
>> (which explains the microdata itemtype / itemscope property names and
>> the references to "item" in the RDFa spec, for example). For those
>> coming to without that broader context, then, I'm concerned
>> that "item" is going to strongly suggest material goods rather than the
>> more inclusive products-and-services. (But perhaps that's based too much
>> on my own thick-headedness!)
> Well, we might be equally thick-headed, but "item" does feel like it has materiality that wouldn't cover services or other intangibles.
>>> BTW, it would be good if allowed definitions to standalone,
>>> and not force the "for example" text into the definitions (not good
>>> 11179 ;-) and added a notes metadata attribute...
>> I, too, admit to feeling a little discomfort about the heavy reliance on
>> examples in the definitions. It might be interesting to put together an
>> experimental draft that separates the inline examples from the
>> definitions, at least for a subset of the vocabulary: I suspect that it
>> would end up pushing us to strengthen the definitions in the long run.
> Unless our definitions become highly Wittgensteinian, and therefore nearly incomprehensible, I don't think we can do without the examples in the definition text. We need a simple definition that can be understood by folks with a wide range of English language skills, and that means that those definitions will be ambiguous (in most cases) without examples in the definition. I suppose that we could break up the definition pre- and post-"such as", but I wouldn't want to see the definition displayed ever without that "such as" portion.
> I think we all know that folks rely heavily on code examples (I'm a copy/paste/edit coder, myself) and more of those should be provided. Because the pages are often quite long for a single property or class, it might be useful to have a link from the top of the page to the examples (which would remind newcomers that there are examples on the pages).
> kc
> -- 
> Karen Coyle
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet

martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

phone:   +49-(0)89-6004-4217
fax:     +49-(0)89-6004-4620
www: (group) (personal)
skype:   mfhepp 
twitter: mfhepp

Check out GoodRelations for E-Commerce on the Web of Linked Data!
* Project Main Page:

Received on Friday, 13 September 2013 10:33:20 UTC