- From: Dan Brickley <danbri@google.com>
- Date: Mon, 7 Oct 2013 20:41:52 +0100
- To: Guha <guha@google.com>
- Cc: Martin Hepp <martin.hepp@ebusiness-unibw.org>, Stéphane Corlosquet <scorlosquet@gmail.com>, Dan Brickley <danbri@danbri.org>, jean delahousse <delahousse.jean@gmail.com>, "public-vocabs@w3.org" <public-vocabs@w3.org>
On 7 October 2013 18:52, Guha <guha@google.com> wrote: > It was a precursor to what is now the Description logic community. > > Look at this for example. I believe CommonKADS also used 'Concept' as a basic representational primitive http://www.slideshare.net/guest3bd2a12/a-introduction-to-common-kads-presentation I had the same reaction to SkosConcept: this is backdoor namespaces. At least in an RDFa 1.1 setting we already have skos: prefix and other major namspace prefixes pre-bound to their URIs, so typeof="skos:Concept" doesn't need the full URL. As for "Concept", one of the reasons I didn't push for it to be called 'Topic' at the ~2003/4 time was just pragmatism: the Topic Maps standard was more active then, and it would have seemed hostile. I don't think that's an issue now. It was always an awkward name. >From my point of view, it is important that we are respectful of the work that has gone into the creation and deployment of SKOS around W3C. But I don't think that ties our hands to necessarily name everything exactly as in SKOS. The BibExtend group, for example, have been coming to terms with the idea that in schema.org a book's 'title' is called its 'name'. The (professional-information-management-people) community around SKOS are also perfectly capable of adapting to the idea of writing 'name' instead of 'prefLabel' when data flows from SKOS into schema.org-oriented environments. I'd say there are probably just a few thousand people on this planet who understand the important and role of SKOS. Schema.org reaches a vastly larger audience and it is reasonable for us to tune the terminology to that diverse audience's names, so that the *ideas* behind SKOS and earlier KR initiatives finally go mass-market, even if their specific terminological choices don't. I could live with http://schema.org/Concept or /Topic and I could live with personally telephoning KR professors and/or Thesaurus experts to apologise for naming clashes, but let's try something else first: Proposal: http://schema.org/EnumConcept [ or NamedConcept or ...] An EnumConcept is an intangible schema.org thing that represents a topic, category, subject code or classification, typically drawn from an organized collection of inter-related concepts. By naming, identifying and describing these 'enumerated concepts' we can integrate a variety of standards for encoding lists, taxonomies, and controlled values. Instances of EnumConcept are also instances of W3C's SKOS 'Concept' type (and vice-versa), allowing widely used thesauri and subject classification systems to be (at least partially) represented within the schema.org system. Enumerated concept schemes are also useful for example in describing the [occupationalCategory] of a [JobPosting], where simple hierarchical structure in a job codes list can be made machine-accessible. Another schema.org use is in describing educational resources, where the targetUrl of an AlignmentObject describing e.g. an educational VideoObject could refer to an EnumConcept indicating some standard educational achievement or topic code. Again the use of these richer, interconnected enumerations (rather than simple strings or more basic Enumerations) allows machines easier access to the otherwise hidden relationships amongst possible property values. The advantage of using an EnumConcept over simple string values (or a less structured simple Enumeration) is that we can now exploit broader/narrower hierarchies, give alternate labels, multilingual translations etc. ... could something like that work? i.e. try to tie it in to our story around http://schema.org/Enumeration ? Dan
Received on Monday, 7 October 2013 19:42:21 UTC