[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [tm-pubsubj] Subject Indicator vs Subject Descriptor
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 **************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC