[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [tm-pubsubj-comment] Comments on ontopia strawman - psi metadata
Steve Comments on your strawman - Part 2 - metadata > 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> As written in previous message, I would prefer: <topic id="psi-ontopia"> <subjectIdentity> <resourceRef 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? Several answers 1. For human face of PSI, I will tend to answer "yes". But in a very large acception of names, including codes. Think about PSIs for colors or frequency bands. 2. I tend to consider a PSI Doc Set as a "namespace", and therefore to recommend that a given PSI Doc Set be published in a single default language scope, declared in the PSI Doc Set metadata, and that if necessary, specific names be declared under their specific language scope. > * Issue: Should we recommend (or recommend against) scoping names by > natural language? Agnostic on that point for the moment. > 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)? Definitely. Looks to me that a subject definition almost implies defining its type. Of course reference to an existing PSI for this type is better ... > 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? If not required, highly recommended. And BTW that's another reason why we should have a default language for all PSI Doc Set. > 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. Good idea! I buy it ... send the bill top Mondeca :)) > 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. Agreed. And other metadata as creator, publisher and the like. > PSI SET METADATA <snip/> Agreed with your way to "reify" the topic map. Consistent. > + 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 At that point, the distinction I suggest between *Ontopia* and *PSI for Ontopia* topics/subjects would be much helpful. Otherwise, you are mismatching semantic layers. The publisher is not the PSI for Ontopia, but Ontopia itself. > + 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 Same remark as above, unless you want to be merged with your PSI, augmenting therefore your virtuality ... > + 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. I would recommend a default language, used for description. > + 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? Very consistent in topic maps paradigm. Might be puzzling and too deeply conceptual for other users. Can't figure ... > * 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. I don't follow you there. The PSI set is not efficient without all the metadata you just listed. I was just beginning to like PSI DocSet = PSI set + their common mandatory metadata > * Issue: Why does psdoc.htm 4.2 not suggest that title, language, date, > and rights should be defined as PSIs? Language, date : it certainly should Rights : may be ... Title : Why a PSI for the title? Title is a <resource(meta)Data> to me. Just a character string ... > * 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/.) Why not. I had just swept out the two last ones anyway -- "relation" seems an assertion like "equivalence", and is better managed in TM using the PSI than inside the PSI. -- "coverage" because I did not figure what use it could have in a PSI. But others could ... Treating all dc elements the same way would make things more simple indeed. > * 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? That looks like a good idea to begin with ... But we will have the case of already existing and well-built namespaces that people would like to keep, because they are already stable. Could you imagine W3C shifting all its standards reference pages, e.g to http://psi.w3.org/rdf ... Of course a standard prefix will help systems to identify PSIs ... All in all, I figure that this proposition is not scalable. OTOH we should keep the notion of a PSI Doc Set as a namespace. > * 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? Definitely. Magicians, move a step forward. > 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 You mean that it *should be available*, right? That means you want the core PSI to be published in XTM. That puts XTM as *the* recommended format, no? I'm not keen to follow you that far ... Bernard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC