[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [tm-pubsubj] Subject Indicator vs Subject Descriptor
Mary I was waiting for some other TC member(s) to jump in the debate, but ... > MN -- 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 ;-) I agree it would be good indeed to provide both DTD and equivalent xml schema for Subject Descriptor > 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. I don't feel reasonable to let open the door to non-resolvable identifiers. IMO, a Subject Indicator without Subject Descriptor would miss half of the mission of topic maps using it. They would be only machine-usable but not human-understandable. I'm afraid we'll see such practises anyway, given the "URI-is-a-name" trend ... But I think we'd better not encourage them in our recommendations. > 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. Hmm ... using subjectName *inside the URL* seems to put semantics where they don't belong, and is the top of the slippy slope down to confusion between Indicator and Descriptor - that we don't want, or do we? > 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." Yes - they put semantics in the namespaces ... I don't like it ... > BV --- 2. Subject Descriptor ... > 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? Any existing PSI published in the standards should be kept stable for backward compatibility. Of course, as they appear in XTM 1.0 they seem far from the recommendations we are aiming to. But if we include in Subject Descriptor the <equivalent> element, nothing prevents to have more standard sets equivalent to those. I hope you don't figure *unicity* of PS for a given subject as a sustainable objective? People have to be let able to publish independently their own PS sets, simply because they will not be necessarily aware of relevant equivalent other ones, or wait for them to be available. Of course that will lead to redundancy, but it's unavoidable.But, publishers should be able to declare equivalence at any moment afterwards, without changing the Indicators. And that's also a reason why the Indicator should be resolvable, because the declaration of equivalence will be in the Descriptor. It cannot be in the Indicator, because the Indicator is stable, whereas the declaration of equivalence is bound to change ... And the parsers/spiders/crawlers and whatever intelligent agents will have to go inside the descriptor to extract that kind of information. Hope that helps Bernard ------------------------------------------------- Bernard Vatant - Consultant Mondeca - "Making Sense of Content" www.mondeca.com bernard.vatant@mondeca.com -------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC