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

RE: Global concept identification and reference: Published Subjects and decentrally provided identification points for notions

From: Houghton,Andrew <houghtoa@oclc.org>
Date: Fri, 12 Nov 2004 10:46:17 -0500
Message-ID: <D53793AA582576458786FBE27899DB181E8722@OAEXCH2SERVER.oa.oclc.org>
To: <public-esw-thes@w3.org>
Cc: "tm-pubsubj" <tm-pubsubj@lists.oasis-open.org>

> -----Original Message-----
> From: Bernard Vatant [mailto:bernard.vatant@mondeca.com] 
> Sent: 12 November, 2004 09:54
> To: public-esw-thes@w3.org; Houghton,Andrew
> Cc: tm-pubsubj
> Subject: RE: Global concept identification and reference: 
> Published Subjects and decentrally provided identification 
> points for notions
> > The argument made by the PSI folks that anyone can issue PSI's is 
> > fundamentally flawed.
> I like this kind of frontal attack ...

Actually, it wasn't meant to be a frontal attack, or an attack at all, merely an overzealous statement ;-)  As I have pointed out in a prior message, "fundamentally flawed" was an overstatement on my part...

> Could you explain what makes for you the difference between a 
> "KOS publisher", and "anyone" publishing a KOS? If it's a 

I took "anyone" in the PSI document to mean a non-KOS publisher.  Someone who is not realted to the publisher of the KOS, but may have an interest in using the KOS.  Hence the need to create PSI's when they are unavailable from the KOS publisher.  Anyone publishing a KOS would fall under a "KOS publisher".  That's how I interpreted the PSI document when I read it.

> > Some KOS publishers will not be willing to use PSI's due to 
> > intellectual property concerns, but might be willing to 
> provide opaque 
> > URI's to concepts in their KOS.
> This is something I have hard time to understand, actually. 
> How do you figure folks will use identifiers defined in your 
> namespace if you don't provide clear, non-ambiguous 
> descriptions of the subjects those identifiers identify (read 
> : subject indicators). The risk in doing so is, either to see 
> users turn towards other identifiers, maybe less trustable, 
> but for which subject indicators are available, or to see 
> less reliable third parties provide second-hand hacked 
> subject indicators for your own identifiers. Both are bad 
> scenarios to consider IMO.

KOS publishers, are generally concerned with intellectual property.  It takes a lot of time and money to maintain and keep a KOS current.  These costs have to be recouped, in some fashion, if the KOS publisher is to say in business.  Some KOS publishers may have concerns about putting intellectual property, in any digital form.  They only have to look at what is happening in the music and video space to add to their concerns.  I am merely pointing out those concerns.

So how would folks use identifiers defined in the KOS's namespace without clear, non-ambiguous descriptions of the concepts?  A scenario might be that the identifiers are used in *conjunction* with a printed version of the KOS or a subscriber only online service.  It's clear that the printed version scenario breaks the PSI requirement that the PSI *must* resolve to a human readable Web resource.  The subscriber only online service scenario, less so.  However, in either scenario the concepts *are* clear and non-ambiguous.  It's just that unless you have *access*, the identifier of the concept may not be clear to a human.  Machines can still aggregate like URI's.

> But maybe you think we have to live in a world with 
> "proprietary concepts" and "open-source concepts", with the 
> same arguments about quality as in any other proprietary vs 
> open-source debate.

Ahh... I knew a counter attack was lurking around a corner ;-))  I am agnostic about proprietary vs. open-source, each has their place.  I wasn't raising a proprietary vs. open-source debate.  Merely pointing out that business models and intellectual property use cases need to developed during the standards process and possibly written into a standard.  When a standard demonstrates how proprietary and open-source can co-exist, then the standard will be more widely adopted in both communities.

Received on Friday, 12 November 2004 15:47:05 UTC

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