W3C home > Mailing lists > Public > public-esw-thes@w3.org > November 2003

Re: Design Issue (4) - constraining 'descriptor'/'prefLabel' card inality for multilingual thesauri

From: Dan Brickley <danbri@w3.org>
Date: Fri, 7 Nov 2003 12:44:06 -0500
To: "Miles, AJ (Alistair) " <A.J.Miles@rl.ac.uk>
Cc: "'Cayzer, Steve'" <Steve.Cayzer@hp.com>, "'NJ Rogers, Learning and Research Technology'" <Nikki.Rogers@bristol.ac.uk>, Dave Reynolds <der@hplb.hpl.hp.com>, "'public-esw-thes@w3.org'" <public-esw-thes@w3.org>
Message-ID: <20031107174406.GN26667@w3.org>

Yup, generally rdf:Alt is pretty bad. There is also currently language
in the spec that says something like "the first value is the default". 
Which may be I18N-unwise, if we hold the English and French text in the 
example below to be equally good characterisations of the concept.

My understanding of 1st is that it means the rdf:_1 property, so a
workaround would be to use 

	 <rdf:_2 xml:lang="en">Bangers and mash(cuisine)</rdf:li>
	 <rdf:_3 xml:lang="fr">Saucisson et pomme de terre Anglais</rdf:li>

(since only rdf:_1 is considered the default)

...instead. In fact I just proposed this (tasteless hack!) as a
workaround in the RDFCore telecon today.

You could, if you like the basic data structure, do something 
with the same shaped graph as your proposal, just not use rdf:Alt.
eg. invent a class to replace Alt, and named properties (or rdf:value
perhaps) for the pointers from its instance to the bits of lang-tagged
text.

Backing up a bit, is there a lot of value in having a cardinality 
constraint on soks:descriptor? 

<soks:Concept>
 <soks:descriptor xml:lang="en">Bangers and mash (cuisine)</soks:descriptor>
 <soks:descriptor xml:lang="fr">Saucisson et pomme de terre Anglais</soks:descriptor>
</soks:Concept>

...looks good to me. Is it significantly more annoying for some classes
of user, implementation etc?

Dan




* Miles, AJ (Alistair)  <A.J.Miles@rl.ac.uk> [2003-11-07 17:20-0000]
> 
> Hey Steve,
> 
> Yeah I got really excited when I read the spec about rdf:Alt containers,
> because this seemed a way to keep the cardinality of the soks:descriptor
> property to one and still have language alternatives.  The RDF specs and the
> DC in RDF specs have examples doing things this way.  
> 
> So e.g.
> 
> <soks:Concept>
> 	<soks:descriptor>
> 		<rdf:Alt>
> 			<rdf:li xml:lang="en">Bangers and mash
> (cuisine)</rdf:li>
> 			<rdf:li xml:lang="fr">Saucisson et pomme de terre
> Anglais</rdf:li>
> 		</rdf:Alt>
> 	</soks:descriptor>
> </soks:Concept>
> 
> However Danbri sent me a mail back saying that rdf:Alt is no good because
> there is no consistent notion of 'alternative' behind it.  Danbri, is this
> really no go?
> 
> Al.  
> 
> -----Original Message-----
> From: Cayzer, Steve [mailto:Steve.Cayzer@hp.com]
> Sent: 07 November 2003 14:34
> To: 'NJ Rogers, Learning and Research Technology'; Dave Reynolds; Miles,
> AJ (Alistair)
> Cc: 'public-esw-thes@w3.org'
> Subject: RE: Design Issue (4) - constraining 'descriptor'/'prefLabel'
> cardinality for multilingual thesauri
> 
> 
> 
> First mail to list - hi all! so sorry if I've missed vital context.
> 
> 1. sound like a workable fallback 
> 2. works but adds inference load 
> 3. Urgh! This is similar to the classic subclassing error of OO modelling
> (imo) - except it's subproperty of course.
> 
> What about saying (apologies for any N3 errors)
> <concept> 
>    :hasDescriptor [:inLanguage <French>; :value "chaud"];   
>    :hasDescriptor [:inLanguage <English>; :value "hot"] .
> 
> Or, if you want to keep cardinality constraints, add a level of indirection
> <concept> 
>    :hasDescriptor [:alternative [:inLanguage <French>; :value "chaud"];
> :alternative [:inLanguage <English>; :value "hot"]] .
> 
> Steve
> > -----Original Message-----
> > From: NJ Rogers, Learning and Research Technology 
> > [mailto:Nikki.Rogers@bristol.ac.uk] 
> > Sent: 07 November 2003 12:14
> > To: Dave Reynolds; Miles, AJ (Alistair)
> > Cc: 'public-esw-thes@w3.org'
> > Subject: Re: Design Issue (4) - constraining 
> > 'descriptor'/'prefLabel' cardinality for multilingual thesauri
> > 
> > 
> > 
> > Hi Alistair and Dave,
> > >
> > >> This does have consequences for constraining the data model.  It 
> > >> means a node typed as a 'soks:Concept' must then be 
> > allowed to have 
> > >> multiple 'soks:descriptor' properties, one for each 
> > language.  Is it 
> > >> then possible in OWL to express the constraint that a concept may 
> > >> have one and only one 'soks:descriptor' property for each language?
> > >
> > > Only if you represent content-in-a-specific-language as a 
> > class, which 
> > > would mean having a different class and different cardinality 
> > > constraint for every language. Which probably wouldn't be workable.
> > >
> > I've been trying to consider some options here:
> > 
> > ***********
> > 1. throw out the 'descriptor' cardinality constraint for multilingual 
> > thesauri (as well as for/as distinct from monolingual 
> > thesauri?) and don't 
> > worry about it - live with it, & provide recommendation of use
> > 
> > instead.
> > 
> > ***********
> > 2. model multilingual thesauri in a specific way: express 
> > each language's
> > 
> > interpretation of a concept uniquely by giving the same 
> > concept different 
> > uri's in each of the languages in question. Then map the 
> > concepts (using 
> > "owl:equivalentTo").  That way we could still specify exactly 
> > 1 preferred 
> > label/'descriptor' per concept. Does it upset us to give 
> > different uri's to 
> > what certain communities believe to be the same concept? I guess how 
> > inferencing is then conducted over the thesaurus data (for 
> > queries) is then 
> > critical & I haven't thought about this in any depth. 
> > Therefore I'm not 
> > sure if this approach is currently "legal".
> > 
> > ***********
> > 3. Subclass 'soks:Concept' with what we'd understand to be 
> > concepts in the 
> > context of a particular language. I think this is similar to 
> > what Dave is 
> > referring to? And yes, it feels cranky:
> > 
> > e.g.
> > 
> > 'soks:Concept'
> >    |
> >    |
> > 'soks:English_concept'
> > 
> > Then we'd potentially have multiple properties (e.g. 
> > soks:english_language_concept, soks:japenese_language_concept 
> > etc.) hanging 
> > off any one 'soks:Concept' in a thesaurus schema.
> > [I guess 'soks:english_language_concept' has domain 
> > 'soks:Concept' and 
> > range 'soks:English_concept' ....]
> > Using this approach, we can keep the cardinality constraint = 1 for 
> > 'soks:descriptor' properties (because there would be one for each of 
> > 'soks:English_concept', 'soks:Japenese_concept', etc)?
> > [I suppose 'soks:English_concept' could be further subclassed for 
> > American_english etc.]
> > However, typically, one then feels that further constraints are now 
> > required to protect data integrity. Such as a constraint that the 
> > 'descriptor' property value for any [Language]_concept must 
> > be in the same 
> > language as that [Language]_concept bla bla.
> > 
> > Hmmm ... :-)
> > 
> > Nikki
> > 
> > > But in any case you need to add the qualifier "in any given 
> > conceptual 
> > > scheme". That definitely makes expressing the cardinality 
> > constraint 
> > > in OWL unworkable.
> > >
> > > Dave
> > >
> > >
> > 
> > 
> > 
> > ----------------------
> > NJ Rogers, Technical Researcher
> > (Semantic Web Applications Developer)
> > Institute for Learning and Research Technology (ILRT) 
> > Email:nikki.rogers@bristol.ac.uk
> > Tel: +44(0)117 9287096 (Direct)
> > Tel: +44(0)117 9287193 (Office)
> > 
Received on Friday, 7 November 2003 12:44:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:08 UTC