[okfn-br] mirem-se no exemplo do Dan

Peter Krauss ppkrauss em gmail.com
Terça Abril 28 11:59:42 UTC 2015


OKBr's partidários do "tudo tudo tudo na lista",

Existem também os partidários a levar parte das discussões mais específicas
(de projeto) ao *Github/okfn-brasil/PROJETO/issues*
do respectivo projeto... Entendo que somos minoria, mas não custa confirmar
(por favor manifestem-se).

Coloquei "parte das discussões": existem sempre as mais holísticas, e a
sugestão de partir para os */issues* ou não é do pessoal que discute, não
tem regra... O importante, e que quero chamar atenção, é que *não deveria
haver barreira*.

Abaixo um exemplo fresquinho de como se dá a dinâmica de uma lista com o
pressuposto de especialização nos *issues*.

O Dan Bruckley é o gestor do projeto (no nosso caso poderia ser ou zelador
ou coordenador ou alguem da equipe), e ele, com alguns ajudantes mais
(usuários de github), incentiva a discussão geral na lista
(public-vocabs em w3c)...
Mas logo que ele percebe especialização ou chance de "formalizar pedidos"
(emissão de *ticket*), ele mesmo (exemplo anexo), se o assinante da lista
não estiver acostumado, consolida o discurso da lista num texto de nova
*issue*...
E assim vai:

* discussões de *isssues* que crescem, podem voltar à lista;

* discussões da lista que se especializam, mesmo sem ser "bug" nem "new
issue", ganham seu *ticket* (issue) com devido *label*

* *Labels* são bem diversificados e bem controlados, para acomodar todos os
tipos de discussão especializada: ver
https://github.com/schemaorg/schemaorg/issues

Essa é a minha leitura do "como funciona" (boas práticas para nos
espelharmos) uma *lista de discussão global acoplada às discussões
especializadas* e formalizadas (tickts) nas *Github/issues*.

Peter


- - - -
PS: o fato de a própria lista public-vocabs já ser meio especializada não
compromete a analogia, pois o "global" deles é realmente aberto e envolve
um publico amplo.

- - - - - COPIA DE MENSAGEM DA LISTA public-vocabs em w3.org - - - - - - -
From: Dan Brickley <danbri em google.com>
Date: 2015-04-28 8:14 GMT-03:00
Subject: Re: Domain of schema:numberOfEmployees?
To: Sarven Capadisli <info em csarven.ca>
Cc: W3C Web Schemas Task Force <public-vocabs em w3.org>


On 28 April 2015 at 10:41, Sarven Capadisli <info em csarven.ca> wrote:
> On 2015-04-28 11:02, Jindřich Mynarz wrote:
>>
>> Hi,
>>
>> why is the domain of <http://schema.org/numberOfEmployees> set to
>> schema:BusinessAudience? Shouldn't it be schema:Organization instead?

Thanks both. This is worth addressing. I've filed an issue:
https://github.com/schemaorg/schemaorg/issues/456

There is a natural temptation to try to generalize this further, but
(as I've argued in the issue tracker) things get complex quickly.
Adding Organization as an appropriate type for numberOfEmployees is a
quick and simple improvement.

Incidentally it does also improve (very slightly) the possibility for
verifying certain kinds of information, or at least probing for
consistency. For example consider an Organization that has Ali, Bob
and Carla listed as 'employee'. If we also had numberOfEmployees: 3,
we would have some additional confidence that we have a complete
description of the organization's employees (at that time, at least),
whereas if we had been told numberOfEmployees: 2, we might instead
care to re-evaluate what exactly the data was telling us. Since
schema.org (and microdata/rdfa/json-ld) descriptions are always
partial accounts of a larger reality, having these simple count
properties can provide helpful checks.

Dan

>> Best,
>>
>> Jindřich
>>
>> --
>> Jindřich Mynarz
>> http://mynarz.net/#jindrich
>
>
> Beside the point that the rdfs:comment only emphasizing on "business",
> looking at all of the rdfs:subClassOf schema:Organizations, it appears to
be
> that "number of employees" is suitable for all of them.
>
> I agree that domain schema:Organization seems more appropriate. Thinking
> ahead, are there organisations (currently undeclared) which do not have
> "employees"?
>
> -Sarven
> http://csarven.ca/#i
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20150428/06fe3594/attachment-0004.html>


Mais detalhes sobre a lista de discussão okfn-br