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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj message

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


Subject: [tm-pubsubj] Vocabulary - details (Re: Deliverable 1 review ...)


Lars Marius

The third part of the answer.

On the details of vocabulary ...

> | I suggest to add to this list the two following
> |
> | -- publisher (as by Dublin Core definition for example)

> There is a whole slew of possible concepts that could go in here, such
> as 'author', 'contributor', 'copyright owner', 'compiler',
> 'originating source', 'maintainer' ...
> Why not add a more general requirement to say that we will look into
> concepts for describing the roles played by individuals and
> organization with respect to publishing of PSDs?

All the "slew" is not of the same importance ... If we are about published
subjects, we are about publication, and in publication the publisher is the
legal authority, first and last responsible for the content publication. We must
explicitly say he has to be there. No publisher, no publication. No publication,
no published subjects. How the publisher deals with authors, copyright, IPR and
so on ... I am not sure we should consider that in details.

> The requirement should also make clear what it is we intend to get out of
defining
> these concepts.

I don't figure we'll define anything there. Just declare consistency with an
existing standard, namely Dublin Core.

> | -- published subjects directory (since published subject
> | documentations are more likely to come by flocks than single)
>
> I am unhappy with the term, especially as I think it is synonymous
> with published subject documentation. I don't think we need this term,
> since it is what I understood by PSD, that is, a package of
> information defining some number of published subjects.

Hmmm ... either you or me got it wrong. I understood PSD was about *one* subject
...

> We may need to come up with a better name to make this clear, or else
> accept that there are two useful terms hiding under this one. I would
> prefer to leave it as it is.

Assuming we agree on what it *is* ;-)

> | So far, I come with the following glossary concerning those
> | concepts: [...]
>
> Where do you want to put this glossary? Can we get it up on the
> tm-pubsubj web somewhere? (With appropriate disclaimers, of course.)

See the post about process. But I intended this glossary to come definitely at
the beginning of the deliverable.
I'll post it as soon as it's a little clearer if it belongs there or in ISO
13250 ...

> | -- published subject (used by XTM 1.0 - definition refined)
>
> I don't think we should change definitions of key terms. If we want to
> change the definition then let's do that in ISO 13250, not here.

Sure. But there again, nothing was said about it in Orlando ...

> | -- published subject documentation (not defined in ISO 13250)
> | A published subject documentation is a resource that is intended by its
> | publisher to be used as a subject indicator. A published subject
documentation
> | includes at least a subject definition document and a subject indicator
> | reference.
>
> It seems to me that this term as defined is synonymous with subject
> definition document, since an SDD without a subject indicator
> reference is inconceivable.

There again we did not get the same understanding. I can conceive very well a
subject definition document defining the subject on one hand, and the URI
(subject indicator reference) of that document on the other hand. Or is it too
naive, or do I miss something?

> I think published subject documentation is a package defining a whole
> set of published subjects, using SDDs in combination with other
> machinery.

I'm not sure I'm following you there, and I don't know if it is because we have
different understanding of the vocabulary, or because you see something with the
developer's eye that I miss completely ...

> | -- published subjects directory (not defined in ISO 13250)
> | A published subjects directory is a set of structured published subject
> | documentations, managed in a consistent way by an unique publisher.
>
> This is how I understood PSD. Therefore I don't think we need this term.

Consistent. I'd like other opinionss on that.

> | -- publisher (as defined by Dublin Core elements)
> | The publisher of a resource is an entity responsible for the content of the
> | resource, and making it available.
>
> I think we should be very careful here. We could spend the rest of our
> lives discussing this area without exhausting it. What are our
> requirements in relation to this? What are we trying to achieve? What
> are our use cases? Before we agree on this I'm very reluctant to delve
> into a discussion in this area.

See above remarks. Publisher is a standard dc:element. It would be silly not to
use it.
This is not a re-definition, just a reference.

 > | -- subject (as defined by ISO 13250)
>
> This is just a straight quote, right? We should include a reference to
> ISO 13250.

Sure

> | -- subject definition document (not defined in ISO 13250)
> | A subject definition document is a document that has been intended by its
> | publisher to provide an indication of the nature of a subject. A subject
> | definition document shall be usable both for human understanding and machine
> | processing.
> |
> | Note : "usable for machine processing" is not in the requirements and may be
> | controversial.

> It is indeed controversial with me, though you may have some funny
> interpretation of "usable for machine processing" that may make me
> happy if you change the wording. :-)

What I have in mind is that the SDD should have a structured form defined by a
DTD, XML Schema or whatever formal declaration, and not be an "unstructured
document". This structure, consistent throughout a whole set of Published
Subjects (what I call a directory) will allow automatic processing, not only of
the subject indicators (for merging), but of the document itself for whatever
relevant sem... - oops - use ... That's why I tried to expand on the following
text that you did not want to read or discuss :(
Surely you could find a better wording for that.

> In my mind this document is the final thing that defines what the
> subject is when considered by a human being. Computers may help the
> human access the document, but they have no use for it themselves.

I don't agree. Computers should be able to parse this document and retrieve
structured information.

> There may be things of use to them as well, but they are not SDDs,
> though they may be contained in the PSD package.

I don't follow you there. Do you mean the SDD is "what remains when computers
have extracted whatever structured information they could"? Strange ... Is not
there some kind of document structure that both humans and computers can deal
with?
Is not it what XML is all about, BTW? Or there again, am I too naive?

> Also, what's a "document"? What is its relation to the term "resource"?

An XML file is a document. An XML file with its URI is a resource. Is that too
simple?

> | -- subject indicator (as defined by ISO 13250)
> | A subject indicator is a resource that can be used to directly or indirectly
> | indicate the nature of a subject.

> Is this how ISO 13250 defines subject indicator? If so, what's the
> difference with an SDD?

Nope. It comes to me right now that in ISO 13250 (XTM), subject indicator is
defined *from the viewpoint of the topic map author*.
"A resource that is intended *by the topic map author* to provide a positive,
unambiguous indication of the identity of a subject."
And we consider now the viewpoint of the *publisher*. That is where we have to
clarify, and certainly have different terms for:

1. A resource intended by a topic map author to provide a subject identity
(but not necessarily intended to be used for that by its publisher ...)
2. A resource intended by its publisher to provide a subject identity
(but not necessarily used for that ...)

This is IMO the difference between subject indicator and SDD. Not very
technical, but in the direction of intention.

> | -- subject indicator reference (as used by ISO 13250 XTM)
> | A subject indicator reference is an URI that resolves to a subject
indicator.
>
> Is this term actually used in XTM? I don't think it is, apart from as
> the expansion of an element type name. I think we should define this
> term in ISO 13250, and just reference it here. In general I think it
> makes sense for this TC to be a client of ISO 13250 as far as core
> terms are concerned, and this is one of them. (That is, XTM uses this
> term, and should therefore define it. That it doesn't is formally a
> bug, to be fixed in the new ISO 13250, not by tm-pubsubj.)

Agreed

> It should be "a URI", BTW.

You are picky, aren't you?

To be continued - slowly :))

Bernard



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


Powered by eList eXpress LLC