OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xmlvoc-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xmlvoc-comment] xmlvoc: Requirements (V0.1 Draft): Defining Core,Why not XTM?



* Lars Marius Garshol
|
| However, I am not sure why we would do this. If we're not going to
| do cover instances, why must we specify this?

* Patrick Durusau
|
| Can you clarify what you mean by "instances?"

What I mean is that we all agree that we should cover classes such as
'standard', 'software tool', etc, but should we actually create PSIs
for instances of these classes, such as 'XTM', and 'the Omnigator'? I
don't think so.
 
| BTW, I like the tools ontology but isn't "standard" a little broad
| to be useful in a topic map of "core XML standards?" 

It is, but it's all that application needs. We should start looking at
how we can classify standards, and useful things one might say about
them. That's beyond the scope of the Free XML Tools site, though.

| Unless the intent is to build an ontology that can then be used by
| others to apply build topic maps for XML 1.0 or DOM 1.0, 2.0 and 3.0
| (drafts)?

I wasn't really thinking of that, but more that I'd do what was
necessary for this application (which, after all, focuses more on
tools), and that we could use that as a starting point to see where we
might want to expand it.
 
| Assuming for the moment that "instances" = "ontologies found in XML
| standards," where does one start to derive an ontology for the Cover
| pages? Could start with the current categories (a fairly large
| number) but that seems (to me) to lose the opportunity to provide a
| more detailed ontology for navigation of XML standards and
| resources.

Well, not really. You could use his existing category system in
addition to whatever else you come up with. With topic maps you can
have it both ways.

I would start by identifying the high-level subjects discussed in his
pages: standards, tools, people, organizations, techniques, and only
afterwards consider whether to expand into further detail.
 
* Lars Marius Garshol
|
| If we are going to cover instances, why would we do such a thing?
| What's the point of creating a PSI set that will be out of date before
| it is even published and that we *know* we can't keep up to date?

* Patrick Durusau
|
| Do PSIs go out of date? At least for reference to ISO and W3C
| specifications? Shouldn't a PSI for ISO 8879 (as amended on July 1,
| 1988) be a valid identifier whether other PSIs are added to a PSI
| set or not?

The PSIs themselves don't go out of date, but assertions about the
subjects may well do so. Also, how would you look at a PSI set that
included subjects for all W3C specifications in existence on
2002-04-16, but left out others added later? 

If you create a PSI for each specification document (kind of
pointless; they already have URIs) you run into the problem that
you'll need to create subjects for the things described in those
documents. Where is XLL today? It's split into XPointer and XLink.
We'll also find examples where A and B become C.

There are ways of keeping old PSIs from rotting, but all of them have
the problem that any PSI set you create will at some point be seen as
out of date because it does not include things created later. Unless,
of course, you maintain it.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC