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

[Kristen James Eberlein <kris@eberleinconsulting.com>]

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 <gemerso1=icloud.com@groups.io>
Reply-To:	main@dita-users.groups.io
To:	main@dita-users.groups.io

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 <kris@eberleinconsulting.com> 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

gemerso1@icloud.com

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 [kris@eberleinconsulting.com]

_._,_._,_