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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj-comment message

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


Subject: [tm-pubsubj-comment] Comments on my strawman


Here at last is the description of the strawman PSI set that I posted a
couple of weeks ago, including a whole bunch of issues. I would
appreciate any comments, especially on the specific issues, but please
deal with each issue in a separate thread.

While reading this, you should refer to the XTM document at

    http://psi.ontopia.net/ontopia/ontopia.xtm

which can also be view in the Omnigator at

   http://www.ontopia.net/omnigator/models/topicmap_complete.jsp?tm=ontopia.xtm

I also make some references to "psdoc.htm", which is the TC draft at

   http://www.oasis-open.org/committees/tm-pubsubj/docs/recommendations/psdoc.htm


GENERAL POINTS
--------------

The first point to note is that I have chosen to express my subject
indicators as topics in a topic map. I believe there will be substantial
benefits to using a machine processable syntax and, in particular, topic
maps, for published subjects. Although we have agreed not to REQUIRE any
particular syntax, I think we should RECOMMEND using XTM and provide
examples of how to do so.

* Issue: What are the arguments for using a machine processable syntax?
* Issue: Should we recommend use of XTM?

However, in recognition of the fact that topic map software is not yet
ubiquitous, I have also created a (machine generated) HTML rendition of
the subject indicators, available at

   http://psi.ontopia.net/ontopia/

If we decide to recommend using XTM or other machine processable
syntaxes, I think we should also recommend this approach.


OVERVIEW OF THE PSI SET TOPIC MAP
---------------------------------

ontopia.xtm starts with a directive to merge in another topic map.
(Ignore this for the time being; I will return to it later.)

The topic map contains five topics. Four of these are published subject
indicators (for the topics "ontopia", "oks", "omnigator", and "pepper",
respectively). The fifth topic (ID "topicmap") reifies the topic map. I
will discuss the purpose of the "topicmap" topic shortly. However, its
presence does raise one issue immediately:

* Issue: If we use topics as PSIs, should it be possible to distinguish
topics that are *intended* to be used as PSIs from other topics (in the
same map) that are not?

I think it should. The mechanism I have used is a self-referential
subject identity. For example, the topic "ontopia" has its subject
identity defined through a subject indicator reference with the URL

   "http://psi.ontopia.net/ontopia/ontopia.xtm#ontopia"

-- in other words, it points to itself. Even an application that has not
retrieved the topic map from its canonical location can know that this
is the case because the "identifier" of the topic map is set to the URL

   "http://psi.ontopia.net/ontopia/ontopia.xtm"

through an occurrence on the "topicmap" topic. (More about this later.)

I'm not sure this is a good solution for distinguishing between PSI
topics and non-PSI topics, but I got it for free, because I am using
that subject indicator reference to specify the identifier of the
published subject. (See the subhead "IDENTIFIER" in the next section.)

I'm not sure how else we might differentiate PSI topics from non-PSI
topics. Creating a PSI for PSIs and making the PSI topics instances of
this type is not an alternative, because that would amount to saying
that, say, (the company) Ontopia is an instance of the class Published
Subject Indicator, which it obviously is not.


PSI METADATA
------------

(This section discusses how I handle the items listed under "4.4 -
Information provided by published subject indicators" in psdoc.htm, viz.
identifier, name, type, description, and equivalence.)

IDENTIFIER: The identifier of my published subjects is specified, as I
have already said, using a subjectIndicatorRef subelement of the
subjectIdentity element:

   <topic id="ontopia">
     <subjectIdentity>
       <subjectIndicatorRef
         xlink:href="http://psi.ontopia.net/ontopia/ontopia.xtm#ontopia"/>
     </subjectIdentity>
     ...
   </topic>

NAME: I provide a single name in the unconstrained scope for each of my
PSI topics. None of them are language dependent, so this should be OK.
But what if the names *are* language dependent? Should we recommend
scoping by natural language in that case? Should we *require* it if the
PSI set metadata claims to be in a certain language?

* Issue: Should names be required?

* Issue: Should we recommend (or recommend against) scoping names by
natural language?

TYPE: I have not formally specified a type for any of my PSI topics,
partly because I don't feel the need to and partly because there are (as
yet) no established PSIs for "company", "software product", and
"person", so it wouldn't buy me a lot. On the other hand, I *have*
specified types informally in some of my definitions, so... This is an
issue we should discuss. We might want to make recommendations one way
or the other.

* Issue: Should we recommend (or recommend against) formally specifying
the type of a PSI topic (i.e., the class to which its subject belongs)?

DESCRIPTION: Each of my PSI topics has a description in the form of an
(inline) occurrence of type

   http://psi.topicmaps.org/pubsubj/pubsubj.xtm#description

The descriptions are in English and are scoped as such. I think we
should encourage both multiple descriptions in different languages and
the use of scope (with GeoLang PSIs).

* Issue: Should descriptions be required?

EQUIVALENCE: I'm not sure this property should even be included. Stating
equivalence involves making an assertion, which is a quite different
activity than providing a binding point for subject identity. Assertions
about equivalence should rather be made in a separate topic map, through
topics with multiple subject indicators.

Obviously, one has to make *some* assertions in order for the document
to have any meaning, but these should be restricted to names and
descriptions.


PSI SET METADATA
----------------

(This section discusses how I handle the items listed under "4.2 -
Publisher and documentation metadata" in psdoc.htm, viz. dc:publisher,
dc:identifier, dc:format, dc:source, dc:contributor, dc:title,
dc:language, dc:date, and dc:rights.)

Since my PSI set is expressed as a topic map, I chose to hang the
metadata for the PSI set off a topic that reifies the topic map, what I
call the "topic map topic" (TMT). This is the topic with the ID
"topicmap". It reifies the topic map because its subject identity is
established by a subject indicator reference to the <topicMap> element:

   <topicMap
       id="ontopia-as"
       ... >
     ...
     <topic id="topicmap">
       ...
       <subjectIdentity>
         <subjectIndicatorRef xlink:href="#ontopia-as"/>
       </subjectIdentity>
       ...

The TMT is also an instance of the class "PSI set", for which I created
another PSI:

   <topic id="topicmap">
     <instanceOf>
       <subjectIndicatorRef
         xlink:href="http://psi.topicmaps.org/pubsubj/pubsubj.xtm#psiset"/>
     </instanceOf>
     ...

The TMT now represents the PSI set, and its characteristics (i.e. its
names, occurrences, and association roles) can carry all necessary
metadata, as follows:

+ IDENTITY OF THE PUBLISHER (DC:PUBLISHER)
   An association between the TMT and the topic "ontopia" (which happens
   to already be in the topic map as a PSI).
   PSIs for association type and association role types:
   - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#publishedBy
   - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#publisher
   - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#publication

+ IDENTITY OF THE DOCUMENTATION SET (DC:IDENTIFIER)
   An occurrence of the TMT
   PSI for occurrence type:
   - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#identifier

+ FORMAT (DC:FORMAT)
   NOT USED

+ SOURCE OF DOCUMENTATION (DC:SOURCE)
   NOT USED

+ CREATOR (DC:CREATOR)
   An association between the TMT and the topic "pepper" (which happens
   to already be in the topic map as a PSI).
   PSIs for association type and association role types:
   - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#createdBy
   - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#creator
   - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#publication

+ CONTRIBUTORS (DC:CONTRIBUTOR)
   NOT USED

+ TITLE OF THE DOCUMENTATION (DC:TITLE)
   Base name of the TMT (scoped by English)

+ LANGUAGE OF PUBLICATION (DC:LANGUAGE)
   An association between the TMT and a topic that represents English
   using a topicmaps.org PSI.
   PSIs for association type and association role types:
   - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#languageOfPublication
   - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#publication
   - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#language

* Issue: What should "language of publication" mean? My opinion: That
every subject indicator either has a name in the scope of each of the
specified languages, or a single name in the unconstrained scope. And
that, every subject indicator has a description in each of the specified
languages.

+ DATE OF PUBLICATION OR VALIDATION (DC:DATE)
   Occurrences of the TMT (publication date and revision date).
   PSIs for occurrence types:
   - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#publicationDate
   - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#revisionDate

+ POSSIBLE RESTRICTIONS OF USE (DC:RIGHTS)
   NOT USED

Additional "metadata" properties that I used:

+ DESCRIPTION
   Occurrence of TMT.
   PSI for occurrence type:
   - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#description

+ VERSION
   Occurrence of TMT.
   PSI for occurrence type:
   - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#version

+ STATUS
   Occurrence of TMT.
   PSI for occurrence type:
   - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#status

+ DOCUMENTATION
   Occurrences of the TMT that provide access to all the documents
   belonging to the PSDS. In my case there are three "documents":
   + http://psi.ontopia.net/ontopia/ontopia.xtm (the topic map) and
   + http://psi.ontopia.net/ontopia/ (the HTML rendition)
   + http://psi.ontopia.net/ontopia/ontopia-psis.txt (this document)
   PSI for occurrence type:
   - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#psdsdoc

* Issue: Given my desire to express the PSI set as a topic map, is using
the characteristics of the topic that reifies the topic map the best
solution for handling PSI set metadata?

* Issue: In all of the above, I have had very little need for the
concept of published subject documentation set, but frequent recourse to
the term "PSI set". I suggest we definitely need "PSI set" and that we
may not need "published subject documentation set". Before deciding the
latter, it might be useful to have more people create their own PSI sets
in other notations.

* Issue: Why does psdoc.htm 4.2 not suggest that title, language, date,
and rights should be defined as PSIs?

* Issue: Do we have the correct set of metadata properties in psdoc.htm?
Might we not just as well include all 14 Dublin Core elements: Title,
Creator, Subject, Description, Publisher, Contributor, Date, Type,
Format, Identifier, Source, Language, Relation, Coverage. (For
descriptions of these, see http://dublincore.org/documents/dces/.)

* Issue: Should we make recommendations regarding the syntax of the
published subject *indicators* (i.e., the URLs)? Should we recommend the
use of the string "psi" as the first component of the host name in the
URL?

* Issue: Should we invent some magic string that is recommended/required
to appear in all PSI set documents (e.g. "PubSubjDocSet"), in order to
aid discovery using web search engines?


PUBSUBJ TC PSIs
---------------

In order to create my own set of PSIs, I needed a starter set of PSIs
that expressed the base semantics that I intended to convey. I therefore
created another topic map, which is available at

    http://psi.topicmaps.org/pubsubj/pubsubj.xtm

It contains the following PSIs:

http://psi.topicmaps.org/pubsubj/pubsubj.xtm#createdBy
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#creator
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#description
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#identifier
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#language
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#languageOfPublication
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#psdsdoc
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#psiset
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#publication
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#publicationDate
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#publishedBy
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#publisher
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#pubsubjTC
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#revisionDate
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#status
http://psi.topicmaps.org/pubsubj/pubsubj.xtm#version

A subset of this topic map (minus all occurrences, the topic map
topic and its characteristics) is included via a mergeMap directive in
ontopia.xtm, in order to provide the topic map application with names
for the typing topics referenced by PSIs in ontopia.xtm.

-- 
Steve Pepper, Chief Executive Officer <pepper@ontopia.net>
Convenor, ISO/IEC JTC1/SC34/WG3  Editor, XTM (XML Topic Maps)
Ontopia AS, Waldemar Thranes gt. 98, N-0175 Oslo, Norway.
http://www.ontopia.net/ phone: +47-23233080 GSM: +47-90827246



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


Powered by eList eXpress LLC