Re: Should we adopt SKOS?

On 9 Jan 2013 20:26, "Jason Douglas" <jasondouglas@google.com> wrote:
>
> I rescind my earlier comment in the sense that we do want everything to
have a name, description, url, etc. so it makes practical sense to have
everything inherit from Thing to get those properties.

Yes, let's keep Thing as the class of *all* things.

I am a little wary of Category as a name since it is more likely to be
mixed with Type; eg. Thad's description below seems also to describe our
existing typing notion.

A category/topic in this SKOSlike sense is an identified entity typically
used to characterise the subject / topical coverage of a CreativeWork, but
could also be used to indicate skills and abilities eg in CV/resume,
JobPosting; or descriptions of learning resources. Recipies, Software Apps,
Geospatial entitied and TV shows (amongst countless others) often get coded
using domain specific, simple hierarchical lists.

We want to encourage the use of such coding in schema.org markup, and it
would probably be good to show some examples of these 'externally
enumerated' topic/category schemes being published as Rdfa Lite so they can
be presented using both skos and schema.org vocab.

Many SKOS schemes encode Thesauri; it is hard to see these items as
categories. Even as topics is a stretch. Also 'topic' has specific meaning
in Freebase, perhaps halfway between Skos 'Concept' and Rdf/rdfs 'Class'?

Sometimes the hardest thing with schemas is finding the right word....

Dan

>
> -jason
>
>
>
> On Wed, Jan 9, 2013 at 11:23 AM, Thad Guidry <thadguidry@gmail.com> wrote:
>>
>> I differ and think that there is a need for these 3 at the highest level:
>>
>> Category - A grouping of Things, or Topics.
>> Thing - we have it already, and which is sometimes placed in Categories.
>> Topic - where Concept, Ideas, etc. hold and are rarely placed in
Categories.
>>
>>
>>
>> On Wed, Jan 9, 2013 at 12:31 PM, Guha <guha@google.com> wrote:
>>>
>>> Category should be a subClassOf Thing.
>>>
>>> guha
>>>
>>>
>>> On Wed, Jan 9, 2013 at 10:28 AM, Jason Douglas <jasondouglas@google.com>
wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Jan 9, 2013 at 10:00 AM, Dan Brickley <danbri@danbri.org>
wrote:
>>>>>
>>>>> +Cc: Jamie
>>>>>
>>>>> On 9 January 2013 16:29, Richard Wallis <richard.wallis@oclc.org>
wrote:
>>>>> > Coming from the bibliographic world, specifically chairing  the
Schema Bib
>>>>> > Extend Group[1] (who are building a consensus around a group of
proposals
>>>>> > for Schema.org extensions for bibliographic resources, before
submitting
>>>>> > them to this group), I am identifying situations where being able
to model
>>>>> > things as SKOS[2] Concepts held in ConceptSchemes would make a
great deal of
>>>>> > sense.
>>>>> >
>>>>> > Working with colleagues we were finding ourselves almost
reinventing the
>>>>> > SKOS model in [proposed] Schema.org vocabulary.
>>>>> >
>>>>> > The introduction of External Enumerations[2] provided the ability
to link to
>>>>> > lists of things controlled by external authorities.  An approach
used widely
>>>>> > in the bibliographic and other domains – Library of Congress Subject
>>>>> > Headings[4] for example.  Many of these authorities are modelled
using SKOS
>>>>> > (Concepts within ConceptSchemes) which introduces a consistent
structured
>>>>> > way to describe relationships (broader/narrower), language specific
>>>>> > preferred labels, etc.
>>>>> >
>>>>> > Sub-typing Intangible for Concept and ConceptScheme, it would be
>>>>> > comparatively easy to introduce SKOS into Schema.  The benefits I
believe
>>>>> > being to add even more value to External Enumeration; providing a
flexible
>>>>> > simple-ish yet standard pattern for marking up lists of concepts
and their
>>>>> > interrelationships; provide a very easy way for already published
>>>>> > authoritative lists of concepts to adopt Schema.org and provide
valuable
>>>>> > resources for all to connect with.
>>>>> >
>>>>> > For instance VIAF[4] the Virtual International Authority File, a
well used
>>>>> > source of URIs and authoritative names for people and organisations
>>>>> > (compiled and managed by the bibliographic community but used
widely) is
>>>>> > already in SKOS.  SKOS is also used in many other domains.
>>>>> >
>>>>> > I could see this adding value without significant impact on the
rest of
>>>>> > Schema.
>>>>> >
>>>>> > What do others think?
>>>>>
>>>>> I've been thinking in this direction too (and had brief discussion
>>>>> with Jamie, cc:'d, w.r.t. Freebase's approach).
>>>>>
>>>>> SKOS has done well and a great many controlled vocabularies in the
>>>>> thesauri, subject classification and code list tradition are expressed
>>>>> using it. SKOS handles various cases where 'class/object/property'
>>>>> models don't capture things well. I'd like to have a way of reflecting
>>>>> SKOS-oriented data into schema.org descriptions without going
>>>>> 'multi-namespace'. There are also already various corners of
>>>>> schema.org where different loose notions of 'category' are slipping
>>>>> in.
>>>>>
>>>>> My current preference would be to call a new type "Topic" or perhaps
>>>>> "Category" rather than the more esoteric / vague "Concept", even while
>>>>> borrowing most structure and terminology from SKOS.
>>>>
>>>>
>>>> +1 to a top-level, independent peer to Thing for this.  While Category
might not be the most precise term for these, it has the advantage of being
very clearly distinct from Thing -- and I worry that Topic and Concept
aren't.
>>>>
>>>>>
>>>>> Do you have a strawman list of what you'd hope to include, from a
>>>>> bibliographic perspective?
>>>>>
>>>>> Dan
>>>>>
>>>>> > ~Richard
>>>>> >
>>>>> > --
>>>>> > Richard Wallis
>>>>> > Technology Evangelist
>>>>> > OCLC
>>>>> >
>>>>> >
>>>>> >
>>>>> > [1] http://www.w3.org/community/schemabibex/
>>>>> > [2] http://www.w3.org/TR/skos-reference/
>>>>> > [3] http://www.w3.org/wiki/WebSchemas/ExternalEnumerations
>>>>> > [4] http://id.loc.gov/authorities/subjects.html
>>>>> >
>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> -Thad
>> http://www.freebase.com/view/en/thad_guidry
>
>

Received on Wednesday, 9 January 2013 21:18:35 UTC