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 ontopia strawman - psi metadata


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">

> 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.



Agreed with your way to "reify" the topic map. Consistent.

>    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.

>    An occurrence of the TMT
>    PSI for occurrence type:
>    - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#identifier

>    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 ...

>    Base name of the TMT (scoped by English)
>    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.

>    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
> Additional "metadata" properties that I used:
>    Occurrence of TMT.
>    PSI for occurrence type:
>    - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#description
>    Occurrence of TMT.
>    PSI for occurrence type:
>    - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#version
>    Occurrence of TMT.
>    PSI for occurrence type:
>    - http://psi.topicmaps.org/pubsubj/pubsubj.xtm#status
>    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
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.

> ---------------
> 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 ...


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

Powered by eList eXpress LLC