Several emails to reply to

Dear all,

I am sorry to reply to all emails a bit late... As i was sick and when i went
back to work last week I had some work accumulated, I had now to analyze
around 170 emails from this group.
Therefore I decided to read all of them before replying because maybe some
issues were solved or modified.

Here below all my comments after reading all emails. I hope is fine to put
them all together in one email (even if in this case i lose the connection
with the emails subjects):

1) ISSUE-44 (which is now closed) - (also ISSUE-56): i was thinking that we
were not specifying the transitivity of hasBroader and hasNarrower by
allowing the user to use them both in case of transitivity and also in  case
of non transitivity. BUT i realized (if i understood correctly) that we are
defining as NON transitive. I would actually prefer to define them as
general, so people can use these relationships in both cases... If they would
like a more precise definition, they can use a specialised
hasBroaderTransitive or hasBroaderIntransitive.

Also: this is why (together with Antoine ans Sean) i support the idea of
having hasTransitiveBroader (sorry if i do not use this name consistency, the
final decision should be taken i suppose) as a subproperty and not as a
super-property of hasBroader.

By the way, I asked to our agrovoc management group and they could not find
an example in which a BT is intransitive... just to let you know... 

2) Reply to Alan: yes, also relationships can have synonyms etc, so it is
good for me to make hasBroader synonym of isNarrowerThen.
Mr. Busse also suggested to prefer hasBroader vs isBroaderThan, but these are
opposite each other so we can define both as synonyms of the isNarrowerThen
and hasNarrower. 

3) ISSUE-36: i think everything by Antoine was said is ok to me. Issue is
closed now.

4) Issues from 68 to 84:
Before I reply to these i have to say that we know skos is for KOS, such as
thesauri, ontology, classifications schemes, etc. What I know from my
experience is that we generally want good semantics in these KOS, so we
generally want BT to be transitive so that the hierarchy is valid within the
full KOS... But then i read comments from Antoine and Bernard, who find good
motivations to keep them more generic and not forcing the semantics within
SKOS ... So, I would say that based on my experiences the replyes to these
questions will be the following, but these should be probably revised with a
more generic view. Below I will reply based on my experience and therefore
this is what I wish as an skos user.

>>Should skos:related be normatively irreflexive?
For this I would generally say NO, because in general, in all KOS we use this
in a reflexive way.

>>Should skos:broader be normatively irreflexive?
I would say YES.

>>skos:broaderTransitive be normatively irreflexive?
I would say YES.
Antoine say this is also corresponding to: >>Should skos:narrower be disjoint
with the transitive closure of broader ?<<
Not sure what this means actually... 

>>ISSUE-71: ParallelMappingVocabulary -- Should we keep skos:broadMatch,
skos:narrowMatch and skos:relatedMatch?
I would say YES, because it is easier to immediately identify the
inter-thesaurus relationships otherwise in a mapping file we are obliged to
specify the schemes they belong to. Also exactmatch cannot be represented as
a intra-thesaurus right (what will be RT? skos:exact?).
And also this allows the freedom to use different intra-thesaurus
relationships in different schemes. E.g. A and B in agrovoc are connected by
RT
     A1 and B1 in CAT are connected by NT
but A exactMatch A1 and B exactMatch B1

>>Should skos:exactMatch be transitive?
I would say YES.

>>ISSUE-73: ExactMatchDisjoints?
hummm not sure about this...
What exactly means "disjoint"? Two sets are disjoint if they have no element
in common?
this means they cannot have the same domain and range together? or only
cannot have the same range?  or only cannot have the same domain?
If we intend that they cannot have the same domain and range then YES, the
relationships should be disjoint.

>>ISSUE-74: MappingPropertyConventions
I think that for what i mention in ISSUE-71 YES, I agree on specifying these
conventions. This is helpful to identify when and how the relationships can
be used.
  
>>ISSUE-75: ExactMatchInclusions 
This is actually welcome, because sometimes, we need to use the mapping
between KOS to find all resources related to a domain. For example, if i need
to find document about rice from 3 sources indexed with 3 different schemes,
and I have the mapping between two of them only, then it may be good to have
the proposed rules in ISSUE75 so that i can get documents related to rice
also from the source to which my terminology is not mapped to by just using
these rules on properties between the mapped concepts. 

>>ISSUE-76: SymbolicLabels 
I already reply some time ago: I think they may be useful for chemical names,
formulas, etc.
I suggest we keep them.

>>ISSUE-77: SubjectIndexing (ALSO ISSUE-48)
I think they should be dropped so that we can reuse dc:subject... always good
to reuse other standard if already exists.
Other emails talks about this subject proposing other solutions, but i really
think we may reuse other standards (e.g. dcterms:subject as proposed by
Mikael) without defining new relationships.
By the way, skos:subject should be read as skos:subjectOf right?
And for Richard proposals, i vote for A), B), C)
For Antoine proposal I vote for 1. >>" SKOS is about KOS representation only,
and it is not feasible/desirable have SKOS representing the indexing link
between (possibly very numerous) resources and the concepts they are about.
The functions are just different."<<
I would add that we do not have to forget that dc:subject may also have more
specialized subproperties. FAO created the AgMes standard where we have
ag:subjectThesaurus and ag:subjectClassificationScheme, where we can use
keywords from a thesaurus or categories from a scheme...

>>ISSUE-78: SubjectIndicators 
do not know... never used.

>>ISSUE-79: Notations 
I think here we are going too far... SKOS is for KOS right? the use of the
skos:concept for indexing or other in indexing system etc. in my opinion
belongs to another area... no?

>>ISSUE-80: SKOS-OWL-Patterns
This is interesting... Need to spend more time to read before giving
comments.

>>ISSUE-81: LabelRelationsNaming 
I vote for skos:hasRelatedLabel   
Like skos:hasNote, it may be intuitive, but i think is good to keep
consistency. 

>>ISSUE-82: PropertyNames 
YES, definitely i vote for the following:
 - skos:hasNarrowerConcept
 - skos:hasBroaderConcept
 - skos:hasRelatedConcept 

>>ISSUE-83: SemanticsOfSchemeContainmentProperties 
Yes i would like to be able to say that if SCHEMEX  skos:hasTopConcept A and
A skos:hasNarrower B, then  also B belongs to the SCHEMEX in the hierarchy A
NT B.
Also: more complex: i would like to build a different hierarchy for different
schemes... is that possible? (see below in my email ISSUE 84)

>>ISSUE-84: ConstructionOfSystematicDisplaysFromGrouping 
not clear to me...

5) Question regarding owl:DeprecatedClass and owl:DeprecatedProperty
I would like to tell Elisa that in FAO we do use deprecated concepts. We plan
indeed to use a status to mark deprecated concepts (and why not, also
properties) in the AGROVOC concept server. So I think these construct may be
very useful. Especially because we NEVER delete terms/concepts from a
resource, but we need to mark them as deprecated!

6) Re: RIF: Comments on SKOS Primer: I read the reply from Antoine to my
revision. Here my replyes:
- Section about "Alternative Lexical labels"
Yes, your sentence which try to give guidelines on modifying the KOS is
enough in my opinion.

- ISSUE 45: ok thanks
- ISSUE 82: ok thanks
- inference on relationships (BT inverse of NT or viceversa). ok thanks
- ISSUE 83 and 85: ok thanks

- ISSUE 84: you say "SKOS is concerned with the expression of 
information at the conceptual level, and not at the display one"
I think that what i need is not only related to the display... Maybe i was
not clear: what i need is to be able to reorganize the hierarchy of the
concepts based on different schemes. I am not sure if this belongs to SKOS,
but i wish you and the team to understand what i mean.
For example: I have agrovoc as a thesaurus which has a specific hierarchy
(using BT/NT). So for example i have FOREST NT LOGGING, and ENVIRONMENT NT
FIRE PROTECTION.
Then I have two classification schemes SCH1 and SCH2.
SCH1 hasTopConcept FOREST but i wish to have NT  FIRE PROTECTION 
SCH2 hasTopConcept AGRICULTURE and I wish to have NT ENVIRONMENT and no more
Nts.
(sorry maybe fake examples as I have no access to internet/agrovoc in this
moment). 
So, what i mean is that if I use skos:hasTopConcept and skos:hasNarrowConcept
I can only create one hierarchy (the one guided by the thesaurus) and I
cannot really REORGANIZE the concepts in another hierarchy...
Now I do not know if this belongs to SKOS or not. Maybe I just need to
recreate another 2 KOS, the SCH1 and the SCH2 where I rebuild my hierarchy...
You see what i mean?  
This is actually a real needs in FAO. Because some departments would like to
reorganize agrovoc terms based on a specific classification scheme which may
follow a different prospective than the full thesaurus.
Maybe this has to do with "context"?

Ups sorry I read now the rest of your point in the email... Yes I think the
solution may be the first one you wrote:
>>"- either you want to express hierarchies that are conceptually 
different, and in this case you should create two concept schemes. And 
have them "containing" using the pattern introduced in the Reference the 
different skos:broader assertions that you need for each scheme."<<

I think this make sense so the solution to my problem would be to represent 2
different schemes. Ok I will think about it. thanks

-  in 2.5 at page 11 : YES your new sentence is more clear now.

-  section 3.2 page 14: to me this is valid only if the people that enrich
the concept scheme are different from the ones who own the scheme, because if
somebody owns the scheme that they can just create the missing skos:broader
instead of the skos:broadMatch.
Does this make sense? But ok I see your point. But I propose another
possibility, basically if somebody need to create a link that doesn't exist
in the original thesaurus, would not be enough to add a "dc:creator" to the
created relationships?
 
-  section 3.4 skos:subject: well here see above in my emails. I really wish
not to create other tags other than the ones exists already. For me SKOS is
for the KOS, if I need to use the skos:concepts for indexing, will be the
standard used in my indexing system that identify how to express that an
skos:concept is the subject for a document or another resource. Also because
that system may allow me to decide to use the string or better the URI of the
concept.

- section 4.1: page 17: rdf:nil -> seems more clear, but i need to go back
and read the full document (the one modified by you) then i will let you know
better.

- ISSUE-76: ok i see. anyway see above in this email for same issue.

(end of Comments on SKOS Primer)
 
7) Topic "Are the following statements valid?"

I would say:
1. true
2. true, but i would prefer to call them just term more than "indexing terms"
3.true, but i would prefer to say "assigning intexing terms or concept URI
to"
4. true
5. i do not really agree... this definition for me define "related content
objects"

8) skos:Concept rdfs:subClassOf owl:Class 
need to read the html pages before commenting (will do during next week)

9) SKOS comment: Grouping Concept Schemes
skos:member: i suggest should be skos:hasMember, its more clear like that.
And, i think as Jakob, if we need to identify an inverse better to have a
more clear name such as >>"rename 'skos:inScheme' to 'skos:memberIn'"<<
However there is still some discussion on this issue. I will follow up.

10) SKOS editor: for Quentin
I am happy to see there will be an SKOS editor! I will surely test it.
2. YES in my SKOS representation of my KOS I can have multiple concept
schemes. So I hope the editor my reflect this.
3. In my opinion for siblings there is no need to specify they are
skos:related. The fact they have the same BT is enough to the user to know
they are related. 

-----------------------------------

Finally, I will leave Monday for 3 weeks. I saved some files to read, between
which the skos reference.

End of my SKOS-related weekend :)
Sorry for this long email... Hope this helps.
Margherita

Received on Monday, 4 February 2008 08:47:39 UTC