Re: ISSUE-130 draft response

I have neglected the response to this issue. There was some subsequent
discussion, but I hear no objections to the response as written below.

I'm on holiday until 17 Nov, so in the interests of progress I will
send the response as-is. I hope this is ok, if there are any problems
we can always reconsider our position.

Thanks,

Alistair.


On Wed, Oct 01, 2008 at 03:30:34PM +0100, Alistair Miles wrote:
> 
> Hi all,
> 
> Here's a draft response to Kjetil on [ISSUE-130], let me know what you
> think. Note *this is just a draft, not the actual response* -- I'll
> wait for feedback from the WG before replying formally to
> Kjetil. (Kjetil if you're lurking on this list feel free to post your
> thoughts at any time.)
> 
> --
> Dear Kjetil,
> 
> Many thanks for your comments and suggestions [1]. In respect of your following comment:
> 
> """
> We have defined a 
> sub:isMainConceptOf  a owl:ObjectProperty ; 
>             rdfs:range skos:ConceptScheme ;
>             rdfs:domain skos:Concept ;
>             owl:inverseOf skos:hasTopConcept . 
> so it was great to see that skos:topConceptOf is in! Please keep it there, it 
> is simply much easier for us to use it in development with the present 
> architecture.
> 
> I haven't followed the debate since this first was debated, but I would like 
> to bring this up again: I do not like the naming of skos:hasTopConcept and 
> skos:topConceptOf. As long as there are associative relationships in the 
> system, it seems meaningless to make the hierarchical relationships more 
> prominent than the associative by connecting this property to the hierarchy. 
> 
> So, that's why I called my inverse of skos:hasTopConcept isMainConceptOf. I 
> think something like that would be better. 
> 
> I haven't thought too carefully about it, but what if:
> 
> <S> rdf:type skos:ConceptScheme ;
>   skos:hasTopConcept <B> .
> 
> <B> rdf:type skos:Concept .
> 
> <A> rdf:type skos:Concept ;
>         skos:related <B> .
> 
> would this be consistent?
> 
> I think that's fairly inevitable in our system, and it would certainly break 
> things if we couldn't do this. What if <B> skos:broader <C> . ?
> """
> 
> As stated in the SKOS Primer [3], the skos:hasTopConcept provides an
> efficient access to the entry points of broader/narrower concept
> hierarchies. This property allows you to link a concept scheme to the
> (possibly many) most general concepts it contains, as in the
> (continued) animal thesaurus example:
> 
> ex:animalThesaurus rdf:type skos:ConceptScheme;
>   skos:hasTopConcept ex:mammals;
>   skos:hasTopConcept ex:fish.
> 
> A typical use of this property is to find and display the top levels
> of a thesaurus in a tree browsing interface. Because this is such a
> common requirement, we felt that it makes sense to have a property
> such as skos:hasTopConcept which is designed to complement the
> broader/narrower links in the scheme. If you require some other
> mechanism for identifying entry points into a concept scheme which is
> not dependent on broader/narrower links, we suggest you define a
> custom property for this purpose. Can you live with this?
> 
> On the subject of conventions and integrity conditions, the SKOS
> Reference [2] states that the property skos:hasTopConcept is, by
> convention, used to link a concept scheme to the SKOS concept(s) which
> are topmost in the hierarchical relations for that scheme.
> 
> It was felt that a usage convention was sufficient to promote
> interoperability in this case. Also there is no convenient way to
> state an equivalent formal integrity condition using either RDFS or
> OWL. Therefore, the graph below, whilst not strictly adhering
> to the usage convention for skos:hasTopConcept, is nevertheless
> formally consistent with the SKOS data model.
> 
> <MyScheme> skos:hasTopConcept <MyConcept> .
> <MyConcept> skos:broader <AnotherConcept> .
> <AnotherConcept> skos:inScheme <MyScheme> .
> 
> How an application should handle this data is not formally defined for
> SKOS.  
> 
> There are neither usage conventions nor integrity conditions governing
> the interaction between skos:hasTopConcept and skos:related. Therefore
> the graph below is formally consistent with the SKOS data model.
> 
> <MyScheme> skos:hasTopConcept <MyConcept> .
> <MyConcept> skos:related <AnotherConcept> .
> <AnotherConcept> skos:inScheme <MyScheme> .
> 
> We are not aware of any use cases which suggest we define either usage
> conventions or integrity conditions prohibiting such a graph.
> 
> Can you live with this?
> 
> Kind regards,
> 
> Alistair Miles
> Sean Bechhofer
> 
> [ISSUE-130] http://www.w3.org/2006/07/SWD/track/issues/130
> [1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Sep/0015.html
> [2] http://www.w3.org/TR/2008/WD-skos-reference-20080829/
> [3] http://www.w3.org/TR/2008/WD-skos-primer-20080829/
> 
> -- 
> Alistair Miles
> Senior Computing Officer
> Image Bioinformatics Research Group
> Department of Zoology
> The Tinbergen Building
> University of Oxford
> South Parks Road
> Oxford
> OX1 3PS
> United Kingdom
> Web: http://purl.org/net/aliman
> Email: alistair.miles@zoo.ox.ac.uk
> Tel: +44 (0)1865 281993
> 

-- 
Alistair Miles
Senior Computing Officer
Image Bioinformatics Research Group
Department of Zoology
The Tinbergen Building
University of Oxford
South Parks Road
Oxford
OX1 3PS
United Kingdom
Web: http://purl.org/net/aliman
Email: alistair.miles@zoo.ox.ac.uk
Tel: +44 (0)1865 281993

Received on Thursday, 6 November 2008 18:03:28 UTC