Re: RE : broader and broaderMatch... and BT???

Learning by doing...

A Wiki would allow to document experiments and implementations, to 
propose normalized and extended XML/RDFS schemas for sharing, etc.

A discussion page about recommended conventions when targeting ISO 25964 
compatibility will be nice.

This will support next standardization steps...

Have a nice w.e.

Christophe

Antoine Isaac a écrit :
>
> Hi everyone,
>
> I fully agree with Alistair, and am very curious to hear about what 
> you (especially Johan, Christophe and Stephen, in this thread) would 
> like to have as a solution!
>
> I'd like to answer on Johan's first point in [1]: yes, these best 
> practices/extension may be closely related to different types of KOSs 
> to represent. You can find a a good example of this during our last 
> comment period, if you look at issues 181 to 186 in [2].
>
> Cheers,
>
> Antoine
>
> [1] http://lists.w3.org/Archives/Public/public-esw-thes/2009Feb/0030.html
> [2] http://www.w3.org/2006/07/SWD/track/issues/closed
>
>
> -------- Message d'origine--------
> De: public-esw-thes-request@w3.org de la part de Alistair Miles
> Date: ven. 13/02/2009 15:41
> À: Stephen Bounds
> Cc: public-esw-thes@w3.org
> Objet : Re: broader and broaderMatch... and BT???
>
>
> Hi Stephen,
>
> Yes, this is a great idea. I brought this up withi the WG a while ago,
> the WG has been focused on reaching candidate rec so hasn't discussed
> it yet, but Tom Baker has been very diligent in making sure it stays
> on the agenda.
>
> Do you think a wiki page on the W3C site would be enough to act as a
> "registry" of SKOS extensions? Or do we need more than that?
>
> Cheers,
>
> Alistair
>
> On Fri, Feb 13, 2009 at 07:52:26AM +1100, Stephen Bounds wrote:
> >
> > Hi Alistair,
> >
> > I agree that it's probably too late for changes to be considered to the 
> > core SKOS language.  However, making the extensibility of SKOS 
> > explicitly part of the standard could be a really important benefit.
> >
> > These days, there is a common trend in open-source packages (eg Drupal, 
> > Firefox) for there to be a place for extensions to be registered by the 
> > *owner* of the package (not just hoping that people can publish on 
> their 
> > own web pages and get a sufficient rank on Google).
> >
> > Doing this reduces the proliferation of competing extensions to some 
> > extent and focuses community effort.
> >
> > SKOS sits somewhere between a technology (eg XML) and a software 
> > package.  I believe it could benefit from a similarly endorsed 
> community 
> > extension model.
> >
> > This could be achieved simply by inserting something into the 
> > Recommendation like: "The SKOS standard was built was extensibility in 
> > mind.  A list of unofficial community extensions to SKOS can be 
> found at 
> > http://w3c.org/xxx."  Then, just give people a way for people to submit 
> > their extensions to the SKOS group for listing on a W3C web page.
> >
> > Even better would be the ability to submit under an "extension" subtype 
> > of the W3C, eg http://www.w3.org/2008/05/x-skos/iso#bt.  I can 
> > appreciate that this might be politically difficult to arrange, however.
> >
> > Cheers,
> >
> > -- Stephen.
> >
> > Alistair Miles wrote:
> >> Hi all,
> >>
> >> I'm afraid it is too late in the day to consider addition of new
> >> vocabulary to SKOS in time for the Recommendation schedule. We are
> >> approaching candidate recommendation, and any substantive changes
> >> needed to be considered prior to last call.
> >>
> >> However, if there is consensus that this is an important requirement,
> >> then I would be more than happy to provide an indication to future
> >> working groups that this should be given further consideration.
> >>
> >> In the mean time, anybody is of course free to publish their own
> >> extensions to SKOS, and to disseminate them as a community practice. I
> >> anticipate that many important requirements may only be met through
> >> third party extensions and usage conventions established within the
> >> community. If anyone has any suggestions as to how we might best
> >> support such community efforts, I'd love to hear them--it is on the
> >> agenda for the SWDWG to consider community support, but we're a bit
> >> short of effort at the moment.
> >>
> >> Personally, I don't find a need to introduce a sub-property of
> >> skos:broader that is intended only for use within a single concept
> >> scheme. I find skos:broader to be sufficient, when used in conjunction
> >> with skos:inScheme. I also find skos:broader to correspond perfectly
> >> well to the ISO notion of BT.
> >>
> >> Cheers,
> >>
> >> Alistair
> >>
> >> On Mon, Feb 02, 2009 at 03:17:01PM +0100, Christophe Dupriez wrote:
> >>> I like this proposal !
> >>>
> >>> Is it reasonable to follow it for implementation?
> >>>
> >>> Thanks!
> >>>
> >>> Christophe
> >>>
> >>> Stephen Bounds a écrit :
> >>>> Hi Christophe, Antoine and all,
> >>>>
> >>>> Personally I'm a fan of keeping SKOS terminology self-describing
> >>>> where  possible (and therefore would argue against using
> >>>> "BT"/"NT"/"RT"  within SKOS).
> >>>>
> >>>> A thought -- what about simply using:
> >>>>
> >>>>   skos:broadInScheme
> >>>>   skos:narrowInScheme
> >>>>   skos:relatedInScheme
> >>>>
> >>>> This would then follow a construction similar to skos:broadMatch
> >>>> and  match the terminology of existing vocab terms such as
> >>>> skos:inScheme.
> >>>>
> >>>> Regards,
> >>>> -- Stephen.
> >>>>
> >>>> Christophe Dupriez wrote:
> >>>>> Dear Antoine,
> >>>>>
> >>>>> Reading this (and seing my (reasonable) difficulties to apply
> >>>>> SKOS to real life problems), I would like to insist that the
> >>>>> frame defined by previous ISO standards for thesauri be kept and
> >>>>> supplemented. This  may seem bottom-up compared to the apparent
> >>>>> top-down process to  define SKOS: it is alway better when
> >>>>> stalagmites join stalagtites !
> >>>>>
> >>>>> For my own stuff, I will implement:
> >>>>>
> >>>>> skos:semanticRelation
> >>>>> |
> >>>>> +- skos:related
> >>>>> |   |
> >>>>> |   +- ???:RT
> >>>>> |   |  (disjoint from)
> >>>>> |   +- skos:relatedMatch
> >>>>> |
> >>>>> +- skos:broaderTransitive (disjoint from related and 
> narrowerTransitive)
> >>>>> |   |
> >>>>> |   +- skos:broader
> >>>>> |       |
> >>>>> |       +- ???:BT
> >>>>> |       |  (disjoint from)
> >>>>> |       +- skos:broadMatch
> >>>>> |
> >>>>> +- skos:narrowerTransitive (disjoint from related and 
> broaderTransitive)
> >>>>>     |
> >>>>>     +- skos:narrower
> >>>>>         |
> >>>>>         +- ???:NT
> >>>>>         |  (disjoint from)
> >>>>>         +- skos:narrowMatch
> >>>>>
> >>>>>
> >>>>> Please note that "BT <union> broadMatch" does not cover "broader"
> >>>>>  because "broader" may cross scheme boundaries and "BT" cannot.
> >>>>> If you add the concept of "subScheme" (micro-thesaurus), "BT"
> >>>>> should  not cross micro-thesaurus borders.
> >>>>>
> >>>>> With "RT", you can cross micro-thesaurus borders but not scheme  
> >>>>> boundaries.
> >>>>>
> >>>>
> >>>>
> >>
> >>> begin:vcard
> >>> fn:Christophe Dupriez
> >>> n:Dupriez;Christophe
> >>> org:DESTIN inc. SSEB
> >>> adr;quoted-printable:;;rue des Palais 44, bo=C3=AEte 
> 1;Bruxelles;;B-1030;Belgique
> >>> email;internet:Christophe.Dupriez@Destin.be
> >>> title:Informaticien
> >>> tel;work:+32/2/216.66.15
> >>> tel;fax:+32/2/242.97.25
> >>> tel;cell:+32/475.77.62.11
> >>> note;quoted-printable:D=C3=A9veloppement de Syst=C3=A8mes de 
> Traitement de l'Information
> >>> x-mozilla-html:TRUE
> >>> url:http://www.destin.be
> >>> version:2.1
> >>> end:vcard
> >>>
> >>
> >>
> >
>
> --
> 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
>
>