RE: Blank nodes for concepts.

> I don't see why something as well as a URI is necessary.
Yup, that's the crux of it.
If we insist on the use of URIs for unambiguous identification, the problem
goes away.

It depends how useful/essential an 'identify by description' capability is.
The experience of the foaf project might help us answer that?

Steve

> -----Original Message-----
> From: Charles McCathieNevile [mailto:charles@w3.org] 
> Sent: 07 February 2004 13:15
> To: Cayzer, Steve
> Cc: 'Miles, AJ (Alistair) '; 'public-esw-thes@w3.org'
> Subject: RE: Blank nodes for concepts.
> 
> 
> 
> I don't see why something as well as a URI is necessary.
> 
> The idea of the semantic web is that URIs are identifiers, 
> good for identifying "things". There are some things they are 
> good at identifying. One is actual pages on the web, since 
> these already have a URI. But there are also "concepts" - 
> things that have a way of identifying them, and various 
> descriptions. We can give them a name (URI) or we can just 
> describe them (as blank nodes).
> 
> 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 03:48:05 UTC