RE: [tm-pubsubj] Questions

[Peter F Brown <peter@justbrown.net>]

Lars' questions are similar to many of those that we came across in the 
European Parliament's work on object identification and labelling, both in 
the context of possible TM use and more generally...

Peter

Peter Brown
Head of Information Resources Management, European Parliament

Affiliation is indicated for information only. The contents of this mail 
should be considered as reflecting the views of, and engaging, only the 
author. Formal correspondence with the European Parliament should be 
addressed to gri@europarl.eu.int


On Thursday, February 19, 2004 10:30 PM, Patrick Durusau 
[SMTP:Patrick.Durusau@sbl-site.org] wrote:
| Forwarded post from Lars Marius Garshol
|
| (Lars had a problem with his message bouncing. Let me know if anyone
| else has this problem with the list.)
|
| ----------------------------------------------------------------------
|
| We had an internal discussion here about a PSI set we're creating for
| a customer, and I made some notes about questions that came up.
|
|   - how to handle multiple languages? (in the URIs, the names, and the
|     descriptions)
For the PSI URI, see below: keep them semantics-free and the language issue 
doesn't even arise; If the only thing that distinguishes two topics is 
language, then IMHO, they are the same topic, and thus the same PSID and 
PSI.
In the indicator, give the topic names and descriptions in all languages 
that are actually represented in the TM: use the xml:lang attribute for all 
XML tagged elements; With a bit of javascript and/or XSLT or on an Apache 
server, a PSIndicator written in XML can either display the topic name and 
description in the language of the user's browser settings using language 
negotiation; or present the user browser with a drop down list of the 
language versions of the name and description.
|
|   - what is a good form for a PSI URI?
Simple, non-hierachical, but following an algorithmically 
deductible/predictable structure. Consider each structure as an "identif  
ication scheme" for each topic type.
|
|   - should URIs be name-based or meaningless? is there a difference
|     between types and individuals here?
Keep them meaningless but consistently structured: keep the semantics out 
of the ID and put them in the indicator only. The only exception to this 
that we considered was regarding the type/class of object/topic being 
identified. Therefore a topic type would not be in the same identification 
scheme as an instance of that type.
|
|   - what should the subject indicator actually include?
metadata that adequately and uniquely identifies the topic; preferably 
using agreed and namespace-scoped value sets and/or application profiles
|     - what should a good textual definition look like?
Something that a non-Ontopian can understand... ;-). Use DC and other 
metadata standards as a guide.
|
|     - to what extent should constraints on the use of the indicator be
|       included?
|
|     - what form should these constraints be in? prose? OSL/TMCL?
Most good metadata standards have structural constraints or require 
pointers to such constraints (eg application profiles or lookup tables)
|
| There's probably more, but this is what I can remember right now.
|
|
| -- Lars Marius Garshol, Ontopian <URL: http://www.ontopia.net > GSM: +47
| 98 21 55 50 <URL: http://www.garshol.priv.no >