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

RE: SKOS for schema.org proposal for discussion

From: Evain, Jean-Pierre <evain@ebu.ch>
Date: Tue, 29 Oct 2013 11:04:40 +0000
To: "'Young,Jeff (OR)'" <jyoung@oclc.org>, Kingsley Idehen <kidehen@openlinksw.com>
CC: "public-vocabs@w3.org" <public-vocabs@w3.org>
Message-ID: <A71D9E70FCEE5E40A5EAA598864E605705E26ECD@maildrs.gva.ebu.ch>
-1 for Topic

From: Young,Jeff (OR) [mailto:jyoung@oclc.org]
Sent: dimanche, 27. octobre 2013 23:22
To: Kingsley Idehen
Cc: public-vocabs@w3.org
Subject: Re: SKOS for schema.org proposal for discussion

+1 for Topic.

There is a little bit of weirdness I mentioned in relation to the schema:about property, but I agree that Concept is too broad and EnumConcept is too artificial.

Jeff

Sent from my iPad

On Oct 27, 2013, at 5:43 PM, "Kingsley Idehen" <kidehen@openlinksw.com<mailto:kidehen@openlinksw.com>> wrote:
On 10/27/13 12:17 PM, Guha wrote:
Topic sounds good. Avoids the problems that Concept introduces and is also general enough.

Any thoughts on this?

+1 for Topic .

Kingsley


guha

On Sun, Oct 27, 2013 at 8:31 AM, Karen Coyle <kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net>> wrote:
Guha, it looks to me like schema has tried hard to use terms that are as close to natural language as can be, even when those turn out to be awkwardly long: isAccessoryOrSparePartFor. EnumConcept is not immediately understandable as it is, and I cannot find any other property that uses this kind of "non-real word/world" naming.

Other suggestions (some which have been posted here) are:

topic
concept
conceptList
topicList
termList
etc.

I would greatly encourage the use of natural language terms.

kc



On 10/26/13 2:07 PM, Guha wrote:
Reviving the thread ...

Schema.org<http://Schema.org> already uses Enumeration in the unordered sense. So, could
you live with EnumConcept?

guha


On Sun, Oct 20, 2013 at 7:25 AM, Antoine Isaac <aisaac@few.vu.nl<mailto:aisaac@few.vu.nl>
<mailto:aisaac@few.vu.nl<mailto:aisaac@few.vu.nl>>> wrote:

    Hi,

    Interesting that the topic has been stalled for one week, especially
    in the middle of a discussion on naming ;-). It looks like it will
    end like earlier SKOS threads, which also lead to discussion on the
    general strategy for schema.org<http://schema.org> <http://schema.org> or this list [1]...


    OK, if applications need to publish or consume concept-level data,
    we can point them to RDFa+SKOS. But if some here prefers to use the
    schema.org<http://schema.org> <http://schema.org> namespace, we can't really say it's

    wrong. Especially when better-known ontologies have been already
    integrated into Schema.org<http://Schema.org>. The discussion should have happened for
    FOAF and GR. And if it happens now, still, it should have a broader
    scope than SKOS!

    I also hear the point that relying on SKOS-like data is less good
    than trying to categorize 'concepts', so that they fit various
    schema.org<http://schema.org> <http://schema.org> classes (Person, Place, etc). Again

    this debate has already happened, in a way.
    If a good, clean ontologization of thesauri, folksonomies etc was
    possible (ie., if people had resources for it), then there wouldn't
    be any need for SKOS in the first place, in the Semantic Web /
    Linked Data ecosystem.
    Besides the logical pitfalls of shoehorning SKOS data into OWL
    ontologies, there's the problem of raising the barrier to the use of
    data. A range of simple applications like the one Stéphanes has
    presented don't need fully-fleged ontologies, or, here, fine-grained
    instances of schema.org<http://schema.org> <http://schema.org>'s 'concrete' classes.



    To come back to the naming...
    SKOS was partly designed to reflect the shift to 'traditional'
    term-based knowledge organization systems to more 'conceptual' ones
    (a shift examplified by more recent thesaurus standard). As
    Jean-Pierre said, the whole point is having string and terms
    masquerading as something more structured. Having skos:Concept
    mapped to a schema:Term or anything that prominently feature 'term'
    will be harmful in this respect.

    "Topic" may be counter-intuitive for all the cases when the
    resources are not used as subjects of documents.

    Using 'concept' does not seem so harmful to me, in fact. I don't see
    how the general schema.org<http://schema.org> <http://schema.org> users could possibly

    live and breath by early DL work and CommonKADS...
    'EnumConcept' carries a meaning of ordered listing I'm not
    comfortable with. But if Enumeration has been already used without
    that sense in schema.org<http://schema.org> <http://schema.org>, it may well fly.


    If you are really desperate for another one, how about 'category'?

    Best,

    Antoine

    [1]
    http://lists.w3.org/Archives/__Public/public-vocabs/2013Jan/__0033.html
    <http://lists.w3.org/Archives/Public/public-vocabs/2013Jan/0033.html>






--
Karen Coyle
kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net> http://kcoyle.net
m: 1-510-435-8234<tel:1-510-435-8234>
skype: kcoylenet





--



Regards,



Kingsley Idehen

Founder & CEO

OpenLink Software

Company Web: http://www.openlinksw.com

Personal Weblog: http://www.openlinksw.com/blog/~kidehen

Twitter/Identi.ca<http://Identi.ca> handle: @kidehen

Google+ Profile: https://plus.google.com/112399767740508618350/about

LinkedIn Profile: http://www.linkedin.com/in/kidehen








------------------------------------------------------------------------------

**************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please notify the system manager. This footnote also confirms that this email message has been swept by the mailgateway
**************************************************
Received on Tuesday, 29 October 2013 11:05:35 UTC

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