Using DBpedia resources as skos:Concepts?

[Richard Cyganiak-2]

Hi,

I want to get some broader feedback and opinion on this question.

There is a use case where an external dataset is modelled in SKOS, and  
we want to map it to DBpedia. Something like:

<http://mydataset/433256>
     a skos:Concept;
     owl:sameAs <http://dbpedia.org/resource/Michelle_Obama>;
     .

I've used owl:sameAs here. Now the problem is that my:433256 is a  
skos:Concept, while dbp:Michelle_Obama is a foaf:Person. I wonder  
wether that's a problem. I can't see any immediate contradiction  
arising from that, but I'm uncertain.

Another option would be to use skos:closeMatch or skos:exactMatch, but  
these are intended for use between skos:Concepts, while I'm trying to  
connect a skos:Concept to a foaf:Person.

The main question, I guess, is wether people in the DBpedia project  
would consider the assertion

     <http://dbpedia.org/resource/Michelle_Obama> a skos:Concept .

to be acceptable or erroneous, or wether SKOS folks tell me that  
skos:Concept is obviously disjoint from foaf:Person.

I know that this is a complex issue, so I'm not really looking for a  
"right" or "wrong" answer. I'm more interested in getting all the pros  
and cons and pitfalls and caveats on the table, so please, if you have  
any opinion on the issue, I want to hear it.

I'm cc'ing Pat Hayes, because he said he's interested in that kind of  
question.

All the best and thanks for your time,
Richard




--
Linked Data Technologist • Linked Data Research Centre
Digital Enterprise Research Institute (DERI), NUI Galway, Ireland
http://linkeddata.deri.ie/
skype:richard.cyganiak
tel:[phone]

[Antoine Isaac-2]

Hi Richard,

I've recently been caught in discussions on the fact that it was not very good to have "universals" (in your case, concepts) mixed with "particulars" (in your case, persons). But to tell the truth, in the SKOS Recommendation there is no axioms stating that skos:Concept is distinct from foaf:Person. So there is no contradiction. I'll let you judge, maybe Dan and Pat can say more of it.

In fact there is an ontologically cleaner solution, namely to create some intermediate skos:Concept and use a specific property to link that concept to the physical entity it is intrinsically associated to. There was a suggestion (skos:it), again Dan may say something about it. But we never had the time to address that issue properly, so that was not included in the standard. One thing is sure, it would make all the paths to access the relevant data elements a bit longer.

About the skos:exactMatch vs. owl:sameAs issue. Your argument against skos:exactMatch is not really right. If you are using owl:sameAs, you are asserting that dbpedia:Michelle_Obama is a skos:Concept too, by virtue of owl:sameAs's semantics. At least if using skos:exactMatch you are not transfering other statements, e.g., if you have one that says that you created http://mydataset/433256 (using dc:creator), then according to owl:sameAs semantics you would have created dbpedia:Michelle_Obama as well.
There's a nice example of such not-so-good practice at the NYT dataset released last week (which is otherwise an excellent work!). There they have something like:
  <rdf:Description rdf:about="http://data.nytimes.com/64870337666324078863">
    <dc:creator>The New York Times Company</dc:creator>
   <cc:License>http://creativecommons.org/licenses/by/3.0/us/</cc:License>
    <dcterms:rightsHolder rdf:datatype="http://www.w3.org/2001/XMLSchema#string">The New York Times Company</dcterms:rightsHolder>
    <owl:sameAs rdf:resource="http://dbpedia.org/resource/John_Frankenheimer"/>
  </rdf:Description>

By stating those triples, they in fact say (for those who will apply the owl:sameAs semantics on the dataset) that they created the Freebase concept, and hold the rights for it. when using owl:sameAs, you would have to be careful about that. At least with the exactMatch solution you are a bit safer.

(I'm sorry this is maybe not the solution to your issues, but I have no time now for more than giving you caveats...)

Best,

Antoine

> Hi,
>
> I want to get some broader feedback and opinion on this question.
>
> There is a use case where an external dataset is modelled in SKOS, and
> we want to map it to DBpedia. Something like:
>
> <http://mydataset/433256>
>     a skos:Concept;
>     owl:sameAs <http://dbpedia.org/resource/Michelle_Obama>;
>     .
>
> I've used owl:sameAs here. Now the problem is that my:433256 is a
> skos:Concept, while dbp:Michelle_Obama is a foaf:Person. I wonder wether
> that's a problem. I can't see any immediate contradiction arising from
> that, but I'm uncertain.
>
> Another option would be to use skos:closeMatch or skos:exactMatch, but
> these are intended for use between skos:Concepts, while I'm trying to
> connect a skos:Concept to a foaf:Person.
>
> The main question, I guess, is wether people in the DBpedia project
> would consider the assertion
>
>     <http://dbpedia.org/resource/Michelle_Obama> a skos:Concept .
>
> to be acceptable or erroneous, or wether SKOS folks tell me that
> skos:Concept is obviously disjoint from foaf:Person.
>
> I know that this is a complex issue, so I'm not really looking for a
> "right" or "wrong" answer. I'm more interested in getting all the pros
> and cons and pitfalls and caveats on the table, so please, if you have
> any opinion on the issue, I want to hear it.
>
> I'm cc'ing Pat Hayes, because he said he's interested in that kind of
> question.
>
> All the best and thanks for your time,
> Richard
>
>
>
>

[Alexandre Passant-3]

Hi,

On 4 Nov 2009, at 00:56, Richard Cyganiak wrote:

> Hi,
>
> I want to get some broader feedback and opinion on this question.
>
> There is a use case where an external dataset is modelled in SKOS, and
> we want to map it to DBpedia. Something like:
>
> <http://mydataset/433256>
>     a skos:Concept;
>     owl:sameAs <http://dbpedia.org/resource/Michelle_Obama>;
>     .
>
> I've used owl:sameAs here. Now the problem is that my:433256 is a
> skos:Concept, while dbp:Michelle_Obama is a foaf:Person. I wonder
> wether that's a problem. I can't see any immediate contradiction
> arising from that, but I'm uncertain.
>
> Another option would be to use skos:closeMatch or skos:exactMatch, but
> these are intended for use between skos:Concepts, while I'm trying to
> connect a skos:Concept to a foaf:Person.
>
> The main question, I guess, is wether people in the DBpedia project
> would consider the assertion
>
>     <http://dbpedia.org/resource/Michelle_Obama> a skos:Concept .
>
> to be acceptable or erroneous, or wether SKOS folks tell me that
> skos:Concept is obviously disjoint from foaf:Person.

I think that is the question that should be answered here.
The SKOS spec says: "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."

So, do the SKOS implementors consider that, while subjective, anything  
can be allowed to go under skos:Concept ?
If not, shouldn't a disjunction be introduced in SKOS to prevent that ?

I find all these SKOS properties more that useful, but that  
subjectivity regarding skos:Concept is imo an issue - I personally  
limit the use of skos:Concept to non-physical objects / abstract  
notions, but since that's subjective, someone else will use it for  
anything, e.g. foaf:Person, and may lead to disagreement between us -  
and related applications.

Thanks,

Alex.

>
> I know that this is a complex issue, so I'm not really looking for a
> "right" or "wrong" answer. I'm more interested in getting all the pros
> and cons and pitfalls and caveats on the table, so please, if you have
> any opinion on the issue, I want to hear it.
>
> I'm cc'ing Pat Hayes, because he said he's interested in that kind of
> question.
>
> All the best and thanks for your time,
> Richard
>
>
>
>
> --
> Linked Data Technologist • Linked Data Research Centre
> Digital Enterprise Research Institute (DERI), NUI Galway, Ireland
> http://linkeddata.deri.ie/
> skype:richard.cyganiak
> tel:[phone]
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Dbpedia-discussion mailing list
> Dbpedia-discussion@...
> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion

--
Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .

[Dan Brickley-2]

On 4 Nov 2009, at 08:37, Antoine Isaac <aisaac@...> wrote:

> Hi Richard,
>
> I've recently been caught in discussions on the fact that it was not  
> very good to have "universals" (in your case, concepts) mixed with  
> "particulars" (in your case, persons). But to tell the truth, in the  
> SKOS Recommendation there is no axioms stating that skos:Concept is  
> distinct from foaf:Person. So there is no contradiction. I'll let  
> you judge, maybe Dan and Pat can say more of it.

Sent fat-fingered from my iphone; excuse the lack of detail and  
citations...

My main concern with this idiom is that SKOS is designed for talking  
about the artifacts of library-like systems which rarely map onto tidy  
subclass hierarchies. However often these artifacts are 'clearly'  
individual things or category (class) terms. Since most SKOS  
properties are for talking about the characteristics of the artifact  
(admin-related dates, scope notes etc) not the 'thing in the world',  
and since many thesauri will overlap in scope especially around link-
friendly entities like people and place, i see a tension.

An older rev of the SKOS spec had a nice example with Henry the 8th or  
similar, and urged a distinction between him and his lowercase-r-
reification as a Concept in SKOS.

While this might seem longwinded, and in a sense all things described  
in rdf are done so from the perspective of some conceptualisation, I  
am keen that we make sure thesaurus etc admin metadata doesn't get  
garbled when two or more thesauri are overlaid in the same rdf graph.  
If we use direct equivalence too enthusiastically this seems a risk.

Cheers,

Dan

[Jürgen Jakobitsch]

hi,

here's my two cents.

0. i think the question implies (psycho lingually) that mrs. obama
   IS really a foaf:Person. i think she's (also) DESCRIBED as a foaf:Person..
1. describing what really is, is hard enough - triple so with triples.  
2. it depends on who's looking at the data.
   2.1. i personally dont't consider mrs. obama to be a
        - a foaf:Person
        - a foaf:Agent
        - a geo:SpatialThing
        - a skos:Concept or whatever class, most certainly not a poor owl:Thing.        
   2.2. a reasoner with limited access to data, say your's and dbpedia would
        just find that this resource has two types, weather sensefull or not.
   2.3  a reasoner (more an intelligent agent) with access to all data, would
        most certainly find a triple somewhere, that states that a skos:Concept
        disjoints with a foaf:Person and conclude that humans (hm.. they're all
        owl:Things... tomorrow i use them as duracell:batteries..) are a quite contraditory breed.
3. consindering normal daily speaking reveals that asserting facts with owl has it's weaknesses and
   that a reasoner who sees these triple must be humanly intelligent.
   - mrs obama is a woman
   - mrs obama is the first lady
   - what mrs. obama means to me, is that .... (so she's an abstract concept)
   - yesterday i saw mrs. obama playing football (soccer)
   - my mother is a woman

wkr www.turnguard.com



----- Original Message -----
From: "Richard Cyganiak" <richard@...>
To: dbpedia-discussion@..., "SKOS" <public-esw-thes@...>
Cc: "Pat Hayes" <phayes@...>
Sent: Wednesday, November 4, 2009 1:56:56 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: [Dbpedia-discussion] Using DBpedia resources as skos:Concepts?

Hi,

I want to get some broader feedback and opinion on this question.

There is a use case where an external dataset is modelled in SKOS, and  
we want to map it to DBpedia. Something like:

<http://mydataset/433256>
     a skos:Concept;
     owl:sameAs <http://dbpedia.org/resource/Michelle_Obama>;
     .

I've used owl:sameAs here. Now the problem is that my:433256 is a  
skos:Concept, while dbp:Michelle_Obama is a foaf:Person. I wonder  
wether that's a problem. I can't see any immediate contradiction  
arising from that, but I'm uncertain.

Another option would be to use skos:closeMatch or skos:exactMatch, but  
these are intended for use between skos:Concepts, while I'm trying to  
connect a skos:Concept to a foaf:Person.

The main question, I guess, is wether people in the DBpedia project  
would consider the assertion

     <http://dbpedia.org/resource/Michelle_Obama> a skos:Concept .

to be acceptable or erroneous, or wether SKOS folks tell me that  
skos:Concept is obviously disjoint from foaf:Person.

I know that this is a complex issue, so I'm not really looking for a  
"right" or "wrong" answer. I'm more interested in getting all the pros  
and cons and pitfalls and caveats on the table, so please, if you have  
any opinion on the issue, I want to hear it.

I'm cc'ing Pat Hayes, because he said he's interested in that kind of  
question.

All the best and thanks for your time,
Richard




--
Linked Data Technologist • Linked Data Research Centre
Digital Enterprise Research Institute (DERI), NUI Galway, Ireland
http://linkeddata.deri.ie/
skype:richard.cyganiak
tel:[phone]


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Dbpedia-discussion mailing list
Dbpedia-discussion@...
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion

[Leonard Will]

On Wed, 4 Nov 2009 at 08:15:18, Alexandre Passant
<alexandre.passant@...> wrote

>I think that is the question that should be answered here.
>The SKOS spec says: "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."
>
>So, do the SKOS implementors consider that, while subjective, anything
>can be allowed to go under skos:Concept ?
>If not, shouldn't a disjunction be introduced in SKOS to prevent that ?
>
>I find all these SKOS properties more that useful, but that
>subjectivity regarding skos:Concept is imo an issue - I personally
>limit the use of skos:Concept to non-physical objects / abstract
>notions, but since that's subjective, someone else will use it for
>anything, e.g. foaf:Person, and may lead to disagreement between us -
>and related applications.
>
>Thanks,
>
>Alex.

 From the point of view of thesaurus standards, "concept" is used with a
very general meaning - "unit of thought" - which was introduced to
distinguish between that and the various different "terms" that may be
used to label it. A concept is defined by its scope note, if present,
and/or by its various terms and relationships.

In a thesaurus, concepts are divided into several disjoint facets, such
as people, objects, activities, disciplines, places, times, and
"abstract concepts" such as "peace", "friendship", "intellectual
property" and so on.

The choice of these facets may vary in different applications; "people"
could be part of an "organisms" facet, for example, and might or might
not include "organisations" or "groups of people".

As SKOS was developed to handle thesaurus structures, I believe that the
use of "concept" in SKOS is in accordance with this. Mrs Obama is an
"instance" of a concept within the "people" facet.

Leonard Will

--
Willpower Information     (Partners: Dr Leonard D Will, Sheena E Will)
Information Management Consultants            Tel: [phone]
27 Calshot Way                              L.Will@...
ENFIELD                                Sheena.Will@...
EN2 7BQ, UK                            http://www.willpowerinfo.co.uk/

[Ross Singer-2]

Is this the sort of scenario where umbel comes into play?  If so, I
might start understanding what exactly umbel is.

Given what I can parse from the documentation (hairnet over the
basketball and everything) is that:
<http://mydataset/433256>
  a skosConcept;
  umbel:linksEntity <http://dbpedia.org/resource/Michelle_Obama>;

might work.  The definition of linksEntity is this:

Property name:  umbel:linksEntity

Description:  Check the definition of umbel:isAbout for the definition
of this property; linksEntity is the inverse property of isAbout.

Domain:  umbel:SubjectConcept

Range: owl:Thing

Inverse-of: umbel:isAbout

with umbel:isAbout being:

Property name:  umbel:isAbout

Description:  The property umbel:isAbout is used to assert the
relation between a named entity (individual) and a subject concept
class. umbel:isAbout relates the named entity (individual) to the
class through the basis of its subject matter. The relation
acknowledges that the scope of the class can not be determined solely
by the aggregation or extent of its associated individual entity
members, and that the nature of the subject concept class may not
alone bound or define the individual entity.

Named entities may be related with multiple subject concept classes.
The domain of umbel:isAbout defines its class description as the class
of all individuals (owl:Thing) and its range as the class of subject
concepts (umbel:SubjectConcept), thereby bounding the property's
proper semantics of associating individuals to their related subject
concept class(es).

This property is therefore used to create a topical assertion between
an individual and a subject concept.

Domain: owl:Thing

Range: umbel:SubjectConcept

an umbel:SubjectConcept is a subclass of a skos:Concept.

If this -is- how that's supposed to work, it seems like a work around
the "aboutness" vs. "isness" issue.

-Ross.

On Tue, Nov 3, 2009 at 8:56 PM, Richard Cyganiak <richard@...> wrote:

> Hi,
>
> I want to get some broader feedback and opinion on this question.
>
> There is a use case where an external dataset is modelled in SKOS, and we
> want to map it to DBpedia. Something like:
>
> <http://mydataset/433256>
>    a skos:Concept;
>    owl:sameAs <http://dbpedia.org/resource/Michelle_Obama>;
>    .
>
> I've used owl:sameAs here. Now the problem is that my:433256 is a
> skos:Concept, while dbp:Michelle_Obama is a foaf:Person. I wonder wether
> that's a problem. I can't see any immediate contradiction arising from that,
> but I'm uncertain.
>
> Another option would be to use skos:closeMatch or skos:exactMatch, but these
> are intended for use between skos:Concepts, while I'm trying to connect a
> skos:Concept to a foaf:Person.
>
> The main question, I guess, is wether people in the DBpedia project would
> consider the assertion
>
>    <http://dbpedia.org/resource/Michelle_Obama> a skos:Concept .
>
> to be acceptable or erroneous, or wether SKOS folks tell me that
> skos:Concept is obviously disjoint from foaf:Person.
>
> I know that this is a complex issue, so I'm not really looking for a "right"
> or "wrong" answer. I'm more interested in getting all the pros and cons and
> pitfalls and caveats on the table, so please, if you have any opinion on the
> issue, I want to hear it.
>
> I'm cc'ing Pat Hayes, because he said he's interested in that kind of
> question.
>
> All the best and thanks for your time,
> Richard
>
>
>
>
> --
> Linked Data Technologist • Linked Data Research Centre
> Digital Enterprise Research Institute (DERI), NUI Galway, Ireland
> http://linkeddata.deri.ie/
> skype:richard.cyganiak
> tel:[phone]
>
>
>

[Frederick Giasson]

Hi Ross!

Exactly. It is a good example of the usage of umbel:linksEntity. so, it
links a concept to a related (in terms of aboutness) individual.

So, with these two properties, we have the usecases for: "Concept ->
Individual" and "Individual -> Concept"

Additionally, you have other properties that handle other usecases such as:

(1) umbel:isLike (Individual -> Individual). You can also reify a
likelihood weight by reifying the umbel:withLikelihood property)
(2) umbel:isAligned and umbel:linksConcept (Class -> SubjectConcept and
SubjectConcept -> Class ; and you can reify an alignement weight with
the umbel:isAligned property).


So, as you cited bellow, the goal is to assert "aboutness and
likelihood" relationship between: individuals, classes and subject concepts.

So, umbel has two major components: (1) a graph of subject concepts (its
usage is discussed at length in the documentation) and (2) an ontology
that relates inviduals and classes to subject concepts (usecases
discussed in this thread).

http://umbel.org/technical_documentation.html

A new version of the subject concepts framework will be released soon
(v0.73)


Thanks!


Take care,

Fred

> Is this the sort of scenario where umbel comes into play?  If so, I
> might start understanding what exactly umbel is.
>
> Given what I can parse from the documentation (hairnet over the
> basketball and everything) is that:
> <http://mydataset/433256>
>   a skosConcept;
>   umbel:linksEntity <http://dbpedia.org/resource/Michelle_Obama>;
>
> might work.  The definition of linksEntity is this:
>
> Property name:  umbel:linksEntity
>
> Description:  Check the definition of umbel:isAbout for the definition
> of this property; linksEntity is the inverse property of isAbout.
>
> Domain:  umbel:SubjectConcept
>
> Range: owl:Thing
>
> Inverse-of: umbel:isAbout
>
> with umbel:isAbout being:
>
> Property name:  umbel:isAbout
>
> Description:  The property umbel:isAbout is used to assert the
> relation between a named entity (individual) and a subject concept
> class. umbel:isAbout relates the named entity (individual) to the
> class through the basis of its subject matter. The relation
> acknowledges that the scope of the class can not be determined solely
> by the aggregation or extent of its associated individual entity
> members, and that the nature of the subject concept class may not
> alone bound or define the individual entity.
>
> Named entities may be related with multiple subject concept classes.
> The domain of umbel:isAbout defines its class description as the class
> of all individuals (owl:Thing) and its range as the class of subject
> concepts (umbel:SubjectConcept), thereby bounding the property's
> proper semantics of associating individuals to their related subject
> concept class(es).
>
> This property is therefore used to create a topical assertion between
> an individual and a subject concept.
>
> Domain: owl:Thing
>
> Range: umbel:SubjectConcept
>
> an umbel:SubjectConcept is a subclass of a skos:Concept.
>
> If this -is- how that's supposed to work, it seems like a work around
> the "aboutness" vs. "isness" issue.
>
> -Ross.
>
> On Tue, Nov 3, 2009 at 8:56 PM, Richard Cyganiak <richard@...> wrote:
>  
>> Hi,
>>
>> I want to get some broader feedback and opinion on this question.
>>
>> There is a use case where an external dataset is modelled in SKOS, and we
>> want to map it to DBpedia. Something like:
>>
>> <http://mydataset/433256>
>>    a skos:Concept;
>>    owl:sameAs <http://dbpedia.org/resource/Michelle_Obama>;
>>    .
>>
>> I've used owl:sameAs here. Now the problem is that my:433256 is a
>> skos:Concept, while dbp:Michelle_Obama is a foaf:Person. I wonder wether
>> that's a problem. I can't see any immediate contradiction arising from that,
>> but I'm uncertain.
>>
>> Another option would be to use skos:closeMatch or skos:exactMatch, but these
>> are intended for use between skos:Concepts, while I'm trying to connect a
>> skos:Concept to a foaf:Person.
>>
>> The main question, I guess, is wether people in the DBpedia project would
>> consider the assertion
>>
>>    <http://dbpedia.org/resource/Michelle_Obama> a skos:Concept .
>>
>> to be acceptable or erroneous, or wether SKOS folks tell me that
>> skos:Concept is obviously disjoint from foaf:Person.
>>
>> I know that this is a complex issue, so I'm not really looking for a "right"
>> or "wrong" answer. I'm more interested in getting all the pros and cons and
>> pitfalls and caveats on the table, so please, if you have any opinion on the
>> issue, I want to hear it.
>>
>> I'm cc'ing Pat Hayes, because he said he's interested in that kind of
>> question.
>>
>> All the best and thanks for your time,
>> Richard
>>
>>
>>
>>
>> --
>> Linked Data Technologist • Linked Data Research Centre
>> Digital Enterprise Research Institute (DERI), NUI Galway, Ireland
>> http://linkeddata.deri.ie/
>> skype:richard.cyganiak
>> tel:[phone]
>>
>>
>>
>>    
>
>  

[Neubert Joachim]

Hi Richard,

 

In my eyes, it's completely ok to use skos:exactMatch or skos:closeMatch in a situation like this (I did it myself for the STW Thesaurus for Economics mapping to dbpedia).

 

Thesauri and classifications are not restricted to abstract concepts. Some thesauri deal explicitly with individual things, e.g. the widely used Getty "Thesaurus of Geographic Names" or "Union List of Artist Names". Other thesauri (like STW) have sections (or facets, as Leonard put it) on geografic names along with others containing "pure" concepts. SKOS, as I understand it, is intended to cover all this and to be used beyond strict class hierarchies or class/individual dichotomies.

 

By the way, some of the SKOS properties (especially the prefLabel/altLabel/hiddenLabel semantics) can be useful in a broad range of applications. Eg. dbpedia itself could be used as a great source for synonym candidates by mapping the resources to skos:Concept and the labels for dbpedia:redirect resources to skos:altLabel.

 

Cheers, Joachim

---

Von: Richard Cyganiak [mailto:richard@...]
Gesendet: Mi 04.11.2009 01:56
An: dbpedia-discussion@...; SKOS
Cc: Pat Hayes
Betreff: [Dbpedia-discussion] Using DBpedia resources as skos:Concepts?

Hi,

I want to get some broader feedback and opinion on this question.

There is a use case where an external dataset is modelled in SKOS, and 
we want to map it to DBpedia. Something like:

<http://mydataset/433256>
     a skos:Concept;
     owl:sameAs <http://dbpedia.org/resource/Michelle_Obama>;
     .

I've used owl:sameAs here. Now the problem is that my:433256 is a 
skos:Concept, while dbp:Michelle_Obama is a foaf:Person. I wonder 
wether that's a problem. I can't see any immediate contradiction 
arising from that, but I'm uncertain.

Another option would be to use skos:closeMatch or skos:exactMatch, but 
these are intended for use between skos:Concepts, while I'm trying to 
connect a skos:Concept to a foaf:Person.

The main question, I guess, is wether people in the DBpedia project 
would consider the assertion

     <http://dbpedia.org/resource/Michelle_Obama> a skos:Concept .

to be acceptable or erroneous, or wether SKOS folks tell me that 
skos:Concept is obviously disjoint from foaf:Person.

I know that this is a complex issue, so I'm not really looking for a 
"right" or "wrong" answer. I'm more interested in getting all the pros 
and cons and pitfalls and caveats on the table, so please, if you have 
any opinion on the issue, I want to hear it.

I'm cc'ing Pat Hayes, because he said he's interested in that kind of 
question.

All the best and thanks for your time,
Richard




--
Linked Data Technologist • Linked Data Research Centre
Digital Enterprise Research Institute (DERI), NUI Galway, Ireland
http://linkeddata.deri.ie/
skype:richard.cyganiak
tel:[phone]


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Dbpedia-discussion mailing list
Dbpedia-discussion@...
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion

[paul.mohr]

Just to say that use of Thesaurus for geographic concepts is very valuable in context of local government and community projects where a particular geographical location can have many alternative names and spellings.

Thanks, Paul
         

From:	"Neubert Joachim" <J.Neubert@...>
To:	"Richard Cyganiak" <richard@...>, <dbpedia-discussion@...>, "SKOS" <public-esw-thes@...>
Cc:	"Pat Hayes" <phayes@...>
Date:	04/11/2009 14:05
Subject:	AW: [Dbpedia-discussion] Using DBpedia resources as skos:Concepts?
Sent by:	public-esw-thes-request@...

---

Hi Richard,
 
In my eyes, it's completely  ok to use skos:exactMatch or skos:closeMatch in a situation like this (I did it  myself for the STW Thesaurus for Economics mapping to dbpedia).
 
Thesauri and classifications  are not restricted to abstract concepts. Some thesauri deal explicitly with  individual things, e.g. the widely used Getty "Thesaurus of Geographic Names" or  "Union List of Artist Names". Other thesauri (like STW) have sections (or  facets, as Leonard put it) on geografic names along with others containing  "pure" concepts. SKOS, as I understand it, is intended to cover all this and to  be used beyond strict class hierarchies or class/individual  dichotomies.
 
By the way, some of the SKOS  properties (especially the prefLabel/altLabel/hiddenLabel semantics) can be  useful in a broad range of applications. Eg. dbpedia itself could be used as a  great source for synonym candidates by mapping the resources to skos:Concept and  the labels for dbpedia:redirect resources to skos:altLabel.
 
Cheers,  Joachim

---

Von: Richard Cyganiak  [mailto:richard@...]
Gesendet: Mi 04.11.2009  01:56
An: dbpedia-discussion@...; SKOS
Cc: Pat Hayes
Betreff: [Dbpedia-discussion] Using DBpedia resources as  skos:Concepts?


Hi,

I want to get some broader feedback and opinion on  this question.

There is a use case where an external dataset is modelled  in SKOS, and 
we want to map it to DBpedia. Something  like:

<http://mydataset/433256>
      a skos:Concept;
     owl:sameAs <http://dbpedia.org/resource/Michelle_Obama>;
      .

I've used owl:sameAs here. Now the problem is that my:433256 is  a 
skos:Concept, while dbp:Michelle_Obama is a foaf:Person. I  wonder 
wether that's a problem. I can't see any immediate  contradiction 
arising from that, but I'm uncertain.

Another  option would be to use skos:closeMatch or skos:exactMatch, but 
these  are intended for use between skos:Concepts, while I'm trying to 
connect  a skos:Concept to a foaf:Person.

The main question, I guess, is wether  people in the DBpedia project 
would consider the  assertion

     <http://dbpedia.org/resource/Michelle_Obama>  a skos:Concept .

to be acceptable or erroneous, or wether SKOS folks tell  me that 
skos:Concept is obviously disjoint from foaf:Person.

I  know that this is a complex issue, so I'm not really looking for  a 
"right" or "wrong" answer. I'm more interested in getting all the  pros 
and cons and pitfalls and caveats on the table, so please, if you  have 
any opinion on the issue, I want to hear it.

I'm cc'ing Pat  Hayes, because he said he's interested in that kind  of 
question.

All the best and thanks for your  time,
Richard




--
Linked Data Technologist • Linked Data  Research Centre
Digital Enterprise Research Institute (DERI), NUI Galway,  Ireland
http://linkeddata.deri.ie/
skype:richard.cyganiak
tel:[phone]


------------------------------------------------------------------------------
Let  Crystal Reports handle the reporting - Free Crystal Reports 2008  30-Day
trial. Simplify your report design, integration and deployment - and  focus on
what you do best, core application coding. Discover what's new  with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Dbpedia-discussion  mailing list
Dbpedia-discussion@...
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion



***********************************************************************
The information contained within this e-mail (and any attachment) sent by Service Birmingham Ltd. is confidential and may be legally privileged. It is intended only for the named recipient or entity to whom it is addressed. If you are not the intended recipient, please notify the sender and delete the e-mail immediately. Unauthorised access, use, disclosure, storage or copying is not permitted and may be unlawful. Any e-mail including its content may be monitored and used by Service Birmingham Ltd. for reasons of security and for monitoring internal compliance with Security Policy. E-mail blocking software will also be used. Any views or opinions expressed are solely those of the originator and do not necessarily represent those of Service Birmingham Ltd.

Although Service Birmingham Ltd. has made every reasonable effort to ensure that this message and any attachments contain no viruses and have not been intercepted or amended, it can not make any assurances to this effect.

Service Birmingham Ltd, Registered in England & Wales under Company No: 05660977�������
Registered Office: Units 2&3 B1, 50 Summer Hill Road, Birmingham, B1 3RB.
***********************************************************************

[Simon Reinhardt]

Hi

Neubert Joachim wrote:

> In my eyes, it's completely ok to use skos:exactMatch or skos:closeMatch
> in a situation like this (I did it myself for the STW Thesaurus for
> Economics mapping to dbpedia).
>  
> Thesauri and classifications are not restricted to abstract concepts.
> Some thesauri deal explicitly with individual things, e.g. the widely
> used Getty "Thesaurus of Geographic Names" or "Union List of Artist
> Names". Other thesauri (like STW) have sections (or facets, as Leonard
> put it) on geografic names along with others containing "pure" concepts.
> SKOS, as I understand it, is intended to cover all this and to be used
> beyond strict class hierarchies or class/individual dichotomies.

While I agree that using real-world entities for classification is ok I don't think this means you have to declare them to be (skos:)concepts. The "has subject" relationship in FRBR [1] for example can link a work to a concept but also to places, people, events, other works, etc. So in this case you can use real-world entities to classify the work (to state what its subjects are) but that doesn't mean you declare all those entities to be conceptual.

So in my eyes there's still value in keeping (skos:)concepts and other things apart. Concepts to me are closer to classes than to individuals. And as Dan pointed out concepts have administrative data attached - they get created and changed etc. so they're basically units of organisation.

I'd therefore prefer using the UMBEL terms or something else for aligning real-world entities and concepts.

> By the way, some of the SKOS properties (especially the
> prefLabel/altLabel/hiddenLabel semantics) can be useful in a broad range
> of applications. Eg. dbpedia itself could be used as a great source for
> synonym candidates by mapping the resources to skos:Concept and the
> labels for dbpedia:redirect resources to skos:altLabel.

Yup, it has a lot of useful annotation terms. They are all declared to be annotation properties and deliberately don't have skos:Concept in their domain. So you can use them on anything which is great!

Regards,
  Simon


[1] http://archive.ifla.org/VII/s13/frbr/frbr_current5.htm#5.2 - scroll down to "5.2.3 Subject Relationships"

[Neubert Joachim]

Hi Simon,

 

Sorry for causing some misunderstanding: My point was not that you SHOULD use skos:Concept. What I rather wanted to say is that it does no harm and that it's already in use for named entites. 

 

This point arises from the suggestion to use skos:exactMatch/closeMatch. These properties are sub-sub-properties of skos:semanticRelation, which entails that subject and object of these properties are instances of skos:Concept (since skos:Concept are domain and range for skos:semanticRelation).

 

The great advantage of skos:exactMatch/closeMatch (over owl:sameAs) is that their semantic doesn't smush the resources with all their properties (like the administrative properties you mentioned).

 

The reason why I prefer skos:exactMatch/closeMatch to the suggested UMBEL properties is that, as an W3C Recommendation with a lot of implementations already, SKOS  is more widespread (and maybe more stable). So I expect better  immediate understandig and more tool support for the skos properties. However, this may be the biased view of a long-term thesaurus/KOS afficinado ...

 

Cheers, Joachim

 

---

Von: Simon Reinhardt [mailto:simon.reinhardt@...]
Gesendet: Do 05.11.2009 17:35
An: Neubert Joachim
Cc: Richard Cyganiak; dbpedia-discussion@...; SKOS; Pat Hayes
Betreff: Re: AW: [Dbpedia-discussion] Using DBpedia resources as skos:Concepts?

Hi

Neubert Joachim wrote:

> In my eyes, it's completely ok to use skos:exactMatch or skos:closeMatch
> in a situation like this (I did it myself for the STW Thesaurus for
> Economics mapping to dbpedia).
> 
> Thesauri and classifications are not restricted to abstract concepts.
> Some thesauri deal explicitly with individual things, e.g. the widely
> used Getty "Thesaurus of Geographic Names" or "Union List of Artist
> Names". Other thesauri (like STW) have sections (or facets, as Leonard
> put it) on geografic names along with others containing "pure" concepts.
> SKOS, as I understand it, is intended to cover all this and to be used
> beyond strict class hierarchies or class/individual dichotomies.

While I agree that using real-world entities for classification is ok I don't think this means you have to declare them to be (skos:)concepts. The "has subject" relationship in FRBR [1] for example can link a work to a concept but also to places, people, events, other works, etc. So in this case you can use real-world entities to classify the work (to state what its subjects are) but that doesn't mean you declare all those entities to be conceptual.

So in my eyes there's still value in keeping (skos:)concepts and other things apart. Concepts to me are closer to classes than to individuals. And as Dan pointed out concepts have administrative data attached - they get created and changed etc. so they're basically units of organisation.

I'd therefore prefer using the UMBEL terms or something else for aligning real-world entities and concepts.

> By the way, some of the SKOS properties (especially the
> prefLabel/altLabel/hiddenLabel semantics) can be useful in a broad range
> of applications. Eg. dbpedia itself could be used as a great source for
> synonym candidates by mapping the resources to skos:Concept and the
> labels for dbpedia:redirect resources to skos:altLabel.

Yup, it has a lot of useful annotation terms. They are all declared to be annotation properties and deliberately don't have skos:Concept in their domain. So you can use them on anything which is great!

Regards,
  Simon


[1] http://archive.ifla.org/VII/s13/frbr/frbr_current5.htm#5.2 - scroll down to "5.2.3 Subject Relationships"

[Frederick Giasson]

Hi Joachim,
> Sorry for causing some misunderstanding: My point was not that you
> SHOULD use skos:Concept. What I rather wanted to say is that it does
> no harm and that it's already in use for named entites.
>  
> This point arises from the suggestion to use
> skos:exactMatch/closeMatch. These properties are sub-sub-properties of
> skos:semanticRelation, which entails that subject and object of these
> properties are instances of skos:Concept (since skos:Concept are
> domain and range for skos:semanticRelation).
For "concept-to-concept" relationship you are right.
> The reason why I prefer skos:exactMatch/closeMatch to the suggested
> UMBEL properties is that, as an W3C Recommendation with a lot of
> implementations already, SKOS  is more widespread (and maybe more
> stable). So I expect better  immediate understandig and more tool
> support for the skos properties. However, this may be the biased view
> of a long-term thesaurus/KOS afficinado ...
It could be a reason why you would prefer the use of the SKOS terms, I
am all for it.

The only problem is that we are talking about different use-cases here.

semanticRelation relates two concepts. However, this thread started by
figuring out if it was making sense (advantages, disavantages) os
relating a skos:Concept to a foaf:Person using owl:sameAs. This is the
reason why the UMBEL properties have been listed here. So, we have
different use-cases at hands:

(1) Individual-to-Individual sameness/likelihood relationship
(2) Class-to-Class sameness/likelihood relationship
(3) Class-to-Individual sameness/likelihood relationship
(4) Individual-to-Class sameness/likelihood relationship
(5) Class-to-Concept sameness/likelihood relationship
(6) Concept-to-Class sameness/likelihood relationship


Apparently that skos:semanticRelation would fall into the
"Concept-to-Concept" sameness/likelihood relationship.

All of these are different usecases that get handled by different
ontologies/projects.

SKOS is mostly relation to taxonomic relationships, so maybe (I am just
making a supposition here) they are not interested in these other
relationships that exists in UMBEL.

UMBEL is:

"UMBEL (Upper-level Mapping and Binding Exchange Layer) is a lightweight
ontology for relating external ontologies and their classes to UMBEL
subject concepts. UMBEL subject concepts are conceptually related
together using the SKOS 1 and the OWL-Full 2 ontologies. They form a
structural 'backbone' comprised of subject concepts and their semantic
relationships. By linking external ontologies to this conceptual
structure, we explode the domain of the linked classes by leveraging
this conceptual structure. UMBEL's project Web site is at
http://www.umbel.org.

UMBEL defines "subject concepts" as a distinct subset of the more
broadly understood concept such as used in the SKOS/OWL-Full controlled
vocabulary, conceptual graphs, formal concept analysis or the very
general concepts common to many upper ontologies. We define subject
concepts as a special kind of concept: namely, ones that are concrete,
subject-related and non-abstract.

UMBEL contrasts subject concepts with abstract concepts and with named
entities. Abstract concepts represent abstract or ephemeral notions such
as truth, beauty, evil or justice, or are thought constructs useful to
organizing or categorizing things but are not readily seen in the
experiential world. Named entities are the real things or instances in
the world that are themselves natural and notable class members of
subject concepts. More detailed distinctions are provided under
Terminology and Definitions below."


And the reason why its simple ontology describe this kind of properties.

But at the end, users decide :)


Thanks,


Take care,


Fred

[kidehen]

Neubert Joachim wrote:

> Hi Simon,
>  
> Sorry for causing some misunderstanding: My point was not that you
> SHOULD use skos:Concept. What I rather wanted to say is that it does
> no harm and that it's already in use for named entites.
>  
> This point arises from the suggestion to use
> skos:exactMatch/closeMatch. These properties are sub-sub-properties of
> skos:semanticRelation, which entails that subject and object of these
> properties are instances of skos:Concept (since skos:Concept are
> domain and range for skos:semanticRelation).
>  
> The great advantage of skos:exactMatch/closeMatch (over owl:sameAs) is
> that their semantic doesn't smush the resources with all their
> properties (like the administrative properties you mentioned).

Joachim,

What do you mean by "smush" are you referring to the union expansion
that results from combing data from all the data sources in the
owl:sameAs relation? I pose my question with the skos:exactMatch
description page URL [1] for context. I see Transitivity and Symmetry,
which are factors re. decision making by reasoners re: union expansion
based on participants in the relation. Note, by "union expansion" I mean
the union of all data associated with the data items in the relation.

Primarily, I just want clarification about "smushing",  relative to the
property definition exposed by the skos:exactMatch URI,  more than
anything else. Thus, far I've simply assumed that skos:exactMatch and
owl:sameAs have similar implementation mechanics re. union expansion,
but their use targets vary i.e. skos:exactMatch works better for Concept
Schemes (where the world view assumes Named Entities e.g., "People"
aren't Concepts) while owl:sameAs works better for Named Entities
(people, places, and other typical real more things, so to speak).


Links:

1.
http://linkeddata.uriburner.com/about/html/http/www.w3.org/2004/02/skos/core%01exactMatch

Kingsley

> [SNIP]
> ..
>  
> Cheers, Joachim
>  
>
> ------------------------------------------------------------------------
> *Von:* Simon Reinhardt [mailto:simon.reinhardt@...]
> *Gesendet:* Do 05.11.2009 17:35
> *An:* Neubert Joachim
> *Cc:* Richard Cyganiak; dbpedia-discussion@...;
> SKOS; Pat Hayes
> *Betreff:* Re: AW: [Dbpedia-discussion] Using DBpedia resources as
> skos:Concepts?
>
> Hi
>
> Neubert Joachim wrote:
> > In my eyes, it's completely ok to use skos:exactMatch or skos:closeMatch
> > in a situation like this (I did it myself for the STW Thesaurus for
> > Economics mapping to dbpedia).
> >
> > Thesauri and classifications are not restricted to abstract concepts.
> > Some thesauri deal explicitly with individual things, e.g. the widely
> > used Getty "Thesaurus of Geographic Names" or "Union List of Artist
> > Names". Other thesauri (like STW) have sections (or facets, as Leonard
> > put it) on geografic names along with others containing "pure" concepts.
> > SKOS, as I understand it, is intended to cover all this and to be used
> > beyond strict class hierarchies or class/individual dichotomies.
>
> While I agree that using real-world entities for classification is ok
> I don't think this means you have to declare them to be
> (skos:)concepts. The "has subject" relationship in FRBR [1] for
> example can link a work to a concept but also to places, people,
> events, other works, etc. So in this case you can use real-world
> entities to classify the work (to state what its subjects are) but
> that doesn't mean you declare all those entities to be conceptual.
>
> So in my eyes there's still value in keeping (skos:)concepts and other
> things apart. Concepts to me are closer to classes than to
> individuals. And as Dan pointed out concepts have administrative data
> attached - they get created and changed etc. so they're basically
> units of organisation.
>
> I'd therefore prefer using the UMBEL terms or something else for
> aligning real-world entities and concepts.
>
> > By the way, some of the SKOS properties (especially the
> > prefLabel/altLabel/hiddenLabel semantics) can be useful in a broad range
> > of applications. Eg. dbpedia itself could be used as a great source for
> > synonym candidates by mapping the resources to skos:Concept and the
> > labels for dbpedia:redirect resources to skos:altLabel.
>
> Yup, it has a lot of useful annotation terms. They are all declared to
> be annotation properties and deliberately don't have skos:Concept in
> their domain. So you can use them on anything which is great!
>
> Regards,
>   Simon
>
>
> [1] http://archive.ifla.org/VII/s13/frbr/frbr_current5.htm#5.2 -
> scroll down to "5.2.3 Subject Relationships"
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> Dbpedia-discussion mailing list
> Dbpedia-discussion@...
> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>  

--


Regards,

Kingsley Idehen      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO
OpenLink Software     Web: http://www.openlinksw.com

[John Graybeal-3]

> Thus, far I've simply assumed that skos:exactMatch and owl:sameAs  
> have similar implementation mechanics re. union expansion, but their  
> use targets vary i.e. skos:exactMatch works better for Concept  
> Schemes (where the world view assumes Named Entities e.g., "People"  
> aren't Concepts) while owl:sameAs works better for Named Entities  
> (people, places, and other typical real more things, so to speak).

I'm sorry, but my understanding of the semantics of owl:sameAs seems  
to be different than is being implied here -- can someone address this  
explicitly?

I have always understood owl:sameAs to link (very tightly!) one on-
line resource to another.  For example, I could say that my URL is  
referring to exactly the same concept as someone else's URN.  So  
anything said about one concept now applies to the other, if sameAs is  
used. Maybe what's confusing me in this exchange is that I could  
imagine several different URLs that refer to an individual person (for  
example), but present that individual in different contexts, and the  
things they say are relative to the context.  Even though the  
individuals at http://mywork.com/staff/joebob, http://joebobfamily.name/joebob 
, and foaf:person=joebob are the same person, that does not mean that  
owl:sameAs is an acceptable linkage of those 3 resources.  Which  
suggests "owl:sameAs works better for Named Entitites" is not a good  
practice to follow, doesn't it?

John



On Nov 5, 2009, at 1029, Kingsley Idehen wrote:

> Neubert Joachim wrote:
>> Hi Simon,
>> Sorry for causing some misunderstanding: My point was not that you  
>> SHOULD use skos:Concept. What I rather wanted to say is that it  
>> does no harm and that it's already in use for named entites.  This  
>> point arises from the suggestion to use skos:exactMatch/closeMatch.  
>> These properties are sub-sub-properties of skos:semanticRelation,  
>> which entails that subject and object of these properties are  
>> instances of skos:Concept (since skos:Concept are domain and range  
>> for skos:semanticRelation).
>> The great advantage of skos:exactMatch/closeMatch (over owl:sameAs)  
>> is that their semantic doesn't smush the resources with all their  
>> properties (like the administrative properties you mentioned).
> Joachim,
>
> What do you mean by "smush" are you referring to the union expansion  
> that results from combing data from all the data sources in the  
> owl:sameAs relation? I pose my question with the skos:exactMatch  
> description page URL [1] for context. I see Transitivity and  
> Symmetry, which are factors re. decision making by reasoners re:  
> union expansion based on participants in the relation. Note, by  
> "union expansion" I mean the union of all data associated with the  
> data items in the relation.
>
> Primarily, I just want clarification about "smushing",  relative to  
> the property definition exposed by the skos:exactMatch URI,  more  
> than anything else. Thus, far I've simply assumed that  
> skos:exactMatch and owl:sameAs have similar implementation mechanics  
> re. union expansion, but their use targets vary i.e. skos:exactMatch  
> works better for Concept Schemes (where the world view assumes Named  
> Entities e.g., "People" aren't Concepts) while owl:sameAs works  
> better for Named Entities (people, places, and other typical real  
> more things, so to speak).
>
>
> Links:
>
> 1. http://linkeddata.uriburner.com/about/html/http/www.w3.org/2004/02/skos/core%01exactMatch
>
> Kingsley
>> [SNIP]
>> ..
>> Cheers, Joachim
>>
>> ------------------------------------------------------------------------
>> *Von:* Simon Reinhardt [mailto:simon.reinhardt@...]
>> *Gesendet:* Do 05.11.2009 17:35
>> *An:* Neubert Joachim
>> *Cc:* Richard Cyganiak; dbpedia-discussion@...;  
>> SKOS; Pat Hayes
>> *Betreff:* Re: AW: [Dbpedia-discussion] Using DBpedia resources as  
>> skos:Concepts?
>>
>> Hi
>>
>> Neubert Joachim wrote:
>> > In my eyes, it's completely ok to use skos:exactMatch or  
>> skos:closeMatch
>> > in a situation like this (I did it myself for the STW Thesaurus for
>> > Economics mapping to dbpedia).
>> > > Thesauri and classifications are not restricted to abstract  
>> concepts.
>> > Some thesauri deal explicitly with individual things, e.g. the  
>> widely
>> > used Getty "Thesaurus of Geographic Names" or "Union List of Artist
>> > Names". Other thesauri (like STW) have sections (or facets, as  
>> Leonard
>> > put it) on geografic names along with others containing "pure"  
>> concepts.
>> > SKOS, as I understand it, is intended to cover all this and to be  
>> used
>> > beyond strict class hierarchies or class/individual dichotomies.
>>
>> While I agree that using real-world entities for classification is  
>> ok I don't think this means you have to declare them to be  
>> (skos:)concepts. The "has subject" relationship in FRBR [1] for  
>> example can link a work to a concept but also to places, people,  
>> events, other works, etc. So in this case you can use real-world  
>> entities to classify the work (to state what its subjects are) but  
>> that doesn't mean you declare all those entities to be conceptual.
>>
>> So in my eyes there's still value in keeping (skos:)concepts and  
>> other things apart. Concepts to me are closer to classes than to  
>> individuals. And as Dan pointed out concepts have administrative  
>> data attached - they get created and changed etc. so they're  
>> basically units of organisation.
>>
>> I'd therefore prefer using the UMBEL terms or something else for  
>> aligning real-world entities and concepts.
>>
>> > By the way, some of the SKOS properties (especially the
>> > prefLabel/altLabel/hiddenLabel semantics) can be useful in a  
>> broad range
>> > of applications. Eg. dbpedia itself could be used as a great  
>> source for
>> > synonym candidates by mapping the resources to skos:Concept and the
>> > labels for dbpedia:redirect resources to skos:altLabel.
>>
>> Yup, it has a lot of useful annotation terms. They are all declared  
>> to be annotation properties and deliberately don't have  
>> skos:Concept in their domain. So you can use them on anything which  
>> is great!
>>
>> Regards,
>>  Simon
>>
>>
>> [1] http://archive.ifla.org/VII/s13/frbr/frbr_current5.htm#5.2 -  
>> scroll down to "5.2.3 Subject Relationships"
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports  
>> 2008 30-Day trial. Simplify your report design, integration and  
>> deployment - and focus on what you do best, core application  
>> coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Dbpedia-discussion mailing list
>> Dbpedia-discussion@...
>> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>>
>
>
> --
>
>
> Regards,
>
> Kingsley Idehen      Weblog: http://www.openlinksw.com/blog/~kidehen
> President & CEO OpenLink Software     Web: http://www.openlinksw.com
>
>
>
>
>

--------------
I have my new work email address: jgraybeal@...
--------------

John Graybeal   <mailto:jgraybeal@...>
phone: [phone]
Development Manager
Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org
Marine Metadata Interoperability Project: http://marinemetadata.org

[Pat Hayes]

On Nov 4, 2009, at 6:43 AM, Leonard Will wrote:

> On Wed, 4 Nov 2009 at 08:15:18, Alexandre Passant <alexandre.passant@...
> > wrote
>> I think that is the question that should be answered here.
>> The SKOS spec says: "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."
>>
>> So, do the SKOS implementors consider that, while subjective,  
>> anything can be allowed to go under skos:Concept ?
>> If not, shouldn't a disjunction be introduced in SKOS to prevent  
>> that ?
>>
>> I find all these SKOS properties more that useful, but that  
>> subjectivity regarding skos:Concept is imo an issue - I personally  
>> limit the use of skos:Concept to non-physical objects / abstract  
>> notions, but since that's subjective, someone else will use it for  
>> anything, e.g. foaf:Person, and may lead to disagreement between us  
>> - and related applications.
>>
>> Thanks,
>>
>> Alex.
>
> From the point of view of thesaurus standards, "concept" is used  
> with a very general meaning - "unit of thought" - which was  
> introduced to distinguish between that and the various different  
> "terms" that may be used to label it. A concept is defined by its  
> scope note, if present, and/or by its various terms and relationships.
>
> In a thesaurus, concepts are divided into several disjoint facets,  
> such as people, objects, activities, disciplines, places, times, and  
> "abstract concepts" such as "peace", "friendship", "intellectual  
> property" and so on.

I have to say, I find this extremely puzzling. Taking the second  
paragraph at face value, so that 'people' means actual living people,  
etc.,. then none of these real things are in what I would understand  
the category "unit of thought" to be. Both that opaque phrase and the  
word "concept" are usually understood to have some kind of  
psychological connection. The concept of an object is not the object  
itself, precisely because the concept, but not the object, can indeed  
be the stuff of a thought: a concept is an idea of a thing, not the  
actual thing. One cannot burn a concept, or make love to it, or kill  
it. One cannot usually even observe it. One can however learn it, or  
form it mentally, or fail to understand it: none of which can be done  
to physical things. And even if one slurs the use/mention distinction  
(a bad idea, but even if) so that this is understood to refer to the  
object of a thought, the thing the thought is *about*, it still is a  
very odd notion. Most things in the universe have never been thought  
about. There are surely objects that have never been thought about and  
never will be thought about (a particular grain of sand on a beach  
during the fall of Carthage) so which cannot ever be a "unit of  
thought" even in this broken sense of being the referent (rather than  
the content) of a thought.

BTW, there is yet another problem with the phrase "unit of thought",  
which is its presumption that thoughts can be divided into "units".  
But let us leave that issue aside, as the other is more pressing.

There seems to be a problem in the very heart of the SKOS design. Is  
it talking about things, or about concepts of things? Y'all really  
need to get this straight before proceeding.

>
> The choice of these facets may vary in different applications;  
> "people" could be part of an "organisms" facet, for example, and  
> might or might not include "organisations" or "groups of people".
>
> As SKOS was developed to handle thesaurus structures, I believe that  
> the use of "concept" in SKOS is in accordance with this. Mrs Obama  
> is an "instance" of a concept within the "people" facet.

Mrs Obama is a living, breathing human being. To my mind, that is  
enough to prevent her ever being a concept. She may well have a  
concept of herself, and others also may have concepts of her. But none  
of these concepts of her are the lady herself.

Pat Hayes

>

>
> Leonard Will
>
> --
> Willpower Information     (Partners: Dr Leonard D Will, Sheena E Will)
> Information Management Consultants            Tel: [phone]
> 27 Calshot Way                              L.Will@...
> ENFIELD                                Sheena.Will@...
> EN2 7BQ, UK                            http://www.willpowerinfo.co.uk/
>
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[kidehen]

John Graybeal wrote:

>> Thus, far I've simply assumed that skos:exactMatch and owl:sameAs
>> have similar implementation mechanics re. union expansion, but their
>> use targets vary i.e. skos:exactMatch works better for Concept
>> Schemes (where the world view assumes Named Entities e.g., "People"
>> aren't Concepts) while owl:sameAs works better for Named Entities
>> (people, places, and other typical real more things, so to speak).
>
> I'm sorry, but my understanding of the semantics of owl:sameAs seems
> to be different than is being implied here -- can someone address this
> explicitly?
>
> I have always understood owl:sameAs to link (very tightly!) one
> on-line resource to another.  For example, I could say that my URL is
> referring to exactly the same concept as someone else's URN.

You mean: URIs referring to the same thing, from our vantage point,
hence the owl:sameAs relation connecting the two Entity (Data Item or
Object) Identifiers.
> So anything said about one concept now applies to the other, if sameAs
> is used. Maybe what's confusing me in this exchange is that I could
> imagine several different URLs that refer to an individual person (for
> example), but present that individual in different contexts, and the
> things they say are relative to the context.
Simple example of owl:sameAs between to Entities:

1.  http://tr.im/Eg85 -- holistic view of Entity: Kingsley Idehen in a
Quad Store. Click on direct co-references tab to see the different
identifiers for said entity, then use the settings tab to enable
"owl:sameAs" context rule

2. With owl:sameAs context enabled, click on each Identifier in the
direct co-reference tab, you will get a union expansion of all the data
across the Identifiers in that tab. Basically, irrespective of choosen
Identifier, you get a  union of all the data across all the entities in
the relation

3. Go back to settings, and uncheck the "owl:sameAs" option, and repeat
step #2, you will see specific data associated with the each of the
Identifiers, so the data will vary on an Identifier basis

You can even repeat the above with custom rules, and see the effects of
these assertions, albeit explicitly scoped to specific user context.
> Even though the individuals at http://mywork.com/staff/joebob,
> http://joebobfamily.name/joebob, and foaf:person=joebob are the same
> person, that does not mean that owl:sameAs is an acceptable linkage of
> those 3 resources.  Which suggests "owl:sameAs works better for Named
> Entitites" is not a good practice to follow, doesn't it?
It works for People, Places, and other things that we subjectively deem
to be "Named Entities".  Of course, the definition of skos:exactMatch
would imply delivery of similar behavior when you assert an  
"skos:exactMatch" between Concepts, using via their URIs.

So back to my question re. the meaning of "smushing": I assume you do
mean union expansion of the data exposed by the Entities referenced in
the relation, in either case. But, the difference between owl:sameAs and
skos:exactMatch, in this particular case, comes down to Entity Type in
the relations i.e., Named Entities (owl:sameAs) or Concepts
(skos:exactMatch).

Kingsley

>
> John
>
>
>
> On Nov 5, 2009, at 1029, Kingsley Idehen wrote:
>
>> Neubert Joachim wrote:
>>> Hi Simon,
>>> Sorry for causing some misunderstanding: My point was not that you
>>> SHOULD use skos:Concept. What I rather wanted to say is that it does
>>> no harm and that it's already in use for named entites.  This point
>>> arises from the suggestion to use skos:exactMatch/closeMatch. These
>>> properties are sub-sub-properties of skos:semanticRelation, which
>>> entails that subject and object of these properties are instances of
>>> skos:Concept (since skos:Concept are domain and range for
>>> skos:semanticRelation).
>>> The great advantage of skos:exactMatch/closeMatch (over owl:sameAs)
>>> is that their semantic doesn't smush the resources with all their
>>> properties (like the administrative properties you mentioned).
>> Joachim,
>>
>> What do you mean by "smush" are you referring to the union expansion
>> that results from combing data from all the data sources in the
>> owl:sameAs relation? I pose my question with the skos:exactMatch
>> description page URL [1] for context. I see Transitivity and
>> Symmetry, which are factors re. decision making by reasoners re:
>> union expansion based on participants in the relation. Note, by
>> "union expansion" I mean the union of all data associated with the
>> data items in the relation.
>>
>> Primarily, I just want clarification about "smushing",  relative to
>> the property definition exposed by the skos:exactMatch URI,  more
>> than anything else. Thus, far I've simply assumed that
>> skos:exactMatch and owl:sameAs have similar implementation mechanics
>> re. union expansion, but their use targets vary i.e. skos:exactMatch
>> works better for Concept Schemes (where the world view assumes Named
>> Entities e.g., "People" aren't Concepts) while owl:sameAs works
>> better for Named Entities (people, places, and other typical real
>> more things, so to speak).
>>
>>
>> Links:
>>
>> 1.
>> http://linkeddata.uriburner.com/about/html/http/www.w3.org/2004/02/skos/core%01exactMatch 
>>
>>
>> Kingsley
>>> [SNIP]
>>> ..
>>> Cheers, Joachim
>>>
>>> ------------------------------------------------------------------------
>>>
>>> *Von:* Simon Reinhardt [mailto:simon.reinhardt@...]
>>> *Gesendet:* Do 05.11.2009 17:35
>>> *An:* Neubert Joachim
>>> *Cc:* Richard Cyganiak; dbpedia-discussion@...;
>>> SKOS; Pat Hayes
>>> *Betreff:* Re: AW: [Dbpedia-discussion] Using DBpedia resources as
>>> skos:Concepts?
>>>
>>> Hi
>>>
>>> Neubert Joachim wrote:
>>> > In my eyes, it's completely ok to use skos:exactMatch or
>>> skos:closeMatch
>>> > in a situation like this (I did it myself for the STW Thesaurus for
>>> > Economics mapping to dbpedia).
>>> > > Thesauri and classifications are not restricted to abstract
>>> concepts.
>>> > Some thesauri deal explicitly with individual things, e.g. the widely
>>> > used Getty "Thesaurus of Geographic Names" or "Union List of Artist
>>> > Names". Other thesauri (like STW) have sections (or facets, as
>>> Leonard
>>> > put it) on geografic names along with others containing "pure"
>>> concepts.
>>> > SKOS, as I understand it, is intended to cover all this and to be
>>> used
>>> > beyond strict class hierarchies or class/individual dichotomies.
>>>
>>> While I agree that using real-world entities for classification is
>>> ok I don't think this means you have to declare them to be
>>> (skos:)concepts. The "has subject" relationship in FRBR [1] for
>>> example can link a work to a concept but also to places, people,
>>> events, other works, etc. So in this case you can use real-world
>>> entities to classify the work (to state what its subjects are) but
>>> that doesn't mean you declare all those entities to be conceptual.
>>>
>>> So in my eyes there's still value in keeping (skos:)concepts and
>>> other things apart. Concepts to me are closer to classes than to
>>> individuals. And as Dan pointed out concepts have administrative
>>> data attached - they get created and changed etc. so they're
>>> basically units of organisation.
>>>
>>> I'd therefore prefer using the UMBEL terms or something else for
>>> aligning real-world entities and concepts.
>>>
>>> > By the way, some of the SKOS properties (especially the
>>> > prefLabel/altLabel/hiddenLabel semantics) can be useful in a broad
>>> range
>>> > of applications. Eg. dbpedia itself could be used as a great
>>> source for
>>> > synonym candidates by mapping the resources to skos:Concept and the
>>> > labels for dbpedia:redirect resources to skos:altLabel.
>>>
>>> Yup, it has a lot of useful annotation terms. They are all declared
>>> to be annotation properties and deliberately don't have skos:Concept
>>> in their domain. So you can use them on anything which is great!
>>>
>>> Regards,
>>>  Simon
>>>
>>>
>>> [1] http://archive.ifla.org/VII/s13/frbr/frbr_current5.htm#5.2 -
>>> scroll down to "5.2.3 Subject Relationships"
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day trial. Simplify your report design, integration and
>>> deployment - and focus on what you do best, core application coding.
>>> Discover what's new with
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> ------------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Dbpedia-discussion mailing list
>>> Dbpedia-discussion@...
>>> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>>>
>>
>>
>> --
>>
>>
>> Regards,
>>
>> Kingsley Idehen          Weblog: http://www.openlinksw.com/blog/~kidehen
>> President & CEO OpenLink Software     Web: http://www.openlinksw.com
>>
>>
>>
>>
>>
>
>
> --------------
> I have my new work email address: jgraybeal@...
> --------------
>
> John Graybeal   <mailto:jgraybeal@...>
> phone: [phone]
> Development Manager
> Ocean Observatories Initiative Cyberinfrastructure Project:
> http://ci.oceanobservatories.org
> Marine Metadata Interoperability Project: http://marinemetadata.org
>
>

--


Regards,

Kingsley Idehen      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO
OpenLink Software     Web: http://www.openlinksw.com

[Pat Hayes]

On Nov 5, 2009, at 1:25 PM, John Graybeal wrote:

>> Thus, far I've simply assumed that skos:exactMatch and owl:sameAs  
>> have similar implementation mechanics re. union expansion, but  
>> their use targets vary i.e. skos:exactMatch works better for  
>> Concept Schemes (where the world view assumes Named Entities e.g.,  
>> "People" aren't Concepts) while owl:sameAs works better for Named  
>> Entities (people, places, and other typical real more things, so to  
>> speak).
>
> I'm sorry, but my understanding of the semantics of owl:sameAs seems  
> to be different than is being implied here -- can someone address  
> this explicitly?
>
> I have always understood owl:sameAs to link (very tightly!) one on-
> line resource to another.

Strictly, it relates a resource to itself, and to nothing else. Its  
use is to say that two URIs refer to the same resource. If AAA sameAs  
BBB, then there is one resource being talked about, and the two names  
'AAA' and 'BBB' both refer to it. NOte that this is entirely to do  
with what the names refer to, not about things like which name is  
'best' for a given purpose, who 'owns' the name, etc..

>  For example, I could say that my URL is referring to exactly the  
> same concept as someone else's URN.

Right, but...

> So anything said about one concept now applies to the other, if  
> sameAs is used.

Not exactly. Because if the sameAs is true, then these are the SAME  
concept. Its not that they are two doppelgangers which can be switched  
for one another. There really is only one thing, which happens to have  
two names. So PatHayes sameAs PatrickJohnHayes does not say that there  
are two of me that are interchangeable, it says that there is one me  
with two different names.

> Maybe what's confusing me in this exchange is that I could imagine  
> several different URLs that refer to an individual person (for  
> example), but present that individual in different contexts, and the  
> things they say are relative to the context.

Exactly, and the whole basis for the OWL language model is that there  
is just one (global) context within which RDF/OWL reasoning is done.  
If we were to introduce contexts explicitly, then the sameAs  
substitutivity would be blocked, but so would just about all the rest  
of OWL/RDF inferencing. A can be a subclass of B in one context but  
not in another, etc..

> Even though the individuals at http://mywork.com/staff/joebob, http://joebobfamily.name/joebob 
> , and foaf:person=joebob are the same person, that does not mean  
> that owl:sameAs is an acceptable linkage of those 3 resources.

But all that owl:sameAs says is that they are indeed the same (person,  
in this case.) And they are, right? So why is this a problem?  
(Apparently because people read more into sameAs than it was designed  
to carry.)

>  Which suggests "owl:sameAs works better for Named Entitites" is not  
> a good practice to follow, doesn't it?

Agree, this dictum makes no sense at all.

Pat Hayes

>
> John
>
>
>
> On Nov 5, 2009, at 1029, Kingsley Idehen wrote:
>
>> Neubert Joachim wrote:
>>> Hi Simon,
>>> Sorry for causing some misunderstanding: My point was not that you  
>>> SHOULD use skos:Concept. What I rather wanted to say is that it  
>>> does no harm and that it's already in use for named entites.  This  
>>> point arises from the suggestion to use skos:exactMatch/
>>> closeMatch. These properties are sub-sub-properties of  
>>> skos:semanticRelation, which entails that subject and object of  
>>> these properties are instances of skos:Concept (since skos:Concept  
>>> are domain and range for skos:semanticRelation).
>>> The great advantage of skos:exactMatch/closeMatch (over  
>>> owl:sameAs) is that their semantic doesn't smush the resources  
>>> with all their properties (like the administrative properties you  
>>> mentioned).
>> Joachim,
>>
>> What do you mean by "smush" are you referring to the union  
>> expansion that results from combing data from all the data sources  
>> in the owl:sameAs relation? I pose my question with the  
>> skos:exactMatch description page URL [1] for context. I see  
>> Transitivity and Symmetry, which are factors re. decision making by  
>> reasoners re: union expansion based on participants in the  
>> relation. Note, by "union expansion" I mean the union of all data  
>> associated with the data items in the relation.
>>
>> Primarily, I just want clarification about "smushing",  relative to  
>> the property definition exposed by the skos:exactMatch URI,  more  
>> than anything else. Thus, far I've simply assumed that  
>> skos:exactMatch and owl:sameAs have similar implementation  
>> mechanics re. union expansion, but their use targets vary i.e.  
>> skos:exactMatch works better for Concept Schemes (where the world  
>> view assumes Named Entities e.g., "People" aren't Concepts) while  
>> owl:sameAs works better for Named Entities (people, places, and  
>> other typical real more things, so to speak).
>>
>>
>> Links:
>>
>> 1. http://linkeddata.uriburner.com/about/html/http/www.w3.org/2004/02/skos/core%01exactMatch
>>
>> Kingsley
>>> [SNIP]
>>> ..
>>> Cheers, Joachim
>>>
>>> ------------------------------------------------------------------------
>>> *Von:* Simon Reinhardt [mailto:simon.reinhardt@...]
>>> *Gesendet:* Do 05.11.2009 17:35
>>> *An:* Neubert Joachim
>>> *Cc:* Richard Cyganiak; dbpedia-discussion@...;  
>>> SKOS; Pat Hayes
>>> *Betreff:* Re: AW: [Dbpedia-discussion] Using DBpedia resources as  
>>> skos:Concepts?
>>>
>>> Hi
>>>
>>> Neubert Joachim wrote:
>>> > In my eyes, it's completely ok to use skos:exactMatch or  
>>> skos:closeMatch
>>> > in a situation like this (I did it myself for the STW Thesaurus  
>>> for
>>> > Economics mapping to dbpedia).
>>> > > Thesauri and classifications are not restricted to abstract  
>>> concepts.
>>> > Some thesauri deal explicitly with individual things, e.g. the  
>>> widely
>>> > used Getty "Thesaurus of Geographic Names" or "Union List of  
>>> Artist
>>> > Names". Other thesauri (like STW) have sections (or facets, as  
>>> Leonard
>>> > put it) on geografic names along with others containing "pure"  
>>> concepts.
>>> > SKOS, as I understand it, is intended to cover all this and to  
>>> be used
>>> > beyond strict class hierarchies or class/individual dichotomies.
>>>
>>> While I agree that using real-world entities for classification is  
>>> ok I don't think this means you have to declare them to be  
>>> (skos:)concepts. The "has subject" relationship in FRBR [1] for  
>>> example can link a work to a concept but also to places, people,  
>>> events, other works, etc. So in this case you can use real-world  
>>> entities to classify the work (to state what its subjects are) but  
>>> that doesn't mean you declare all those entities to be conceptual.
>>>
>>> So in my eyes there's still value in keeping (skos:)concepts and  
>>> other things apart. Concepts to me are closer to classes than to  
>>> individuals. And as Dan pointed out concepts have administrative  
>>> data attached - they get created and changed etc. so they're  
>>> basically units of organisation.
>>>
>>> I'd therefore prefer using the UMBEL terms or something else for  
>>> aligning real-world entities and concepts.
>>>
>>> > By the way, some of the SKOS properties (especially the
>>> > prefLabel/altLabel/hiddenLabel semantics) can be useful in a  
>>> broad range
>>> > of applications. Eg. dbpedia itself could be used as a great  
>>> source for
>>> > synonym candidates by mapping the resources to skos:Concept and  
>>> the
>>> > labels for dbpedia:redirect resources to skos:altLabel.
>>>
>>> Yup, it has a lot of useful annotation terms. They are all  
>>> declared to be annotation properties and deliberately don't have  
>>> skos:Concept in their domain. So you can use them on anything  
>>> which is great!
>>>
>>> Regards,
>>> Simon
>>>
>>>
>>> [1] http://archive.ifla.org/VII/s13/frbr/frbr_current5.htm#5.2 -  
>>> scroll down to "5.2.3 Subject Relationships"
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports  
>>> 2008 30-Day trial. Simplify your report design, integration and  
>>> deployment - and focus on what you do best, core application  
>>> coding. Discover what's new with
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Dbpedia-discussion mailing list
>>> Dbpedia-discussion@...
>>> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>>>
>>
>>
>> --
>>
>>
>> Regards,
>>
>> Kingsley Idehen      Weblog: http://www.openlinksw.com/blog/~kidehen
>> President & CEO OpenLink Software     Web: http://www.openlinksw.com
>>
>>
>>
>>
>>
>
>
> --------------
> I have my new work email address: jgraybeal@...
> --------------
>
> John Graybeal   <mailto:jgraybeal@...>
> phone: [phone]
> Development Manager
> Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org
> Marine Metadata Interoperability Project: http://marinemetadata.org
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[John Graybeal-3]

On Nov 5, 2009, at 1152, Pat Hayes wrote:

> There seems to be a problem in the very heart of the SKOS design. Is  
> it talking about things, or about concepts of things? Y'all really  
> need to get this straight before proceeding.

Let me use this as a way to propose an answer to the question, and get  
a bigger answer to a related point that's been bothering me.

Let's say SKOS is talking about names for things.  This is once  
removed from the things, obviously -- "Mrs Obama" is a name for the  
person, not the person herself -- but not the concept.  And "person"  
is a name for the type of thing of which "Mrs Obama" is a name for an  
instance.

(There is a metaphysical discussion about the correspondence between a  
'name' and a 'concept', but I'd like to avoid it, as I don't think  
it's central to your question.)

So now I have said I have a name of a type of thing, and the name is  
"person".  Can I say anything semantically that connects this name, in  
a constructive and semantically-friendly and Pat Hayes-agreeable way,  
to the semantic web resource that represents the concept of a human  
being?  (Pick your favorite semantic web resource for representing  
that concept, OK?)

In other words, what is the correct way to connect the semantic web to  
all of these thesaurus and dictionary entities?   (Which I am here  
calling 'names', but elsewhere are called 'terms' and other things, to  
the resource in the semantic web that you've picked above (which for  
many people is associated with a 'concept', but I am avoiding that  
term, hoping that 'resource in the semantic web' is clearer).)

I infer that you would like to say they are not concepts, which is  
fine, but then can we all agree on a paradigm for making the connection?

John

John Graybeal   <mailto:jgraybeal@...>
Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org
Marine Metadata Interoperability Project: http://marinemetadata.org

[kidehen]

Pat Hayes wrote:
>
> On Nov 5, 2009, at 1:25 PM, John Graybeal wrote:
> [SNIP]
>>  Which suggests "owl:sameAs works better for Named Entitites" is not
>> a good practice to follow, doesn't it?
>
> Agree, this dictum makes no sense at all.
Yes, but Named Entities has become a moniker (totally subjective of
course) for People, Places and other so called real things.

Thus, owl:sameAs between two Concepts (which have URIs) is absolutely
fine, but this then begs the question: when specifically does one use
"skos:exactMatch" etc? Based on my response John (few minutes ago), I am
assuming that the partitioning of so called Named Entities and Subject
Matter Concepts was the line of delineation sought in SKOS which is
about Subject Matter/Heading style Concept Schemes?

Personally, owl:sameAs works absolutely fine for a Person, Document, or
Subject Matter Concept or Heading, as long as its about different Names
for the same Thing (in the eyes of the claim maker).

Desperately trying to reconcile specs and general language en route to
clarity etc.

Kingsley

>
> Pat Hayes
>
>>
>> John
>>
>>
>>
>> On Nov 5, 2009, at 1029, Kingsley Idehen wrote:
>>
>>> Neubert Joachim wrote:
>>>> Hi Simon,
>>>> Sorry for causing some misunderstanding: My point was not that you
>>>> SHOULD use skos:Concept. What I rather wanted to say is that it
>>>> does no harm and that it's already in use for named entites.  This
>>>> point arises from the suggestion to use skos:exactMatch/closeMatch.
>>>> These properties are sub-sub-properties of skos:semanticRelation,
>>>> which entails that subject and object of these properties are
>>>> instances of skos:Concept (since skos:Concept are domain and range
>>>> for skos:semanticRelation).
>>>> The great advantage of skos:exactMatch/closeMatch (over owl:sameAs)
>>>> is that their semantic doesn't smush the resources with all their
>>>> properties (like the administrative properties you mentioned).
>>> Joachim,
>>>
>>> What do you mean by "smush" are you referring to the union expansion
>>> that results from combing data from all the data sources in the
>>> owl:sameAs relation? I pose my question with the skos:exactMatch
>>> description page URL [1] for context. I see Transitivity and
>>> Symmetry, which are factors re. decision making by reasoners re:
>>> union expansion based on participants in the relation. Note, by
>>> "union expansion" I mean the union of all data associated with the
>>> data items in the relation.
>>>
>>> Primarily, I just want clarification about "smushing",  relative to
>>> the property definition exposed by the skos:exactMatch URI,  more
>>> than anything else. Thus, far I've simply assumed that
>>> skos:exactMatch and owl:sameAs have similar implementation mechanics
>>> re. union expansion, but their use targets vary i.e. skos:exactMatch
>>> works better for Concept Schemes (where the world view assumes Named
>>> Entities e.g., "People" aren't Concepts) while owl:sameAs works
>>> better for Named Entities (people, places, and other typical real
>>> more things, so to speak).
>>>
>>>
>>> Links:
>>>
>>> 1.
>>> http://linkeddata.uriburner.com/about/html/http/www.w3.org/2004/02/skos/core%01exactMatch 
>>>
>>>
>>> Kingsley
>>>> [SNIP]
>>>> ..
>>>> Cheers, Joachim
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> *Von:* Simon Reinhardt [mailto:simon.reinhardt@...]
>>>> *Gesendet:* Do 05.11.2009 17:35
>>>> *An:* Neubert Joachim
>>>> *Cc:* Richard Cyganiak; dbpedia-discussion@...;
>>>> SKOS; Pat Hayes
>>>> *Betreff:* Re: AW: [Dbpedia-discussion] Using DBpedia resources as
>>>> skos:Concepts?
>>>>
>>>> Hi
>>>>
>>>> Neubert Joachim wrote:
>>>> > In my eyes, it's completely ok to use skos:exactMatch or
>>>> skos:closeMatch
>>>> > in a situation like this (I did it myself for the STW Thesaurus for
>>>> > Economics mapping to dbpedia).
>>>> > > Thesauri and classifications are not restricted to abstract
>>>> concepts.
>>>> > Some thesauri deal explicitly with individual things, e.g. the
>>>> widely
>>>> > used Getty "Thesaurus of Geographic Names" or "Union List of Artist
>>>> > Names". Other thesauri (like STW) have sections (or facets, as
>>>> Leonard
>>>> > put it) on geografic names along with others containing "pure"
>>>> concepts.
>>>> > SKOS, as I understand it, is intended to cover all this and to be
>>>> used
>>>> > beyond strict class hierarchies or class/individual dichotomies.
>>>>
>>>> While I agree that using real-world entities for classification is
>>>> ok I don't think this means you have to declare them to be
>>>> (skos:)concepts. The "has subject" relationship in FRBR [1] for
>>>> example can link a work to a concept but also to places, people,
>>>> events, other works, etc. So in this case you can use real-world
>>>> entities to classify the work (to state what its subjects are) but
>>>> that doesn't mean you declare all those entities to be conceptual.
>>>>
>>>> So in my eyes there's still value in keeping (skos:)concepts and
>>>> other things apart. Concepts to me are closer to classes than to
>>>> individuals. And as Dan pointed out concepts have administrative
>>>> data attached - they get created and changed etc. so they're
>>>> basically units of organisation.
>>>>
>>>> I'd therefore prefer using the UMBEL terms or something else for
>>>> aligning real-world entities and concepts.
>>>>
>>>> > By the way, some of the SKOS properties (especially the
>>>> > prefLabel/altLabel/hiddenLabel semantics) can be useful in a
>>>> broad range
>>>> > of applications. Eg. dbpedia itself could be used as a great
>>>> source for
>>>> > synonym candidates by mapping the resources to skos:Concept and the
>>>> > labels for dbpedia:redirect resources to skos:altLabel.
>>>>
>>>> Yup, it has a lot of useful annotation terms. They are all declared
>>>> to be annotation properties and deliberately don't have
>>>> skos:Concept in their domain. So you can use them on anything which
>>>> is great!
>>>>
>>>> Regards,
>>>> Simon
>>>>
>>>>
>>>> [1] http://archive.ifla.org/VII/s13/frbr/frbr_current5.htm#5.2 -
>>>> scroll down to "5.2.3 Subject Relationships"
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> Let Crystal Reports handle the reporting - Free Crystal Reports
>>>> 2008 30-Day trial. Simplify your report design, integration and
>>>> deployment - and focus on what you do best, core application
>>>> coding. Discover what's new with
>>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> Dbpedia-discussion mailing list
>>>> Dbpedia-discussion@...
>>>> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>>>>
>>>
>>>
>>> --
>>>
>>>
>>> Regards,
>>>
>>> Kingsley Idehen          Weblog:
>>> http://www.openlinksw.com/blog/~kidehen
>>> President & CEO OpenLink Software     Web: http://www.openlinksw.com
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --------------
>> I have my new work email address: jgraybeal@...
>> --------------
>>
>> John Graybeal   <mailto:jgraybeal@...>
>> phone: [phone]
>> Development Manager
>> Ocean Observatories Initiative Cyberinfrastructure Project:
>> http://ci.oceanobservatories.org
>> Marine Metadata Interoperability Project: http://marinemetadata.org
>>
>>
>
> ------------------------------------------------------------
> IHMC                                     [phone] or [phone]
> 40 South Alcaniz St.           [phone]   office
> Pensacola                            [phone]   fax
> FL 32502                              [phone]   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>

--


Regards,

Kingsley Idehen      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO
OpenLink Software     Web: http://www.openlinksw.com