W3C home > Mailing lists > Public > public-vocabs@w3.org > October 2013

Re: SKOS for schema.org proposal for discussion

From: Jarno van Driel <jarno@quantumspork.nl>
Date: Tue, 8 Oct 2013 00:55:45 +0200
Message-ID: <CAFQgrbYj+78_ZpLCh-F26ts=-+1fBC35SaQMwjd3iASYrwonJw@mail.gmail.com>
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>
> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:32 UTC