Re: SKOS for schema.org proposal for discussion

On 8 October 2013 11:57, Bernard Vatant <bernard.vatant@mondeca.com> wrote:
> Hi all
>
> 2013/10/8 Ed Summers <ehs@pobox.com>
>>
>> I guess I missed an earlier conversation about this, but why do folks
>> want to import SKOS into schema.org? Can't they just use SKOS as is in
>> their HTML using RDFa or Microdata? Is the expectation that putting it
>> into schema.org will make it more likely to be used by both Web
>> publishers and consumers (crawlers, etc)?
>
>
> I have the same feeling. SKOS was developed to enable migration of library
> KOS legacy (thesaurus, classifications) to the Semantic Web, whereas
> schema.org has a completely different story and focus, which is making web
> content better readable by search engines. Neither protagonists in this
> story (Web developers and search engines) are librarians.

I respectfully disagree with the claim that these are entirely
different ventures.

We created SKOS at W3C, as you say, to bring existing knowledge
organization systems into the Web using simple, practical RDF. But we
did that for a reason not as an end in itself.

Schema.org is very much in that tradition of simple practical RDF
roll-out. More importantly, the materials you call "library KOS
legacy" were never themselves the ultimate goal - they always should
be seen as a means to an end --- putting people in touch with
information. Although SKOS does not yet deal perfectly with the
compositional structures of subject classification, I believe the
SemWeb community should be very proud that both UDC (see
http://udcdata.info/) and Dewey
(http://oclc.org/developer/documentation/dewey-web-services/using-api)
are available in SKOS-based RDF linked data form. Revisiting
http://en.wikipedia.org/wiki/Universal_Decimal_Classification and
http://en.wikipedia.org/wiki/Dewey_Decimal_Classification should
remind us that such systems served a larger purpose. Simply dumping a
thesaurus or classification scheme into the Web in RDF is not a
particularly ambitious goal, although of course data portability
between software systems is always useful. Bringing those
information-organizing structures into the daily lives of millions or
billions of ordinary Web users, ... now that is a much more
interesting goal - and a point at which schema.org goals echo the much
earlier ambitions that brought us the likes of UDC and Dewey in the
first place.

I've talked about that at length elsewhere - slides/video here
http://danbri.org/words/2012/07/18/793 - so I won't go on about it
here. Obviously there are differences of emphasis, mechanism and style
between library-oriented KOS and schema.org, but there's also a shared
agenda and heritage that pre-dates computing such as
http://en.wikipedia.org/wiki/Mundaneum

>> In general I agree with Guha that skos:Concept seems pretty close to
>> Resource, or really, schema:Thing.

And skos:Concept is indeed quite general, since it is an indirection
mechanism. For any entity, you can have the concept/idea/topic of it.

> Representing something as a skos:Concept is just a librarian trick to use
> this thing for indexing, classification, search and retrieval etc. Nothing
> is a skos:Concept before you look at it with librarian glasses, and if you
> put those glasses on, everything can be. Remember endless discussions a
> while ago about Michelle Obama being a concept or not. And the way for
> example VIAF deals with this is OK in library world, with "authorities"
> being represented both as e.g., foaf:Person and skos:Concept, linked by
> foaf:focus, see e.g., http://viaf.org/viaf/9847974/rdf.xml

Yes - 'focus' could easily have been part of SKOS, but there are some
slippery points to the design so we ended up with it in the scruffier
FOAF vocabulary.

> Obviously schema.org does not need to go down those alleys, if you want to
> say you speak about a Person you use schema.org/Person and you're done. What
> is lacking in schema.org are not SKOS artifacts for librarians, but ways to
> indicate topics which do no fall neatly in real-world types schema.org is
> typically about, such as cars, books, restaurants ...
> Mainly the need is to express things that are "intangible topics", more or
> less.
>
> Hence, why not simply define a subclass of schema.org/Intangible called
> schema.org/Topic for concepts (so to speak) such as democracy, friendship,
> anger, hunger, inflation, disagreement ... which have not yet found a better
> place elsewhere in the schema. Maybe at some point will be introduced
> schema.org/Feeling or schema.org/EconomicConcept and some of those "topics"
> will find a better place.

I'd like it to be simple enough in the sense of "anything that is a
skos:Concept is also a schema.org XYZ". Saying that schema.org/Topic
isn't a full subclass of skos:Concept puts us in the unenviable
position of having to say which skos:Concepts are *not* in the
schema.org class. Saying they're the same is much simpler.

>> For example, if I squint enough,
>> schema.org starts looking like a skos:conceptScheme. One of the things
>> I liked about schema.org initially was its concreteness.
>
>
> Indeed, that's why I like Topic which seems more "concrete" than Concept

If we could time travel back to 2004 and fix skos to use Topic, I'd be
happy. And I could live with Topic now, though it does feel a bit
awkward for use with e.g. jobClassification, whereas EnumConcept is
intrinsically awkward already.

>> There are
>> lots of very plain types that people can choose to use without having
>> to think too hard about them. I personally don't think giving people
>> machinery to start saying abstract things about concepts is going to
>> be terribly fruitful.
>
>
> +1

Let's keep clear about which people we have in mind, maybe? There are
a lot of different potential roles and publishers. e.g. in an rNews
setting, one use cases for SKOS-like construct is in news
organizations modeling story timelines (along lines of
http://www.bbc.co.uk/ontologies/storyline/). Having the
concepts/topics/codes be first class entities in the Web seems
worthwhile, so that new relationships can be defined against them.

Dan

Received on Tuesday, 8 October 2013 13:25:19 UTC