- From: Jarno van Driel <jarno@quantumspork.nl>
- Date: Tue, 8 Oct 2013 00:55:45 +0200
- To: Dan Brickley <danbri@danbri.org>
- Cc: "Evain, Jean-Pierre" <evain@ebu.ch>, Thad Guidry <thadguidry@gmail.com>, Dan Brickley <danbri@google.com>, Guha <guha@google.com>, Martin Hepp <martin.hepp@ebusiness-unibw.org>, Stéphane Corlosquet <scorlosquet@gmail.com>, jean delahousse <delahousse.jean@gmail.com>, "public-vocabs@w3.org" <public-vocabs@w3.org>
- Message-ID: <CAFQgrbYj+78_ZpLCh-F26ts=-+1fBC35SaQMwjd3iASYrwonJw@mail.gmail.com>
> One issue with types that have 'obvious' names is that people rarely feel compelled to consult their documentation. I think this is actually a very valid argument > And the word 'Enum' (for http://schema.org/Enumeration), which has been part of schema.org's model since the start. Seems like a proper naming and reference at the same time Having read back the entire discussion and taking into account one could always choose to add the SKOS vocabulary with 'additionalType' I have no problem resolving it this way. So +1 for EnumConcept -- One more question though: Does this also imply that properties like 'eventCategory', ' occupationalCategory' and 'others like it' will be depricated/retracted? And if not, than why not? I can't get my head around why they would need to to stay if the same can also be accomplished with 'EnumConcept'. (probable I'm overlooking something but I have no idea what that might be). On Mon, Oct 7, 2013 at 11:22 PM, Dan Brickley <danbri@danbri.org> wrote: > On 7 October 2013 21:04, Jarno van Driel <jarno@quantumspork.nl> wrote: > > Call me crazy, but I presume the folks who designed SKOS already had a > > discussion like this, isn't it therefore a bit strange to have the same > > discussion all over again. Looking at all the existing documentation > (which > > refers to 'Concept') there is, wouldn't it make the general developer's > life > > a lot easier if the naming stays the same? > > I was one of those people, and the discussions go way back. > Collaboration around an RDF vocabulary for thesauri started ~1998. > Some old notes here > > http://www.ilrt.bristol.ac.uk/publications/researchreport/rr1011/report_html?ilrtyear=00 > though I remember discussing the issue of "when do we model hierarchy > as RDF types, and when broader/narrower?" with Traugott Koch at > http://www7.scu.edu.au/00/ and in the RDFS WG of the day. These and > other (e.g. http://www.w3.org/TandS/QL/QL98/pp/queryservice.html also > LIMBER project) experiments and implementations fed the later > SWAD-Europe project work > http://www.w3.org/2001/sw/Europe/plan/workpackages/live/esw-wp-8.html > where we set up http://lists.w3.org/Archives/Public/public-esw-thes/ > in 2003. Alistair Miles then did an fine job building a community > around the idea and turning vague ideas into a solid spec. Then two > successive W3C groups published SKOS first as a Note, then as a W3C > REC. A lot of work (e.g. see > http://www.w3.org/2006/07/SWD/track/issues/ > http://www.w3.org/2004/02/skos/requirements ) went into standardizing > SKOS. Nothing we do should be so careless as to give the impression > we're tearing things up and starting again. > > The point of our current exercise is to combine SKOS's presence in the > public sector, Libraries/Archives/Museums/Galleries and thesaurus > world, with Schema.org's (and Drupal et al.'s...) presence in the > mainstream mass-market Web. > > For that reason I find 'EnumConcept' a bit ugly but bearable. It > contains the word "Concept", tying it to the SKOS history and > documentation. And the word 'Enum' (for > http://schema.org/Enumeration), which has been part of schema.org's > model since the start. So it somehow embody's the link between skos > and schema.org that we're trying to create. The fact that EnumConcept > is ugly can even work in its favour. One issue with types that have > 'obvious' names is that people rarely feel compelled to consult their > documentation. For 'Person', that's probably just fine; but in this > case, a look at the documentation is probably rather useful. > > > That way there are a lot of resources one can use, instead of yet another > > property which more or less does the same. In my opinion that would only > add > > to the confusion. > > Let's make sure to keep a strong link to SKOS terminology and > documentation, even if we don't call the class 'Concept'. > > > On Mon, Oct 7, 2013 at 9:56 PM, Evain, Jean-Pierre <evain@ebu.ch> wrote: > >> > >> EnumConcept could pass. > > >> From: Thad Guidry [mailto:thadguidry@gmail.com] > [...] > >> It does not HAVE to be called SkosConcept... but as long as the > definition > >> shows it's origin and that Broader & Narrower among others, are part of > the > >> bargain, then I think all web developers will easily comprehend what you > >> mean and what neat interconnections they can bring to expand knowledge > and > >> organize directed Search queries even more. > >> > >> +1 for EnumConcept and I also saw the tie in to > >> http://schema.org/Enumeration ( "Named" does not help signify that > basic > >> "organization" feeling that SKOS is all about....Knowledge > Organization.... > >> but Enumeration or Enum does.) > >> > >> -Thad > > Can anyone here _not_ live with EnumConcept, given the various > constraints and viewpoints expressed so far? > > Dan >
Received on Monday, 7 October 2013 22:56:13 UTC