OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [tm-pubsubj] Vocabulary: will we get rid of "PSI" or not?


Bernard Vatant wrote:
[...]
> To sum it up and try to clarify, once again:
> 
> It was considered in Orlando that "Published Subject Indicator", and worse its
> abbreviation PSI, was overloaded, ill-defined and misleading. It was not clear if it was a
> resource or the reference of the resource, or both. Moreover, it did not make any
> difference between the publisher and the topic map author viewpoint.
> That's why the notion was torn to pieces and revisited throughout in Orlando. We finally
> decided not to restrict or refine the meaning of PSI, but to let it down altogether. Was
> it a good move? I think it was, because we clarified somehow the situation. So, are we
> definitely rid of PSIs? Not quite it seems. Let's try to explain once again.

Yikes. I was unaware of what happened in Orlando, so this is news to me. I
think the concept of a PSI is very valuable (hence my involvement in this TC),
and the idea of using a URI as an identifier of a subject is to me the best
way imaginable to provide this functionality. I can certainly see the difficulties,
but that's what I think the Pubsubj TC is going to address. If we can remove
some of the ambiguities and provide recommendations for best practices, we'll
have a "technology" suitable for using in other communities (and I'm thinking
specifically of the CG, KIF, RDF/DAML+OIL communities, as well as others related).
 
> There is vocabulary describing the publisher viewpoint. I capitalize the terminology to
> highlight it, it is not capitalized in the TC documents.
> 
> 1. Published Subject is a subtype of Subject. It is not necessarily addressable, but it is
> *documented* in a proper way. But the Published Subject *is not* the documentation about
> it.

Understood and agreed.

> 2. Published Subjects Documentation is providing stable
> identification/documentation/definition/description of/about a set of Subjects, therefore
> becoming Published Subjects - if they were not yet : the same Subject can be documented by
> different publishers in different Published Subjects Documentations.

Understood and agreed, though I'm not certain I want to see this as an acronym
just yet.
 
> 3. The part of a Published Subjects Documentation providing
> identification/documentation/definition/description of/about *one* Subject is a Subject
> Definition Document, or better, following recent proposition, *Subject Definition
> Resource*, since it can be only a document node.

Makes sense to me. The result of a database query may be a resource describing
a subject, and that resource may be a document (in any format or notation), a
resource within a document), or perhaps even something else. I'm considering 
(in the work with PORT) the idea that a small area of a Peircean manuscript as
displayed from a TIFF image may be a useful and important subject, and with a
suitable tool, could be an addressable subject. 
 
> Now we have the viewpoint of the Topic Map author, who may use whatever resource he wants
> to indicate a subject identity.
> 
> 4. Subject Indicator is a resource used by a Topic Map author to identify a subject.
> Hopefully, it is a Subject Definition Resource (in a relevant Published Subjects
> Documentation). At least that is the best practice to recommend to topic maps authors. But
> it cannot be made mandatory or inforced, because some times the author won't find any
> available Subject Definition Resource, and will pick whatever she'll find, hoping the
> resource chosen is stable both in address and content. And hoping it fits really the need.
> Declaring Subject Indicator is in the full responsibility of the TM author. It does not
> involve the Subject Indicator publisher, not even aware of it. If the TM breaks because
> this Subject Indicator is not trustable, it's not the responsibility of the publisher of
> the resource, who certainly never declared it was trustable, nor even intended to define
> any subject with it. And there is no way for the topic map author to make *any* resource a
> (proper) Subject Definition Resource just by pointing at it, saying "Hey, don't you move
> anymore, I've PSI-ed you".

Understood. I think we all must accept that the world is continually changing. 
With my move to England I'll be dismantling (actually just not paying the bill)
my doctypes.org web site. As a student I can't justify it anymore. And then you
find that Very Large Corporations (like Enron) go belly up, change their name,
or merge with others, and their web pages disappear. There is not stability in
this world, only relative stability. And not all topic maps are meant to last
forever, perhaps only for a few months.

With this in mind we can only ask authors/publishers to do what they are able
to declare subject indicators that are "likely" to be stable. And to maintain
their topic maps, checking for broken links, etc. We can't entirely escape
the problems of the web, or the world. The only way would be to not connect
with the web or the world, by using URNs, by not interconnecting our topic maps
to the rest of that changing, addressable space. I don't think anyone would 
suggest that here.

But for example, I contacted Doug Lenat and asked him how stable the Cyc HTML
pages were as URLs, and he said that they had no plans to change them, and 
that the next version of Cyc beyond 2.1 would use a different set of web
pages. You can often tell by the URL if it's dated or versioned, and then it's
a matter of whether or not older versions will stay online. But if Cyc changed
its name, merged with Enron, or ended operations, well, yes, these subject
indicators would have no documentation. They'd still be suitable subject
indicators, but would have no addressable resource as documentation. It behooves
me as a PSI author/publisher to make sure any client of mine using my Cyc topic
maps has a local (eg. CD-ROM) copy of the Cyc documentation (for example).
 
> 5. Subject Indicator Reference is the URI used in <subjectIndicatorRef>. This is purely
> technical, and it's completely again the TM author viewpoint.

Yes, this is an important distinction. It took years for the community to
begin making the distinction between "URI" and "URI reference."
 
> In that context "Published Subject Indicator" could still be used in a consistent way, in
> the (recommended) situation where the TM author has indeed be wise enough to use as
> Subject Indicator a conformant Subject Definition Resource. Therefore I would propose, if
> you like, to keep "PSI" but with the following definition, pointing at a full agreement,
> trust and tuning between a Subject Documentation Publisher and a TM Author.
> 
> "A Published Subject Indicator is a Subject Definition Resource used as a Subject
> Indicator"
> 
> If we don't get over with that one, I surrender ...

I get your point but as written it almost sounds like a tautology.
 
> Bottom line: I guess the XTM editors did not make this distinguo, either because they
> focused more on the TM author viewpoint than on the publisher's, or because they were
> already projecting themselves in the realm of a "Web of Intelligence and Trust" where this
> distinction would be obsolete because of such an abundancy of Subject Definition Resources
> that chosing something else for Subject Indicator would be silly - and moreover there
> would not be silly TM authors any more.

I don't know if the editors had thought it out that far. My memory of
conversations during that time is that there was a stress on the use
of URIs as subject indicators (and URI references as subject indicator
references, as above), and that "published" was meant to convey some
attempt on the author's part of choosing a *relatively* stable URI for
that purpose. I've not understood yet what changes are necessary to
that landscape, sorry if my head is a bit thick on this one.

Murray

...........................................................................
Murray Altheim, Staff Engineer          <mailto:murray.altheim&#64;sun.com>
Java and XML Software
Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025

       Ernst Martin comments in 1949, "A certain degree of noise in 
       writing is required for confidence. Without such noise, the 
       writer would not know whether the type was actually printing 
       or not, so he would lose control."


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC