Re: When to use has_broader_match?

>
>  I see that Antoine made the same point on another thread but will send
> this off anyway...


I'm glad you did. It helps to hear the same thing from different
perspectives and what you said further clarified my understanding. Just
FYI, two things I really liked about what you said (at least assuming I
understood correctly):

1) It seems to be a very pragmatic approach which doesn't get too hung up
on formal issues. I love formal stuff but for real world work I find a
pragmatic approach makes more sense.

2) The emphasis on an iterative approach. This is one issue where I
disagree with many of my colleagues within the OWL community. They seem to
be wedded to the Waterfall Model. In my career the one thing I feel that
I've seen without fail going back to the 1980's is that the Waterfall model
never works as well as the iterative model, specifically I practice Agile
as much as possible.

I'd be interested to hear more about what you mean by "pun every class". It
> does not formally contradict the SKOS data model if a SKOS concept is also
> declared to be an OWL class, and I do not see how the reverse could be a
> problem.


It's not a problem for SKOS but it's a problem for OWL. If you directly
make an OWL class also an instance of some other OWL class such as
skos:Concept that puts you into OWL Full and no reasoner can support it.
OWL without a reasoner is severely limited IMO. Of course that is why
punning was invented.

I'm not following... The other property would be rdfs:subPropertyOf
> skos:broader?


Sorry, I wasn't clear. And this isn't from a real use case, just me trying
to imagine all possible uses of SKOS.  Properties in OWL are of course
relations in set theory, i.e., sets of sets and so when you have a property
hierarchy you are really describing a subsumption hierarchy just as you do
with a class hierarchy (the set defined by a super property is a super set
of the set defined by its sub-property).  Hence it seems to me you could
describe an OWL property hierarchy with skos:broader and skos:narrower as
well. Also, you can pun properties. I almost never pun properties except
for R&D things that get very meta and I can't imagine a use case where I
would want to use SKOS on property hierarchies but I was just thinking
through all possible uses. BTW, from the standpoint of OWL this would be
easy to do since the pun for a property is an individual and could be made
an instance of skos:Concept just as the puns for an OWL class.

By your reasoning, might one argue that OWL, which models the world in
> terms of mathematical sets, is even more like paddling against that tide?


I definitely get the point that  Christophe  was making. For years I was
telling colleagues in industry about OWL and how they should be using it to
organize their data and the reaction was (I'm paraphrasing of course) "Why
should we worry about making our data more logical when we can just run ML
algorithms on it?" Then Google wrote what IMO is one of the most
influential two page articles ever
<https://www.blog.google/products/search/introducing-knowledge-graph-things-not/>where
one of their tech VPs coined the term "knowledge graph" and suddenly
everyone was jumping on the bandwagon. In my (very limited) experience one
of the most popular use cases is for data catalogs and data governance.
This is becoming an ever more important issue as companies see their data
as strategic assets that they want to manage carefully, determine the
business owners and users for specific data, and as they need to worry
about new legislation like the EU's GDPR
<https://gdpr.eu/what-is-gdpr/?cn-reloaded=1>. I agree it is still an
uphill battle with OWL. Many people stick to just graph databases (RDF or
Property Graphs). I actually think Jim Hendler (one of the co-authors with
Berners-Lee on the Scientific American Semantic Web article
<https://drive.google.com/file/d/1x6LCDXW1LmHTQ8LyPKR4DGvEWqP6d47C/view>)
developed an excellent presentation about this issue called Wither OWL?
<https://www.slideshare.net/jahendler/wither-owl>  His main point was that
while it's true that in practice people who do large scale development
often use very paired down profiles of OWL, maybe that's just fine and a
little semantics for a lot of data is still a big improvement. I also
really like a book by Dave McComb called The Data Centric Revolution
<https://www.semanticarts.com/the-data-centric-revolution/> that makes the
case for OWL in the enterprise.

Hope I didn't ramble on too long. Thanks for all the feedback guys, it has
been really helpful.

Michael
https://www.michaeldebellis.com/blog

On Fri, Jan 6, 2023 at 2:47 AM Thomas Baker <tom@tombaker.org> wrote:

> Antoine wrote:
> > 2. Maybe Michael would be interested to read the parts
> > on SKOS and OWL in the paper I cited in the other
> > thread [2]
> > [2] https://doi.org/10.1016/j.websem.2013.05.001
>
> The relevant section of that paper is "4.4 Mapping relations".
>
> Michael wrote:
> > But I don't get has_broader_match or
> > has_narrower_match. If one entity is broader or
> > narrower than the other (which I interpret as
> > super-class or super-part relations) then I don't
> > understand how they can also be matches. Similarly for
> > has_related_match.
>
> When the W3C working group that published SKOS discussed this issue, it
> acknowledged that large parts of the KOS community saw inter-KOS "mapping"
> relations and intra-KOS "semantic" relations as distinct, even disjoint.
>
> Making this distinction in SKOS, however, would have required a way to
> formally "contain" a concept scheme -- along with its semantic relations --
> as something distinct and separate from other concept schemes.
>
> SKOS was however designed to support a more fluid and dynamic sense of
> concept scheme -- as something that could evolve over time through
> aggregation or division, through including concepts from multiple
> namespaces, or through overlapping with other concept schemes. Any notion
> of making "mapping" relations formally disjoint from "semantic" relations
> was therefore off the table.
>
> Basically, the working group could see no basis for distinguishing
> "mapping" from "semantic" relations, so it fell back on admitting that the
> difference between the two was not formal in nature, but "conventional"
> (ie, nothing would actually break, in a formal sense, if a mapping were
> expressed with skos:broader instead of skos:broaderMatch, so splitting one
> concept scheme into two would not break those relations).
>
> Oops - I see that Antoine made the same point on another thread but will
> send this off anyway...
>
> Michael wrote:
> > Also, to use SKOS and not fall into OWL Full, I
> > need to pun every class I want to assert a SKOS object
> > property on.
>
> I'd be interested to hear more about what you mean by "pun every class".
> It does not formally contradict the SKOS data model if a SKOS concept is
> also declared to be an OWL class, and I do not see how the reverse could be
> a problem. According to the SKOS data model (which is itself expressed in
> OWL), there are only two things in the formal semantic universe that cannot
> be asserted to be SKOS Concepts: SKOS Collections and SKOS Concept Schemes.
> There are even vocabularies where terms are declared to be both OWL
> properties and SKOS concepts - see, for example,
> https://id.loc.gov/vocabulary/relators/act.html .
>
> Michael wrote:
> > I think I also get has_related. When two Concepts are
> > related (most likely in OWL by some property other than
> > has_Sub_Part). E.g., if Fido was an instance of the Dog
> > class and Michael has_Pet Fido then we could say that
> > Michael has_related Fido (and vice versa since
> > has_related is symmetric).
>
> skos:related is kinda like dcterms:relation or rdfs:seeAlso, only with
> skos:Concept as domain and range. The SKOS "mapping properties" support
> more specific types of relation.
>
> > And has_close_match would indicate that two entities in
> > OWL are (probably) the same entity. If they are
> > individuals then they are owl:sameAs and if class or
> > properties owl:equivalentTo each other.
>
> Not quite. skos:exactMatch is closer to the notion that the entities are
> the same because it is transitive, where skos:closeMatch is not.
>
> > Also, what about OWL properties?. I'm assuming in this
> > context has_broader means the broader property is a
> > super-property of the other property, is that correct?
> > Also, of course I would need to pun properties as well.
>
> I'm not following... The other property would be rdfs:subPropertyOf
> skos:broader?
>
> Christophe wrote:
> > "Broader" means if one (human) is interested by the
> > Broader, (s)he will be interested by this too.
>
> Another way to put it is that SKOS is designed more as a basis for query
> expansion than for inferencing.
>
> Dean Allemang made a fascinating experiment in "expressing Chebi in SKOS"
> (Semantic Web for the Working Ontologist, Second Edition, Chapter 13). When
> using SKOS in place of OWL, he concluded that "the representation is
> simpler but the query is more complex ... a common trade-off in
> representation -- does the model do more work, with a more involved
> representation, or does the query do more work?"
>
> Christophe wrote:
> > In today's world of AI digesting and classifying using
> > statistics rather than scientific models and cartesian
> > reasoning, SKOS looks like paddling against the tide
> > but... who knows !
>
> If you assume that the value of SKOS should lie in formal representation
> and reasoning, then sure. But each SKOS concept has its own word cloud of
> labels (in the case of AGROVOC, in up to 25 languages), and SKOS be used to
> train machine learning engines, eg to use with tools such as TensorFlow
> (see the excellent annif.org). By your reasoning, might one argue that
> OWL, which models the world in terms of mathematical sets, is even more
> like paddling against that tide?
>
> Tom
>
> On Fri, Jan 6, 2023 at 7:30 AM Antoine Isaac <aisaac@few.vu.nl> wrote:
>
>> Hello Michael, Christophe,
>>
>> As a complement to what Christophe says (excellent move to have tried
>> ChatGPT on this ;-) )
>>
>> 1. broadMatch, narrowMatch and relatedMatch may be especially useful to
>> link different concept schemes, when there is no exact mapping or close
>> mapping between two concepts of these schemes. See the example with
>> ex1:referenceAnimalScheme and ex2:eggLayingAnimals at [1]. This is quite a
>> made-up and extreme example, but hopefully it illustrates how two concepts
>> schemes that one may want to map, may have very different semantic grain.
>>
>> 2. Maybe Michael would be interested to read the parts on SKOS and OWL in
>> the paper I cited in the other thread [2]
>>
>> Cheers, (and Happy New Year!)
>>
>> Antoine
>>
>> [1] https://www.w3.org/TR/skos-primer/#secmapping
>> [2] https://doi.org/10.1016/j.websem.2013.05.001
>>
>>
>> On 29/12/2022 12:07, Christophe Dupriez wrote:
>> > Hi Michael and welcome in SKOS wonderland !
>> >
>> > The list will object if I am wrong. For me, SKOS is about "human made
>> for human" classification systems. "Broader" means if one (human) is
>> interested by the Broader, (s)he will be interested by this too.
>> >
>> > The "match" properties are essentially used to correlate different
>> classification systems. "Broader_Match" means if one (human) is interested
>> by the Broader_Match in (another) classification system, (s)he MAY be
>> interested by this too.
>> >
>> > In today's world of AI digesting and classifying using statistics
>> rather than scientific models and cartesian reasoning, SKOS looks like
>> paddling against the tide but... who knows !
>> >
>> > Happy New Year, it will be an interesting one !
>> >
>> > Christophe
>> >
>> > P.S. This is what ChatGPT has to say on the topic:
>> >
>> > dupriez@destin.be
>> > How would you explain the similarities and the differences between two
>> properties of the SKOS standard: "Broader" and "Broader_Match" ?
>> >
>> > SKOS (Simple Knowledge Organization System) is a standard for
>> representing thesauri, classification schemes, and other types of
>> controlled vocabulary as a set of concepts, and the relationships between
>> those concepts.
>> >
>> > The "broader" property is a relationship between two concepts in a SKOS
>> vocabulary, where the concept on which the property is applied (the
>> "narrower concept") is a more specific concept within the hierarchy of the
>> vocabulary, and the concept that is the value of the property (the "broader
>> concept") is a more general concept. This relationship indicates that the
>> narrower concept is a subclass or subcategory of the broader concept.
>> >
>> > For example, in a vocabulary about animals, the concept "dog" might
>> have the broader property with a value of "mammal," because dogs are a type
>> of mammal.
>> >
>> > The "broader_match" property is similar to the "broader" property, but
>> it is used to link a concept in one SKOS vocabulary to a broader concept in
>> another SKOS vocabulary. This can be useful when two vocabularies are being
>> used together, and there is a need to align the concepts in one vocabulary
>> with the concepts in the other vocabulary.
>> >
>> > For example, if you are using a vocabulary about animals that includes
>> the concept "dog," and you also want to use a vocabulary about pets that
>> includes the concept "canine," you could use the "broader_match" property
>> to link the "dog" concept in the animals vocabulary to the "canine" concept
>> in the pets vocabulary. This would indicate that the "dog" concept is a
>> more specific version of the "canine" concept, and that the two concepts
>> are related.
>> >
>> > In summary, the "broader" property is used to relate concepts within a
>> single SKOS vocabulary, while the "broader_match" property is used to
>> relate a concept in one SKOS vocabulary to a broader concept in another
>> SKOS vocabulary.
>> >
>> >
>> > Le 28/12/22 à 20:57, Michael DeBellis a écrit :
>> >> I'm an experience OWL developer but I'm just getting up to speed on
>> SKOS. I think I understand the basics: that has_broader indicates a
>> relation between two Concepts where the broader Concept (the object) is a
>> superclass or super-part of the subject. E.g., Mammal has_broader Animal.
>> Also, to use SKOS and not fall into OWL Full, I need to pun every class I
>> want to assert a SKOS object property on.
>> >>
>> >> I think I also get has_related. When two Concepts are related (most
>> likely in OWL by some property other than has_Sub_Part). E.g., if Fido was
>> an instance of the Dog class and Michael has_Pet Fido then we could say
>> that Michael has_related Fido (and vice versa since has_related is
>> symmetric).
>> >>
>> >> And has_close_match would indicate that two entities in OWL are
>> (probably) the same entity. If they are individuals then they are
>> owl:sameAs and if class or properties owl:equivalentTo each other.
>> >>
>> >> So far so good (I think, please correct me if any of that is wrong).
>> But I don't get has_broader_match or has_narrower_match. If one entity is
>> broader or narrower than the other (which I interpret as super-class or
>> super-part relations) then I don't understand how they can also be matches.
>> Similarly for has_related_match.
>> >>
>> >> Also, what about OWL properties?. I'm assuming in this context
>> has_broader means the broader property is a super-property of the other
>> property, is that correct? Also, of course I would need to pun properties
>> as well. Any feedback would be appreciated.
>> >>
>> >> Michael
>> >> https://www.michaeldebellis.com/blog
>> >
>> >
>> > --
>> > Christophe Dupriez
>> > DESTIN-Informatique.com
>> > Projet AKUINO.net
>> > Tél.: +32 475.77.62.11
>> > Twitter @AkuinoNET
>> >
>>
>>
>
> --
> Tom Baker <tom@tombaker.org>
>