There is another obvious Use Case...

as skos:Concept is used to classify an instance of a more general class.
Over time it becomes necessary to model the sub set of instances of this
general class that share this classification - so the concept hasnt
changed, but under the OWA and AAA principles we can model it with further
axioms. Often such distinctions are necessary across lines of governance -
one domain only cares about a high level classification whereas another
needs to model in more detail the behaviour of subclasses.

I feel Irene's comments relate more to the (natural) requirement to have
alternative frame based models (shapes - i.e. choices of sets of
properties) for the same thing.  In the W3C Data Exchange Working Group we
are looking to formalise the concept of "profiles" and
content-negotiation-by-profile, so there is a mechanism to keep different
views separate (and conveniently discoverable and accessible)  without
forcing rather arbitrary (and difficult to describe and navigate) subtle
variations in defining the underlying concept to try to keep them distinct.






On Sat, 8 Sep 2018 at 17:55 dprice <dpr...@topquadrant.com> wrote:

> To be clear, “punning” is not a modelling concept. It’s just the
> implementation approach that DL reasoners take to handle a class being a
> member of another class. They pretend that there are two separate things (a
> class and an individual) with the same URI - thus the “pun".
>
> I’ve seen many models where classes with members that are also members of
> other classes. If it makes sense in your domain of interest, don’t fear
> using it.
>
> A simple example is “Pump”, the noun, as used in an oil platform. “Pump"
> has physical objects that are its members. However, “Pump" is also a member
> of the class "Rotating Mechanical Equipment Class”, which is a subclass of
> “Mechanical Equipment Class”, and which has other members like “Fan” and
> “Centrifuge”. “Pump” is also a member of the class "NORSOK
> Z-CR-002 Equipment Class” which are classes approved in a specific oil and
> gas standard.
>
> Another similar example is an ontology about the types of things of
> interest to a company that wants to specify, for example, which attributes
> are required to be recorded when a regular survey is done of a specific
> type of asset.  A class called TypeOfRoadAsset might have members Junction,
> Bridge, Motorway, etc. which would then have members “Junction 2 on the GB
> M1”, “London Bridge” and “GB M1” as members. A class called
> TypeOfRoadAttribute might have members Pavement Depth, Date of Build, etc.
> and then a class called AttributeOfRoadAsset would link the assets and
> attributes with members like "Motorway Pavement Depth” that are specified
> as being “mandatory” attributes to be recorded in the yearly road survey.
>
> Both of these examples are kinds of concepts found in real ontologies that
> are in operational use today. This kind of approach is common in the
> manufacturing and engineering asset management industries.
>
> Cheers,
> David
>
>
> On 8 Sep 2018, at 15:03, Adam Kimball <akimb...@healthwise.org> wrote:
>
> Thanks for the help so far.
>
> My intuition suggests the punning is not the right solution, too.  Your
> email, Irene, helps solidify that.  There is no doubt that the properties
> associated with a skos:Concept instance would be radically different from
> an owl:Class instance as you demonstrate with Flu and Audi Q6.
>
> -Adam
>
> On Friday, September 7, 2018 at 6:43:15 PM UTC-6, Irene Polikoff wrote:
>>
>> Adam,
>>
>> Yes, there should be no issue with SHACL.
>>
>> Having said this, I am yet to come across a situation where punning is
>> the best or even the right approach.
>>
>> Typically, when one puns, they really mean to describe two different
>> things that, in a natural language, are referred to using same term.
>> Natural language is informal because when people use the same name to talk
>> about two conceptually different things, they understand from the context
>> what is being talkied about.
>>
>> For example, let’s consider cars and car models. I could decide Audi Q6
>> to be an instance of a class Car Model (or its subclass Audi Car Model). If
>> so, this resource would have certain properties. Or I could decide it to be
>> a class. In the later case, my intention would be for the instances of the
>> class to be the actual cars that have VIN numbers, date of manufacturing,
>> owners that drive them, etc. None of these properties are appropriate for
>> the car model. Depending on what I am trying to express, while the resource
>> name/label could be the same, the meaning would be quite different. Since
>> these resources have different meaning and different properties, they
>> should be separate.
>>
>> Similarly, one could talk about a flu as an instance of a disease and a
>> flu as a set of all occurrences this disease - thus, a class or a set of
>> things, but a set of conceptually different things. Flu as an instance of a
>> disease has typically symptoms, commonly prescribed treatments, may be a
>> person who first discovered it, etc. A flu that someone had let’s say a
>> year ago is a member of the disease occurrences class. It has a start date,
>> an end date, patient that had the disease, etc. These properties are
>> appropriate for the members of the class disease occurrence, but not for
>> the class disease. It was probably treated, but not necessarily using
>> typically prescribed treatments. May be some of them, but definitely not
>> all. There is a relationship between an instance of a disease and a class
>> of decease occurrences (and between a car model and a class of cars), but
>> they are not the same things.
>>
>> Barry Smith has hundreds of slides explaining the difference - not that I
>> think hundreds of slides are necessary to communicate this.
>>
>> Of course, I do not know what your situation and needs are. Just thought
>> I’ll share my perspective on this common modeling question.
>>
>> Regards,
>>
>> Irene.
>>
>> On Sep 7, 2018, at 6:16 PM, Adam Kimball <akim...@healthwise.org> wrote:
>>
>> I've run into a few different scenarios where I would like something to
>> be both a class and an instance.  For me, this happens when I model
>> something as a skos:Concept because I want to refer to the abstract Thing
>> but later have a need to refer to individual Things.  In the past, I have
>> always been freaked out by this problem so I've found ways around it that
>> aren't very elegant.  But I'm working on a new project now where I might
>> Stop Worrying About Owl, and Learn to Love SHACL.
>>
>> I can't imagine why or how the concept of punning could cause problems in
>> SHACL but I think this list would have the people who could provide a
>> definitive answer.
>>
>> So, can I pun freely?
>>
>> -Adam
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "TopBraid Suite Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to topbraid-user...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "TopBraid Suite Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to topbraid-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "TopBraid Suite Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to topbraid-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to topbraid-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to