W3C home > Mailing lists > Public > public-esw-thes@w3.org > July 2004

RE: [Proposal] [SKOS-Core] Initial term_status values

From: Miles, AJ (Alistair) <A.J.Miles@rl.ac.uk>
Date: Thu, 29 Jul 2004 15:11:37 +0100
Message-ID: <350DC7048372D31197F200902773DF4C05E50B59@exchange11.rl.ac.uk>
To: "'public-esw-thes@w3.org'" <public-esw-thes@w3.org>

I suggested skos:Concept skos:broader skos:narrower skos:related as
'testing' because I thought the rdfs:comments could be tightened up, but I
wasn't anticipating any change in the way they are used (i.e. I agree with
Dan that we pretty much know what we mean by these things, but thought we
could probably express it better).

My interpretation of 'stable' was that once a term is 'stable' that's
essentially a guaranteee that nothing about it will ever change (although it
may still be deprecated).

I'm glad to see the rdfs:comments from the schema getting a bit of
discussion - I always thought they could be improved.


Alistair Miles
Research Associate
CCLRC - Rutherford Appleton Laboratory
Building R1 Room 1.60
Fermi Avenue
Oxfordshire OX11 0QX
United Kingdom
Email:        a.j.miles@rl.ac.uk
Tel: +44 (0)1235 445440

> -----Original Message-----
> From: public-esw-thes-request@w3.org
> [mailto:public-esw-thes-request@w3.org]On Behalf Of Dan Brickley
> Sent: 29 July 2004 09:45
> To: Charles McCathieNevile
> Cc: Miles, AJ (Alistair) ; 'public-esw-thes@w3.org'
> Subject: Re: [Proposal] [SKOS-Core] Initial term_status values
> * Charles McCathieNevile <charles@w3.org> [2004-07-29 01:27-0400]
> > 
> > Hmm. So essentailly we expect to be able to change any 
> definition of any part
> > of SKOS? I am not sure that this is a good idea - and in 
> particular I suspect
> > that Concept is actually stable, and probably the {broad,narrow}er*
> > properties...
> > 
> > what do you think?
> Defining 'broader' could probably chew up a bunch more time.
> As for Concept, depends what you mean by stable. I've been meaning to
> suggest that the rdfs:comment isn't quite right actually (sorry
> Alistair!).
> <rdfs:comment>A concept is any unit of thought that can be defin
> ed or described.</rdfs:comment>
> This is a strong cognitive science claim about the nature and 
> structure
> of (human?) thought. It also relies on notions that some but not necc
> all 'units of thought' are definable or describable. 
> I think "Concept" is stable in that we all somehow have the 
> rough notion 
> of what we're trying to say there. Whether the specific text of
> rdfs:comment used totally captures that is another matter. 
> "A Concept is the idea of something"
> "A conceptualization of a thing"
> "The idea of an idea"
> ...etc.
> Regarding "broader", we currently have:
>   <rdfs:comment>This property carries weak semantics.  It may be u
> sed to state that the object is in some way more general in 
> meaning than
> the sub
> ject.  Essentially it provides a means of organising concepts into a
> hierarchy (
> tree), without being restrictive about the exact semantic implications
> of the hi
> erarchical structure itself.  Extend this property to create 
> properties
> that car
> ry stronger semantics, but may be reduced to a hierarchical structure
> for simple
>  visual displays.</rdfs:comment>
> (and no specification of domain or range).
> I would be suprised if this definition remained precisely 
> unchanged over
> the next year. For starters it is defined (textually if not 
> formally) in
> terms of Concept, so what we say about Concept affects meaning of this
> property. If concepts are really 'units of thought' then that
> constrains, perhaps, the ways in which they can be 'organised into
> hierarchies'. 
> It would be pretty awful if every little tweak to these definitions
> meant that a whole new namespace had to be deployed. Dublin Core went
> down that path once and folk are still, years later, writing code to
> merge back together the dc 1.0 and dc 1.1 namespaces, which 
> are for all 
> practical purposes identical in content, just described slightly
> differently.
> Dan
Received on Thursday, 29 July 2004 10:12:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:03 UTC