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

[Bernard Vatant <bernard.vatant@mondeca.com>]

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