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

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

Received on Thursday, 12 February 2009 20:53:15 UTC