Re: SKOS for schema.org proposal for discussion

On 7 October 2013 23:55, Jarno van Driel <jarno@quantumspork.nl> wrote:
>> 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

Thanks

> 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).

EnumConcept is a type, whereas occupationalCategory and eventCategory
are properties. In this case, EnumConcept could describe one possible
type for the values of these properties.

Using Library of Congress Subject Headings as an example,

We could describe an upcoming Event as having an eventCategory which
was the (Enum)Concept described in
http://id.loc.gov/authorities/subjects/sh85133937.html ... labelled
"Tensor algebra", or
http://id.loc.gov/authorities/subjects/sh85108275.html
"Psuedoinverses".

... and we could describe an occupationalCategory with the
(Enum)Concept http://id.loc.gov/authorities/subjects/sh85003441.html
"Linear algebras".

If these were old-style simple schema.org strings, the connection all
these is not so obvious. But if we model them as inter-related
concepts, we can see that the first two share a common broader
concept...

Dan

Received on Monday, 7 October 2013 23:22:37 UTC