RE: Issue with collections

Hi Sue Ellen,
 
Where did you get the phrase 'semantic label' from?  I don't remember writing it anywhere...
 
Cheers,
 
Al.
 
P.s. holiday was rather good thanks :)

-----Original Message-----
From: Sue Ellen Wright [mailto:sellenwright@gmail.com]
Sent: 24 August 2005 05:48
To: Miles, AJ (Alistair); Alan Melby; Gil Francopoulo
Subject: Re: Issue with collections


Hi, Alistair,
I'm not sure whether this is going to the list or just to you, but whatever. We have a problem with the name "semantic label". Whenever we mention it to a group of linguists, the fall apart in gales of laughter. I'm not kidding. To us every single relational label in the whole system is a semantic label at some level within the system. We don't understand from your explanations what the significance of this piece of the puzzle is, and the example I believe is either missing or inoperative in the Vocabulary page. Can you point us to a spot where we can gain enlightenment? 
Bye for now & hope you're having a great holiday. Poland is sunny & warm, but we're all in meetings, alas.
Sue Ellen

 
On 8/23/05, Miles, AJ (Alistair) < A.J.Miles@rl.ac.uk> wrote: 


Hi Mark,

> Good catch, this should be moved to the proposed changes (as soon as
> we have a solution). 

Agreed.

> The consequence of your observation on the range of SemanticRelation
> seems to be that it is impossible to link the collections into the
> hierarchy with narrower/broader.

Not necessarily ... 

> I can think of two solutions now:
>
> 1) special property
>
> Use a special property e.g. "narrowerNodeLabel" to link a
> skos:Concept
> to a collection. This property shouldn't be a SemanticRelation to 
> avoid the problem you discovered. And add a rule
>
> (?x skos:narrowerNodeLabel ?c) (?c skos:member ?m)
> ->
> (?x skos:narrower ?m)
>
> so that each member of the collection is automatically narrower than 
> the concept to which the collection is linked with narrowerNodeLabel.
>

This type of structure is worth considering as an option.

>
> 2) outside of the hierarchy
>
> Because the concepts in a node label/array are always narrower than 
> some other concept C, we can just construct the narrower/broader
> hierarchy as usual, and store the information on their being a member
> of a specific nodelabel elsewhere (outside the hierarchy).
>
> Concept1
>       ConceptA        -> memberOf  nodeLabel1
>       ConceptB        -> memberOf  nodeLabel1
>       ConceptC        -> memberOf  nodeLabel2
>       ConceptD        -> memberOf  nodeLabel2 
>
> nodeLabel1 and nodeLabel2 are instances of a class NodeLabel on which
> a property nodeLabelName with range string is defined.
>

This doesn't work, because a concept may have more than one broader concept, in which case it becomes ambiguous where the node label should be displayed.  To work around this, you would have to have an additional property to explicitly state which concept the node label should be displayed under.  This was in fact of one of the originally suggested solutions to the problem of displaying node labels and guide terms at the correct place in the hierarchy, see the section 'Issue: nesting an array in the hierarchy of concepts' which is at the end of [1].  [1] was writted before we thought up the 'collectable property' idea, which was initially proposed at [2]. 

In fact, structurally your two solutions are identical, because your proposed 'narrowerNodeLabel' in option 1 would be the inverse of the additional property (e.g. 'displayUnder') required by option 2.

There is another option (call it 'option 3')... 

---
Remove the following statement:
---

skos:semanticRelation rdfs:range skos:Concept .

---
Add the following statements:
---

skos:ConceptOrCollection a rdfs:Class;
owl:unionOf (skos:Concept, skos:Collection) . 

skos:Concept rdfs:subClassOf skos:ConceptOrCollection;
owl:disjointWith skos:Collection .

skos:Collection rdfs:subClassOf skos:ConceptOrCollection;
owl:disjointWith skos:Concept .

skos:semanticRelation rdfs:range skos:ConceptOrCollection . 

---
... Then if someone was creating their own semantic relation property, but didn't want to allow use with collections, they could specify e.g.:
---

eg:mySemanticRelation a rdf:Property;
rdfs:subPropertyOf skos:semanticRelation . 

skos:Concept subClassOf [
a owl:Restriction;
owl:onProperty eg:mySemanticRelation;
owl:allValuesFrom skos:Concept;
].

---

What do you think?

Cheers,

Al.


[1] http://esw.w3.org/topic/SkosDev/SkosCore/CollectionsAndArrays
[2] http://lists.w3.org/Archives/Public/public-esw-thes/2004Oct/0072.html  <http://lists.w3.org/Archives/Public/public-esw-thes/2004Oct/0072.html> 



>
>
> Miles, AJ (Alistair) wrote:
> > Hi all,
> >
> > I just realised we have an issue with current recommended
> usage of the 'meaningful collections' bit of SKOS Core [1]. 
> It goes like this:
> >
> > The whole point of the skos:Collection class was so that we
> could *avoid* representing a node label such as 'milk by
> source animal' or 'people by age' as a label for a concept. 
> The current consensus is that node labels are *not* labels
> for concepts, and should not be modelled as such.
> >
> > However, to allow node labels to still be rendered as part
> of a hierarchical display, we had to invent the extremely 
> cunning skos:CollectableProperty class, with the associated
> 'collectable properties rule', see [2].
> >
> > But, if we allow stuff like ...
> >
> > @prefix ex: <  <http:///www.example.com/concepts#> http:///www.example.com/concepts#> .
> > # other namespaces as standard
> >
> > ex:milk a skos:Concept;
> >   skos:narrower _:node1;
> > .
> >
> > _:node1 a skos:Collection; 
> >   rdfs:label 'Milk by source animal';
> >   skos:member ex:goatmilk;
> >   skos:member ex:cowmilk;
> >   skos:member ex:yakmilk;
> > .
> >
> > ... then because ... 
> >
> > skos:narrower rdfs:subPropertyOf skos:semanticRelation .
> >
> > ... and ...
> >
> > skos:semanticRelation rdfs:range skos:Concept .
> >
> > ... we end up with the inference that ... 
> >
> > _:node1 a skos:Collection, skos:Concept .
> >
> > ... which is the very thing we were trying to avoid - doh!
> >
> > I'm not sure how best to fix this right now, I'll have a 
> think when I get back from hols.
> >
> > Cheers,
> >
> > Al.
> >
> > [1]
> http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20050510/#se  <http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20050510/#se> 
ccollections
> [2] http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20050510/#seccollectable
> ---
> Alistair Miles 
> Research Associate
> CCLRC - Rutherford Appleton Laboratory
> Building R1 Room 1.60
> Fermi Avenue
> Chilton
> Didcot
> Oxfordshire OX11 0QX
> United Kingdom
> Email:         a.j.miles@rl.ac.uk
> Tel: +44 (0)1235 445440
>
>

--
Mark F.J. van Assem - Vrije Universiteit Amsterdam
       mark@cs.vu.nl  <mailto:mark@cs.vu.nl> - http://www.cs.vu.nl/~mark






-- 
Sue Ellen Wright
Institute for Applied Linguistics
Kent State University
Kent OH 44242 USA 
sellenwright@gmail.com
swright@kent.edu
sewright@neo.rr.com