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@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 [email protected] - - - - - - - From: Dan Brickley <[email protected]> Date: 2015-04-28 8:14 GMT-03:00 Subject: Re: Domain of schema:numberOfEmployees? To: Sarven Capadisli <[email protected]> Cc: W3C Web Schemas Task Force <[email protected]> On 28 April 2015 at 10:41, Sarven Capadisli <[email protected]> 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 >
_______________________________________________ okfn-br mailing list [email protected] https://lists.okfn.org/mailman/listinfo/okfn-br Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
