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

Interesting discussion,

I would just add a bit (if it was not added in this long email series):

perhaps it is viable to assert owl:sameAs between individuals.
If you identify a person by passport number or tax number, you can collapse all statements about the two pretty safely (assuming you consider endurant, not roles etc.). That you have different statements in the tax and passport office is a different question...

For something that is not an individual (say, classes, concepts)... owl:sameAs is problematic, because ultimately you don't know what an URI define.

getting back to Alan example:
http://alansays/renaultCars
http://I/renaultCars

Indeed these may be different things, I may include tanks and Nissan cars in it...

We can add axioms to try to clarify what we mean, and ultimately seeking equivalence under a consistent set of statements. We would really say that the two are equivalent, not the same.

Or we can shy away from the issue and use a relaxed sameAs (essentially with no formal meaning to it). It is very close to the Gi, Gu, G solution.
In any case, owl:sameAs among non individuals is a difficult thing to say, unless you contextualize.

best,
Andrea

Il giorno 16/mar/2013, alle ore 19:39, Jim McCusker <james.mccusker@yale.edu>
 ha scritto:

> (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
> 
> -- 
> This message has been scanned for viruses and 
> dangerous content by MailScanner, and 
> we believe but do not warrant that this e-mail and any attachments thereto do not contain any viruses. However, you are fully responsible for performing any virus scanning.