Re: owl:sameAs - Is it used in a right way?

(Adding the list back for Alan)

I think he's looking for something like skos:exactMatch/skos:closeMatch but
for things other than concepts, which is (I would argue) prov:alternateOf.


On Sat, Mar 16, 2013 at 2:36 PM, Alan Ruttenberg
<alanruttenberg@gmail.com>wrote:

>  Below is the documentation for skos:concept
>
>  It seems by this documentation that concepts are ideas. So in the case
> of the car we are talking about there would be the car, the idea of the
> car, the description of the idea of the car, and the description of the
> car.
>
>  I'm not sure introducing skos helps reduce complexity here. But I admit
> I don't have a lot of experience using skos.
>
>  How would you suggest modeling, using skos, the situation we are
> discussing?
>
>  -Alan
>
> The class skos:Concept is the class of SKOS concepts.
>
> A SKOS concept can be viewed as an idea or notion; a unit of thought.
> However, what constitutes a unit of thought is subjective, and this
> definition is meant to be suggestive, rather than restrictive.
>
> The notion of a SKOS concept is useful when describing the conceptual or
> intellectual structure of a knowledge organization system, and when
> referring to specific ideas or meanings established within a KOS.
>
> Note that, because SKOS is designed to be a vehicle for representing
> semi-formal KOS, such as thesauri and classification schemes, a certain
> amount of flexibility has been built in to the formal definition of this
> class.
>
>
>
> On Friday, March 15, 2013, Jim McCusker wrote:
>
>> SKOS properties only apply to concepts. So if you're describing concepts,
>> go wild. But they don't cover the world.
>>
>>  Jim
>>
>>
>> On Fri, Mar 15, 2013 at 5:00 PM, Umutcan ŞİMŞEK <s.umutcan@gmail.com>wrote:
>>
>>  And I forgot to ask, can there be a solution based on SKOS vocabulary?
>> AFAIK, SKOS properties are more flexible and semantically looser than
>> owl:sameAs.
>>
>>
>> On 15-03-2013 22:40, Jeremy J Carroll wrote:
>>
>> I think Jim's solution looks to me like the best realistic one going
>> forward … having somewhat looser variants of owl:sameAs and ask people to
>> be a bit honest with their use of sameAs …
>>
>>  For Alan's approach, I feel a problem is that what we are doing is
>> making an approximate model of the world, not a completely accurate copy.
>> Alan is of course correct that the description and the thing are
>> different, and if we want to be precise we would make that clear, and
>> failing to make this distinction may lead us into trouble; but whenever we
>> say anything about anything, the things we didn't say greatly out-number
>> the things we did say, and making a judgment as to what is important is
>> hard, and people will get it wrong.
>>
>>  I think most people, most of the time, do not want to be bothered
>> saying, "Well this is my opinion, and your opinion may differ, and believe
>> me if you wish" …. which is what making the careful distinction between the
>> thing and its description amounts to.
>>
>>  So IMO, Alan is correct, but somehow missing the point.
>>
>>  Jeremy
>>
>>
>>
>>  On Mar 15, 2013, at 12:56 PM, Alan Ruttenberg <alanruttenberg@gmail.com>
>> wrote:
>>
>> There's another perspective, which is to to distinguish descriptions of
>> things from the things themselves. This works if you can agree on identity
>> of the thing but not necessarily on the way to describe it. As an example,
>> consider the class of cars manufactured by Nissan (call it Cn). If you can
>> agree on a URI for that class, you can each write descriptions that have
>> foaf:primaryTopic Cn.
>>
>> Depending on how careful you want to be, you can then use one or two
>> graphs. If you have your predicate relate descriptions then you can use a
>> single graph. For example  instead of having a predicate hasNumberOfDoors
>> that relates cars to a count of doors you can
>> have  describedHasNumberOfDoors that relates a description of a car to a
>> number with the interpretation that the author of the description asserts
>> that the car has 4 doors.
>>
>>  Or, if you want to make assertions about the car, then use two graphs.
>> Each can make statements of the sort [isPrimaryTopicOf <description>]
>> hasNumberOfDoors 4. Since we are talking now about the cars, there could be
>> different perspectives, so to control that you put each author's assertions
>> in a different graph.
>>
>>  I think this is a better strategy than using sameAs. There are a bunch
>> of problems with sameAs, not least of which is that often the assertions
>> are incorrect - they mean something different, Jim's post gives a strategy
>> to relate them without using sameAs, but I'd assert that general ways of
>> relating descriptions takes more than a couple of relations, and should be
>> an orthogonal problem. With the primaryTopic method I suggest the
>> relationship that matters for your application - that the descriptions are
>> pointing to the same thing, is explicit, and doesn't need new predicates,
>> though it does require some level of coordination.
>>
>>  Best,
>> Alan
>>
>> On Fri, Mar 15, 2013 at 2:55 PM, Umutcan ŞİMŞEK <
>>
>>     --
>> Jim McCusker
>> Programmer Analyst
>> Krauthammer Lab, Pathology Informatics
>> Yale School of Medicine
>> james.mccusker@yale.edu | (203) 785-4436
>> http://krauthammerlab.med.yale.edu
>>
>> PhD Student
>> Tetherless World Constellation
>> Rensselaer Polytechnic Institute
>> mccusj@cs.rpi.edu
>> http://tw.rpi.edu
>>
>


-- 
Jim McCusker
Programmer Analyst
Krauthammer Lab, Pathology Informatics
Yale School of Medicine
james.mccusker@yale.edu | (203) 785-4436
http://krauthammerlab.med.yale.edu

PhD Student
Tetherless World Constellation
Rensselaer Polytechnic Institute
mccusj@cs.rpi.edu
http://tw.rpi.edu