dita — archive

Fwd: [dita-users] Use of subjectScheme OTHER than for controlled values

From: Kristen Eberlein
To: [email protected]
Date: Thu, 16 Dec 2021 14:22:00 -0000

For our consideration. Best, Kris -------- Forwarded Message -------- Subject: Re: [dita-users] Use of subjectScheme OTHER than for controlled values Date: Wed, 15 Dec 2021 10:44:13 -0600 From: glenn emerson via groups.io <[email protected]> Reply-To: [email protected] To: [email protected] Kris, I have always been disappointed that these elements have not had greater adoption by sophisticated processing tools. I think that OWL and SKOS beat SubjectScheme to the proverbial table and got adopted first. Many tools use SKOS or OWL. However, there is no common standard. Increasingly, I see different tools in a solution architecture using different standards for representing the same taxonomy or ontology. The ability to create equivalence relationships between terms is critical to building a thesaurus. The has elements are powerful for building classes. Here is the problem I see. One delivery tool uses OWL. A CMS in the same solution architecture uses SKOS. Or the CMS uses subject scheme for taxonomy, but the delivery tool doesn t understand subject scheme. To further complicate, Google has its schema.org model and Facebook has Opengraph, etc. so content that may be shared to those platforms need to use those models. So, in essence, there are multiple standards in play in a solution space. To manage a taxonomy, I might have to encode the same taxonomy differently, using different standards, on each tool in the solution. What I think is needed is a way to create a taxonomy (or ontology) sole-source of truth, from which the specific configuration files for the various tools in the chain can be created. In this way, a taxonomy can be centrally managed in one place, then rendered to platform specific outputs. This greatly reduces the work of creating and testing various configurations manually, each time there is an organization taxonomy update. I think subjectscheme has this potential. But if the ability to create term equivalence relationships, and class modeling, are removed, then the best subject scheme can hope to be is a list of nested terms. There is a growing usage of semantic navigation. I think in the DITA space, there needs to be a way to create a sole-source-of-truth for that semantic model, to which an XSL can be applied to render a platform specific output. I d vote to leave it as is. Do not dumb it down. $.02, Glenn Emerson On Dec 10, 2021, at 6:38 AM, Kristen James Eberlein < [email protected] > wrote: Hi -- The DITA TC wants to find out who is using the subjectScheme map for uses OTHER than controlled values for attributes. Is your implementation doing that? We are considering whether to remove the following from the standard: The has elements: <hasInstance>, <hasKind>, <hasNarrower>, <hasPart>, <hasRelated>, and <relatedSubjects>. The subject relationship table: A specialized relationship table designed to define relationships between subjects The has elements elements were designed to enable information architects to specify more precise relationships in a subjectScheme map than that provided by the hierarchies of <subjectdef> elements. This was supposedly argely for the benefit of sophisticated processing tools. Well, sophisticated processing tools have not arrived, and the DITA specification never discussed what processors should do with this markup. So, these elements largely bloat the subjectScheme map, and practitioners spend time constraining them of subjectScheme. The subject relationship table has a bizarre design that does not mirror reltable. Again, the DITA specification never discussed any processing expectations for this. -- Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee ______________________________ Glenn Emerson [email protected] 585-732-6984 _._,_._,_ Groups.io Links: You receive all messages sent to this group. View/Reply Online (#46637) Reply To Group Reply To Sender Mute This Topic New Topic Your Subscription Contact Group Owner Unsubscribe [ [email protected] ] _._,_._,_