FW: Single value for soks:prefLabel ?

-----Original Message-----
From: Miles, AJ (Alistair) 
Sent: 09 February 2004 13:58
To: 'Charles McCathieNevile'
Subject: Single value for soks:prefLabel ?


OK, let's have a go at making this argument clear.

I've said, that the soks:prefLabel property is NOT inverse functional.  That
is, two concepts may have exactly the same soks:prefLabel value.  

However, as a point of good practise in constructing a conceptual scheme
such as a thesaurus, the creator(s) should ensure that no two concepts from
their scheme have the same value for soks:prefLabel.  

This then means that the value for soks:prefLabel can be used to uniquely
identify concepts within that particular scheme.  (This idea is second
nature to thesaurus developers.  For them, not allowing two identical
descriptor-terms into a thesaurus is axiomatic.)

So there's three options for soks:prefLabel.

1.  soks:prefLabel should be used so that it uniquely identifies a concept
globally (inverse functional).

2.  soks:prefLabel should be used so that it uniquely identifies a concept
within a conceptual scheme (in effect inverse functional within a given
scope).

3.  soks:prefLabel doesn't uniquely identify anything at any level.

(1) is obviously impractical.  (2) could be useful.  (3) is most flexible.  

Personally, I say that we write the support documentation to strongly
recommend users implement their thesauri in SKOS adhering to (2).  This then
gives them the option of working with terms only, and
reference-by-description, if they want to.  But obviously there is nothing
to stop users breaking (2) and doing whatever they like.  The only
consequence is, they lose the ability to have people reference their
concepts via the soks:prefLabel property.   

Chaals: what do you say to all that?

Al.

> 
> And I think it's a bad idea to insist on a single preferred label.
> 
> Words are what people use becausee we don't have blank nodes. 
> They aren't
> equivalent to URIs, because we already know that they are duplicated,
> ambiguous, overloaded. But we're stuck with them as 
> identifiers, since we
> can't look up URIs in our head. (We also have descriptions, 
> and we end up
> using a mixture of the two to try and disambiguate concepts).
> 
> If two concepts have the same labels and descritptions, they 
> might be the
> same. It's certainly a useful working assumption. But a few long
> philosophical discussions are enough to realise that often 
> you can spend
> hours talking about something before realising that each 
> person is talking a
> bout a different thing - and then you disambiguate it by adding some
> qualifying information that is unique to one of the options.
> 
> So we can use identical graphs for two blank concept nodes to 
> assert that
> they are the same, for a given purpose. Or we can use a URI. 
> In either case,
> we have the important ability to go further, and subclass the 
> concept perhaps
> in two or more ways.
> 
> Cheers
> 
> Chaals
> 
> On Fri, 6 Feb 2004, Cayzer, Steve wrote:
> 
> >I think Al's point is that we need *some* way to uniquely 
> identify concepts
> >other than by URI (ie by description) [Al - correct me if I'm wrong!]
> >
> >One way is to insist on only one prefLabel per thesaurus.
> >It sounds like you think this is an unreasonable constraint 
> (which might be
> >true). So if that's the case, what property/ies should we 
> use? Is there a
> >concept equivalent of foaf:mbox ?
> >
> >
> >> -----Original Message-----
> >> From: Charles McCathieNevile [mailto:charles@w3.org]
> >> Sent: 06 February 2004 09:14
> >> To: Cayzer, Steve
> >> Cc: 'Miles, AJ (Alistair) '; 'public-esw-thes@w3.org'
> >> Subject: RE: Blank nodes for concepts.
> >>
> >>
> >>
> >> On Fri, 6 Feb 2004, Cayzer, Steve wrote:
> >>
> >> >
> >> >That's my reading of (b)
> >> >
> >> >b.  A combination of the concept's prefLabel and the URI of the
> >> >thesaurus to which it belongs.
> >> >
> >>
> >> to expand on my example
> >>
> >>  <Concept>
> >>    <prefLabel>Bar</prefLabel>
> >>    <altLabel>Baz</altLabel>
> >>    <rdf:isDefinedBy
> >> rdf:resource="http://example.com/concepts?easyToFind"/>
> >>  </Concept>
> >>  <Concept>
> >>    <prefLabel>Bar</prefLabel>
> >>    <altLabel>Foo</altLabel>
> >>    <rdf:isDefinedBy
> >> rdf:resource="http://example.com/concepts?worksForPWD"/>
> >>  </Concept>
> >>
> >> seems reasonable, or am I missing something?
> >>
> >> Hmm. I am assuming you point to the term definition, not just
> >> the thesaurus it is in. But  I think even if I pointed to the
> >> latter (i.e. the thesaurus defines a concept with two
> >> prefLabels) there would be nothing to stop the thesaurus from
> >> defining two concepts with the same prefLabel and different
> >> alternative labels. And I don't see there is anything wrong
> >> with deciding to name a concept definition:
> >>
> >>  <Concept rdf:about="#foo">
> >>    <prefLabel>Bar</prefLabel>
> >>    <altLabel>Foo</altLabel>
> >>    <rdf:isDefinedBy
> >> rdf:resource="http://example.com/concepts?worksForPWD"/>
> >>  </Concept>
> >>
> >> it just gives you a way to refer to this definition. ?
> >>
> >> cheers
> >>
> >> chaals
> >>
> >> >> -----Original Message-----
> >> >> From: Charles McCathieNevile [mailto:charles@w3.org]
> >> >> Sent: 06 February 2004 01:05
> >> >>
> >> >> doesn't give you any right to infer that the two balnk
> >> nodes are the
> >> >> same (this would be that case if you made prefLabel map 1:1 with
> >> >> concepts but I think that's a bad idea anyway).
> >> >>
> >> >> Looking at user scenarios, there is an obvious cost to two
> >> concepts
> >> >> having the same preferred label - whenever you want to classify
> >> >> something by that label you need to be clear which one you
> >> mean. On
> >> >> the benefit side, you might well have a term that commonly
> >> refers to
> >> >> a couple of different concepts, and want to be easily 
> able to look
> >> >> for things with the preferred Label.
> >> >>
> >> >> "accessible" is the example that springs to mind in my everyday
> >> >> stuff. I suspect in putting vocbularies together it's 
> also useful.
> >> >>
> >> >> Cheers
> >> >>
> >> >> Chaals
> >> >>
> >> >> On Thu, 5 Feb 2004, Steve Cayzer wrote:
> >> >>
> >> >> >
> >> >> >Makes sense to me.
> >> >> >
> >> >> >Might be worth adding an explanation to one of the docos, both
> >> >> >technical (as
> >> >> >below) and non technical (implication - you can't add a new
> >> >> concept with the
> >> >> >same prefLabel as another concept in the same thesaurus)
> >> >> >
> >>
> >
> 
> Charles McCathieNevile  http://www.w3.org/People/Charles  
> tel: +61 409 134 136
> SWAD-E http://www.w3.org/2001/sw/Europe         fax(france): 
> +33 4 92 38 78 22
>  Post:   21 Mitchell street, FOOTSCRAY Vic 3011, Australia    or
>  W3C, 2004 Route des Lucioles, 06902 Sophia Antipolis Cedex, France
>

Received on Monday, 9 February 2004 08:59:03 UTC