W3C home > Mailing lists > Public > public-esw-thes@w3.org > August 2005

Re: Issue with collections

From: Mark van Assem <mark@cs.vu.nl>
Date: Wed, 24 Aug 2005 11:03:24 +0200
Message-ID: <430C37DC.5060507@cs.vu.nl>
To: "Miles, AJ \(Alistair\)" <A.J.Miles@rl.ac.uk>, public-esw-thes@w3.org


Hi Alistair,

(good to have a driving force behind SKOS back from vacation :-)

>>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 ...

Because of your option three in which you remove the range from
skos:semanticRelation you mean?

<snip solutions>

> 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].

Ah yes, I read past that part... So that solution was already proposed.

> 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 a difference in that the one requires a rule and the other
does not. Of course this difference can be removed by also explicitly
adding the skos:narrower relations from Concept1 to the concepts
contained in the collection.

In general it feels "cleaner" to me to having solutions without rules.
A rule means the set of triples is not "complete" and interpretation
can only be done after the implied triples are added. Of course,
without the rules the interpretation can be the difficult part, but at
least the set of triples is "complete".

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

<snip solution three>

> 
> skos:semanticRelation rdfs:range skos:ConceptOrCollection .

Shouldn't the domain of skos:semanticRelation also be
skos:ConceptOrCollection?

Is the disjointness between Collection and Concept that you add 
something that is already tacitly assumed in the current spec?

Stylistic remark: you can also dispense with the ConceptOrCollection
class and define the range of skos:semanticRelation to be the unionOf
Concept and Collection. Unless you really need/want a URI for the class.


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

Yes - but the semantics of semanticRelation have first changed 
(widened range), so it can indeed be narrowed again using OWL 
restrictions. Question is if we want that widened semantics for 
semanticRelation?


I have three remarks on option three:

1) somehow option three doesn't "feel right" because the collections 
are still part of the hierarchy.

2) this solution requires OWL, and I think we discussed earlier that
our position on usage of OWL is not clear yet, in which case the other
RDF solutions are perhaps better/safer?

3) the broader/narrower hierarchy cannot be used anymore to infer that 
a resource is a concept (in the case of absence of explicit rdf:type 
skos:Concept triples) - which can be done in the other solutions.

Cheers,
Mark.

-- 
  Mark F.J. van Assem - Vrije Universiteit Amsterdam
        mark@cs.vu.nl - http://www.cs.vu.nl/~mark
Received on Wednesday, 24 August 2005 09:03:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:53 GMT