From: Bernard Vatant <>
Following November 20 meeting, consensus of present people
seems to be established on the following points (correct me if I am
wrong).
MN ---------- Yes, these are very much to the point. I would like to add a
little and comment more on what I said at the meeting after a little more
reflection.
BV ---------- A Published Subject should provide two distinct parts:
1. Subject Indicator (URI or URL)
as to be used through <subjectIndicatorRef xlink:href>
MN --- Can we add that it is the unequivocal binding point for the
subject's identity, where <subjectIndicatorRef> in the child of
<subjectIdentity> in XTM topic maps. In cases where an xml schema might be
used, the URI would be of built in primitive datatype anyURI for the
identity attribute of the topic. This subject indicator is optional but
would be required at a minimum if the subject's identity were to be
established.
MN ---- Note: This mention of xml schema may not be necessary, but I think
that it would be good to include if we don't want to exclude these
potential TM authors ;-)
BV --- It is thought that this should be both
-- a syntactic identifier, to be used by software as a mere character
string, without any further processing and interpretation.
-- a pointer to a resolvable resource (the Subject Descriptor defined
itself, apart from a standard structure, allowing software or humans to
identify it as a Subject Indicator.
No, or the least possible, "semantics" are to be put in the string.
below).
MN ---- Would this resolvable resource be recommended for the
identity and is it more in the "nice to have" category? If this is the
case, then can we add that the URI may or may not point to a resolvable
resource and would depend on the TM author's need to have such a resolvable
resource.
MN ---------- Thinking about "the semantics in the string" once again, I
wonder how practical my suggestion was. It would take much time and
effort for something that might not be necessary if we do in fact have an
indicator; however, a minimalist approach (simple name) to aide the human
reader, may be appropriate. Example:
http://purl.org/subjectOwner/subjectName/ could point to the resource and
a link to this page would go to the metadata. This would be akin to the way
metadata is attached to resources in http://dublincore.org.
MN -- Please take a look at Namespace Policy for the Dublin Core Metadata
Initiative (DCMI)
http://dublincore.org/documents/2001/10/26/dcmi-namespace/
"The use of XML namespaces to uniquely identify metadata terms allows those
terms to be unambiguously used across applications, promoting the
possibility of shared semantics."
BV --- 2. Subject Descriptor
It is the content of the resource that the Subject Indicator resolves
to. It is where the subject is properly defined and/or described, in
other terms it is where the semantics are grounded, and the Topic
Map recursive process ends.
For the recursivity to end effectively, the Subject Descriptor have to
be defined not in Topic Map terminology, but at a meta-level.
Best candidate for standard Subject Descriptor structure could be
built upon RDF-Dublin Core elements.
Such a standard Subject Descriptor could be used by parsers to
extract metadata on the subject, like publisher, date of creation,
validation etc.
I propose that this distinction be explicitly stated on TC
requirements, as well as the requirement to deliver a syntax for
both Subject Indicator and Subject Descriptor.
MN ---------- If we do go with this, would it mean that the PSIs defined
in XTM would need to be changed or even removed altogether? Any opinion
about this from committee members?
MN -- For the descriptor, I was wondering if we can discuss at some later
date, the use of Qualified Dublin Core
http://dublincore.org/documents/2001/08/29/dcq-rdf-xml/ versus Unqualified
Dublin Core.
Thanks,
Mary
**************************************
Mary Y. Nishikawa, Technical Editor & EDMS Support
XML Evangelist
Technique/ InTouch Documentation
Schlumberger K. K.
2-2-1 Fuchinobe
Sagamihara, Kanagawa 229-0006
Tel: +81-42-759-5376
Fax: +81-42-759-3563
**************************************
