Re: UDEF Representation in RDF

Simon has just written probably the best primer for new folks, I have ever
read through about SKOS.  That should be put somewhere on the Wiki in some
form or fashion especially around points 1 and 2 around design decisions
and "will SKOS work for me or against me ?"

On Tue, May 8, 2012 at 3:33 PM, Simon Spero <sesuncedu@gmail.com> wrote:

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


-- 
-Thad
http://www.freebase.com/view/en/thad_guidry