Re: ISSUE-160: Allowing collections in semantic relationships

Hi again SKOS folks!

ISO 5964 has been around for decades and is one of the best written and easy to read ISO standard together with ISO 2788. I do believe SKOS must nicely encompass them (and should have used their short and simple mnemonics: BT, NT, RT, UF, USE). ISO 25964 is a future evolution which does not have today made its proofs like ISO 5964.

MARC is very complex, OK. Dublin Core has provided a lowest common denominator for exchanges between human users. But Dublin Core has forgotten many of MARC qualities (semantical precision for instance) and has not really benefitted from the knowledge of MARC pitfalls (semantical adequation of data for foreseen real purposes). Dublin Core is correct for "information discovery" but is now used for "information management" which is a painful problem.

For SKOS, semantical precision for information indexing and retrieval is the central aim, IM-not-realy-HO. And semantical precision implies some "data management support" fields.

Have a nice day!

Christophe

--- En date de : Mar 16.12.08, Antoine Isaac <aisaac@few.vu.nl> a écrit :

> De: Antoine Isaac <aisaac@few.vu.nl>
> Objet: Re: ISSUE-160: Allowing collections in semantic relationships
> À: "Aida Slavic" <aida@acorweb.net>
> Cc: "public-swd-wg@w3.org" <public-swd-wg@w3.org>, "public-esw-thes@w3.org" <public-esw-thes@w3.org>
> Date: Mardi 16 Décembre 2008, 10h20
> Hi Aida,
> 
> > 
> >> To pick a concrete example, in a previous mail you
> said that node labels from ISO-25964 were actually not
> entirely captured by skos:Collection. OK, but then if we
> follow this path, we have to add another class to our model,
> and maybe a couple of additional properties. This would make
> the SKOS model more complex, for dealing situations which I
> believe are not that common (at least compared to the
> variety of KOSs outside there), and therefore could turn to
> be counter-productive.
> > 
> > It would be very important that you explain why is
> complexity counter productive in the case of SKOS. Who are
> intended SKOS users?
> 
> People who have been told that they do not need the full
> complexity of OWL construct and spend months learning it and
> using to model the huge bodies of knowledge they already
> have.
> 
> Maybe for *you* who are accustomed to these levels of
> complexity, there is no problem. But for less expert people
> it makes a huge difference whether you have 20 constructs in
> your model or 30, and when the differences between them
> become more difficult to grasp...
> And actually looking at Leonard's ISO model I realize
> that there is much more than 10 constructs to add to SKOS to
> be fully compatible with ISO-25964.
> 
> 
> > 
> >  From the point of view of interoperability it may be
> better (cheaper and easier) if people have to simplify a
> complex format than if we all have to extend dumbed down
> formats. If more classes are needed by an entire community
> of users then it is far better that these classes are added
> by SKOS developers than by users.
> > Standards have also power of introducing and
> instructing about a good practice.
> 
> I'm really not sure about this. Dublin Core has proven
> to be an immense help for exchange of information, even if
> its users are often accusing it of incompleteness or
> fuzziness.
> Would the result have been the same if the proposed
> standard had been close to MARC?
> 
> Further, there is the philosophy of the semantic web, which
> claim that a set of minimal vocabularies that extend each
> other, if reasonable to achieve, is more desirable than
> all-encompassing, complex things. Semantc web makes it
> *really* easy to extend models and still being *fully*
> compatible with them.
> 
> So I think SKOS is oriented towards being used in
> combination with "application profiles", such as
> the SKOS-XL we've proposed.
> 
> > 
> > So far SKOS is not created to port any of existed
> structured vocabulary in its completeness and for each of
> existing vocabularies there would be need to make extensions
> in order to prevent data loss. Thesaurus, having a simplest
> structure, is the one that seems to be the closest to be
> fully supported by SKOS. I see many advantages in having at
> least one type of vocabulary for which there is no need to
> develop extensions.
> 
> It seems difficult to disagree with that.
> But there are also many disadvantages. The complexity, as I
> mentioned, but also more strategical aspects. E.g. if we
> just duplicate ISO-25964 then it's more difficult for a
> user to see the differences between the two. And people with
> no thorough experience in KOS design would just think that
> SKOS is yet another thesaurus standard, maybe not fitting
> their specific need...
> 
> Cheers,
> 
> Antoine

Received on Tuesday, 16 December 2008 10:20:52 UTC