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] | [List Home]


Subject: RE: [tm-pubsubj] Subject identification and ontological commitment :areal-world example


Hi Bernard,

After reading through your explanations, it looks like variuos usage 
senarios for published subjects.  Why don't you write these up? We can then 
put it on a schedule for deliverable 3 or 4, and discuss it formally.

I think that Patrick is reviewing all of the stuff we have already and 
setting up the process and assignments. The next deliverable is Published 
Subject documentation Structure, I think. I think that you are a little 
ahead of the game, but we can get to it later; but let's not loose it.

>*Bernard
>But that's EXACTLY where it hurts! If different applications and languages
>use the subject identifiers at will with their own identification process,
>there will be no way in which they can be interoperable.

Yes, this would be a private implementation of published subjects, valid 
within a specified context.
You seem to want to describe a use case for semantic web use of published 
subjects, and that is fine.
Write it up :)

>Unless, like I've
>tried to show by the example at http://isbn.nu, the different actors in a
>processing context commit to the same semantic properties of the subjects
>they identify, whatever their internal language.
>
>Just catch me well. I don't care that much about PSIs that would be usable
>in a single processing context (like only in TM).

That's fine. You do not need to care about it.
There are others that do and they can write up their own use case :)

>I want to be able to say
>that the subject in data base X is the same that the one in topic map Y,
>the same that in ontology Z, the same as in thesaurus T, and be able to
>syndicate information from those four sources without semantic clashes.
>This requires, to be useful, that X,Y,Z and T, whatever their internal
>structures and languages, don't attach to this subject  properties
>conflicting with the generic ones included in the subject definition
>itself. And the best and certainly only way to ensure that is that those
>generic properties are declared somewhere as reference. And where and how,
>if not by the subject indicator?

This is good if all 4 players have agreed to cooperate with each other, 
have NDAs maybe, etc.
It could be the MIT Library, Library of Congress, British Library, 
Vanderbilt U. Library, etc, or say, a consortium in a vertical market, etc. 
Hey, another good use case :)

>In the case of books, if the PSI http://isbn.nu/0534949657 declares
>explicitly:
>Hey, this identifies a single book. But wait, a book is something with a
>title, an author, a publisher etc. Here are the identifiers for "title",
>"author" "book" "publisher" ... and so on.
>Our recommendation could say: if you use a PSI declared in such a way, it
>implies you commit to those statements, use the same identifiers for
>"author" and "title" and the like, not only the same ISBN number for this
>specific instance. This is the only way I can find the "author" field in so
>many sources.
>What is not attached to the PSI is e.g. its price today at Amazon.

Sounds like a good use case for booksellers :)


> > In my opinion the very furthest we could possibly go in this area is
> > to provide short, simple guidelines on how to apply PSIs in these
> > different areas. I'm not sure we should, but maybe that would be good.
> > It would probably help RDF users, for example.

Sure, as I said write it up! (I think that this is deliverable  3 or 4, maybe).

>I don't know if we have to care about any specific language, as long as it
>is able to express things like the following:
>
>This PSI for subject A declares explicitly that A is an instance of the
>class B, defined by that other PSI for B. If you use this PSI, you
>implicitly agree with that statement, which is a generic part of the
>definition of the subject A, and therefore should not express using this
>PSI something inconsistent with this definition like "A is not an instance
>of B".
>For example if GeoLang publishes PSIs for "Kurdistan" or "Palestine"
>declaring they belong to the class "Country", someone using this PSIs to
>assert that Kurdistan or Palestine are *not* countries is non-conformant to
>the recommended use of GeoLang PSIs. At least it's my viewpoint.

This is not in scope. If ISO says these are countries (and they validated 
this information according to such and such authority) and somebody wants 
to assert that they are not, they should take this up with the ISO 
committee who published this information.

We are only providing a standard to represent the information in a computer.

>  Definition of a subject in a subject indicator should contain assertion
>of generic properties of the subject, like attributes and relationships
>with other subjects, themselves (the relations and the subjects) identified
>by other PSIs. Those generic properties should be reduced to the minimal
>set needed to define the subject without ambiguity. It is recommended that
>the subject indicator provides accurate and explicit indications concerning
>those properties. Use of a PSI entails from its user a commitment to use it
>in conformance with those indications.
>- A recommended practice is for publishers to deliver sets of PSIs where
>those properties are declared using a formal and consistent ontological
>schema : classification, thesaurus, formal ontology, in any relevant
>standard format.

Sounds like the introduction of your best practices :)

>  Nevertheless, my answer here hopefully
>contains concrete proposals for future deliverables.

Agreed. So we are looking forward to reviewing your proposals.

Cheers,
Mary



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