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

Re: SKOS for schema.org proposal for discussion

From: Dan Brickley <danbri@google.com>
Date: Tue, 8 Oct 2013 08:58:15 +0100
Message-ID: <CAK-qy=6ELTCnqefM_wSc2MH_WWEY6iVHygKjGyV4X1dfBcTDJw@mail.gmail.com>
To: Niklas Lindström <lindstream@gmail.com>
Cc: Dan Brickley <danbri@danbri.org>, Jarno van Driel <jarno@quantumspork.nl>, "Evain, Jean-Pierre" <evain@ebu.ch>, Thad Guidry <thadguidry@gmail.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>
On 8 October 2013 00:42, Niklas Lindström <lindstream@gmail.com> wrote:
> Hi,
> On Mon, Oct 7, 2013 at 11:22 PM, Dan Brickley <danbri@danbri.org> wrote:
>> > 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'.
> Does that mean linking this new schema.org class to skos:Concept using
> rdfs:subClassOf or owl:equivalentClass? I'd really like that. :)

I don't see why we wouldn't do that. The RDFS++-- configuration file
(that's a made up technical term) for Dataset vocabulary already has
similar, for example. See
... though it needs exposing in the actual site too.

>> > 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?
> Although I'm quite supportive of "just use Concept", I have found it a bit
> odd that it (skos:Concept) actually means something more artificial than the
> name implies (being the managed notion within a scheme, having
> dcterms:created dates and such, and being correlated to things using
> foaf:focus). So I definitely sympathize with your reasoning and objective.
> (I could possibly go for Topic as well – the relationship between SKOS and
> Topic Maps has certainly struck me at times).

Yes, Topic Maps tried to simultaneously match the capabilities of the
RDF, RDF/XML and SKOS. The more layered approach of RDF eventually
became more popular.

> But to be clear: would an EnumConcept be a *part of* an Enumeration (the
> latter then, as previously suggested, being related to ConceptScheme)? Or
> would it *be* an Enumeration? Which then itself, just as e.g.
> BookFormatType, has *instances* – instead of "narrower" terms? I would have
> expected skos:Concept to be more equivalent to just Intangible in general.

The former, I'd say. e.g. "An enumerated concept is a concept named,
described and enumerated as part of an enumeration scheme. In the
simplest case, a short list of items; in other cases, a complex
hierarchically structured network that can be professionally managed
over several decades." I don't think this answers all the questions,
but for schema.org integration, this is the right discussion to be
having. Otherwise we'll end up with two similar-but-different
mechanisms with overlapping use cases.

Q: are there any instances of Enumerations that are not also instances
of (Enum)Concept? e.g. we already have http://schema.org/Hardcover
which is an instance of BookFormatType(*), a subtype of Enumeration.
Do we use SKOS-like (Enum)Concept here too?


(*) Karen has already pointed out that this is not the finest piece of
modeling w.r.t. realities of book formats, but perhaps we can set that
aside for now? Or perhaps the ability to use an externally enumerated
scheme here is quite relevant...
Received on Tuesday, 8 October 2013 07:58:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:49:13 UTC