Re: [tm-pubsubj] Subject Indicator vs Subject Descriptor

[Mary Nishikawa <nisikawa@fuchinobe.skk.slb.com>]

From: Bernard Vatant <bernard.vatant@mondeca.com>
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
**************************************