[sc34wg3] The interpretation of facets

[Michel Biezunski]

Steve Pepper:
> Be specific. What weaknesses does the SAM have in this respect?
> The proposal I have given for the interpretation of facets works
> very nicely with the SAM as-is ... it even handles mnemonics,
> as I have shown in my most recent posting. If you think the SAM
> is defective in the area of reification, kindly tell us why.

All these issues have been handled in previous
mails and will surely be raised during the meeting.
I hope the face-to-face discussion will be fruitful
and will make possible to reconcile positions that
look difficult to resolve by email exchanges.

> Who on earth has written mails recently about considering
> conformance as a secondary issue? No-one I know of. All I've
> seen is a very thoughtful suggestion from Lars Marius that
> there are limits to how much conformance one can define to a
> data model. Those limits are internal consistency. Most of
> the conformance we need to define will be in terms of the
> specifications that *use* the data model (XTM, HyTM, CXTM,
> TMQL, TMCL, TMTL, etc.).

Another issue for the meeting.

>> I don't call that "considering conformance as a secondary
> issue." I would rather call it considering conformance as a
> major issue, thinking deeply about it, and making serious
> proposals.
> 
> Or were you referring to something I missed?

I don't think so. It's about until which point
a conformance clause should go. I think a standard
should establish clearly what is the criteria for
conformance. Otherwise it's not a standard.

> >I hope that the
> >discussion in London will help making
> >progress in that direction, because
> >this is a serious concern. Why having
> >a standard if we only can guess what
> >it does?
> 
> Precisely. Up to now, with 13250 as it is, we have only been
> guessing. We are very concerned about that. That is why
> absolutely everything we have written in the SAM, the XTM spec,
> the CXTM spec and the recent postings about HyTM has been
> aimed at clarifying what 13250 is actually saying.

Good.

> >It is a way to make explicit
> >what's happening under the cover
> >and stop relying on specific
> >implementations to decide in our
> >place. I am afraid that the problem
> >which Martin is confronted to is
> >only the tip of the iceberg. Let's
> >make sure that the standard will work
> >the way it is supposed to and can
> >actually qualify as a standard.
> 
> I agree that 13250 barely qualifies as a standard today. What
> we should be doing - the editors in particular - is clarifying
> the *existing* standard, not inventing a *new one*. Let's get
> 13250 right before moving on to the Next Thing.

It all depends the perspective you have
of what standard maintenance is about.
As far as I am concerned, I think that
it's important that when a standard gets
revised, it takes into account the changes
that have occurred in the society, the
technological environment, the user 
requirements and the business practices. 
And this has to be done by preserving 
the existing investments that have been 
made. It's also important to recognize 
that there are parts that are not massively 
used, and even if they can not be completely 
removed (for compatibility reasons),
there is no point in fixing something
that is in practice never used. 

> My recollection of the date of the final decision is different,
> but no matter. You give me even more reason to think of you as
> Mr. Facets. Do you still wish that facets were in XTM? If you
> do, why not argue the case. Martin will support you.

No I don't want facets in XTM. I have adjusted
to the decision taken by the majority.

FYI, I have been using facets before XTM was
invented in a commercial application (an 
encyclopaedia) to qualify the source documents 
I was using so that advertising banners could 
be displayed on the document depending on which 
domain it was. I can certainly still get this 
work using another mechanism (reifying the resources 
and adding scopes to their names, for example, or 
through associations, or any other mechanism). 
It's really a matter of playing with the markup 
and making the application understand what to do.

Since I don't think applications (I mean
software applications) should be standardized, 
but only the information itself, it's just a
matter of building a different kind of application
(software) able to react to a specific context.
For example, I do not wish to standardize
the appearance of advertizing banners depending
on the facet value. I believe this has nothing
to do with the standard, which should be limited
to describe what each piece of information means,
not the way it's handled.

To summarize, there are several solutions to 
replace facets, and I don't have any specific 
preference. I believe it depends on the context, 
on what the intended semantic is, etc. I think
it's important to understand what Martin is
willing to do, and see if there is one, or
several possible answers.

> If you are concerned about the issue of facets, as you claim,
> I look forward to your technical comments on my proposal.

As I said before, I am not more in favor of one
solution rather than the other. Now that it is
part of a local topic map model to decide how to
describe that, I will use one or the other possible
ways to do it depending what best fits a specific
customer environment.

As far as deserializing is concerned, I understand
we probably need to choose one way to do it. 
Let's see during the meeting what's considered
the best by the attendees.

Michel
===================================
Michel Biezunski
Coolheads Consulting
402 85th Street #5C
Brooklyn, New York 11209
Email:mb@coolheads.com
Web  :http://www.coolheads.com
Voice: (718) 921-0901
==================================