Fwd: UDEF Representation in RDF

On Tue, May 8, 2012 at 5:04 AM, Chris Harding <c.harding@opengroup.org>wrote:

>
> We are looking at an approach that would define UDEF object classes and
> UDEF properties as SKOS concepts, and use SKOS narrower/broader to capture
> the relation between a parent object class and its children, and between a
> parent property and its children.
>
> The initial questions that we have are:
>    - Does this look like a sensible approach?
>    - Should we make the whole of the UDEF a single SKOS concept scheme, or
> would it be better
>      to have separate concept schemes for object classes and properties?
>

I am not entirely sure that using SKOS would necessarily be the most
appropriate way of increasing the semantic richness for what seem to be
UDEF's target applications. Here are some considerations  that might help
you decide whether a purely SKOS based approach is ideal for your needs, or
whether RDF(S) + OWL might be a better approach.


   1. SKOS was originally developed for representing knowledge
*organizing* systems,
   not knowledge *representation* systems; that is, it was designed to
   represent the relationship between ideas, not between the things that those
   ideas are about.  A good test to see if SKOS is right for your application
   is to consider whether in your application there is ever any difference
   between something being *a kind of* something else, and something being *a
   part of * something else.
   2. SKOS does not have a standardized way of expressing sequences of
   concepts, for generating concatenated notations, or for expressing
   restrictions on the types of concepts that can be used to restrict what
   concepts could follow what other concepts.  This essentially forces UDEF to
   be a fully enumerated system, which may not be ideal.
   3. The example used on the the UDEF
CONOP<http://www.opengroup.org/udef/use/conops.htm>page involves a
sample interaction with the DLA (Defense Logistics Agency).
    That ( and fact that the overview page is titled "Concept of Operation" :)
    suggests that interworking with DoD and other government agencies is an
   important consideration.  DoD semantic interoperability and federation work
   is using OWL/RDF as a basis - see these
slides<http://www.dodenterprisearchitecture.org/program/Documents/1015%20DWiz_DCMO_EAConf_Wednesday_May_2.pdf>
    by Dennis Wisnosky <Dennis.Wisnosky@osd+mil>   (DoD BMA CTO & Chief
   Architect)  from last week's DoD Enterprise Architecture conference.
   4. Earlier work at USAF in the EVT under SAF-US(M) revealed that even
   RDF(S) + OWL was insufficient to capture all useful information for most
   Communities of Interest;  the weaker semantics of SKOS would presumably be
   able to capture even less information.  (Interestingly, the acronym EVT
   stood for "Enterprise Vocabulary Team"; the V was obsolete  even  before
   the team was stood up).
   5. Where a natural language term has different meanings in different
   CoIs, it is a very bad idea to try and force the subject matter experts in
   one or both areas  to use a different term.  Performance level of subject
   matter experts is degraded to a level close to novices.

Taking a look at some of the UDEF definitions seems to suggest that the
current definitions do not include much information that could be
considered essential for interoperability.

  For example, in the "identifier" sub tree, we find the following terminal
node.

  *4.35.8* Air-Force.Assigned.Identifier

         *1.4.35.8* United-States.Air-Force.Assigned.Identifier

Given the number of different USAF identifiers, this is somewhat
problematic,  and would seem to be based on an unnamed specific use case.

In terms of mapping to RDF(S)/OWL/SKOS,  these properties would seem to
imply a hierarchy  - SubPropertyOf in RDFS, SubDataPropertyOf in OWL,
broader in SKOS.

 In terms of  creating interoperable systems, it is hard to understand what
the semantics of these properties would be.

What would it mean to have a data field tagged "4.35.8"?
Could it be meaningfully compared to another data field tagged "4.35.8"?
Could you join two records from different sources using this field?
Could you join two records, one identified by a  "1.4.35.8", the other
by "4.35.8"?

Is the  relationship between the fields strictly one of about-ness;
everything that is in some way about
a United-States.Air-Force.Assigned.Identifier it is in somewhat about
an Air-Force.Assigned.Identifier?

It well be that some many of the unique labels that UDEF has created can be
usefully refactored into their semantic components, and that by doing so it
becomes easier to create federate systems of systems that work at the
enterprise scale and beyond.

 Simon