[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