W3C home > Mailing lists > Public > public-swd-wg@w3.org > April 2007

[SKOS] Response to Reviewer Comments on SKOS Use case document

From: <aisaac@few.vu.nl>
Date: Tue, 17 Apr 2007 14:23:24 +0200
Message-ID: <1176812604.4624bc3cb08d1@www.few.vu.nl>
To: SWD WG <public-swd-wg@w3.org>

Hi all,

I've put on
(always same problems with visualization, try loading it locally)
a new version of the use cases and requirements draft.
Below you will find the editor's answers to Elisa's and Sean's comments.
There are still a few items pending, on which we would need some more feedback
("NOT DONE YET" items, roughly). I'll mention them in today's teleconf.
I think releasing a version taking into account these final points, and our
reviewers' answers to this mail, is feasible by the end of next week.


-----------------------  Sean's comments:

> == General comments. ==
> The current draft displays some evidence of cut and paste :-). There
> is some inconsistency between the presentations of the various use
> cases. Some have clearly been edited, while others are still close to
> the raw format. There are differing levels of granularity in the
> section and some sections still include the headings from the
> questionnaire.

Questionnaire headings have been removed from sections 2.6 and 2.7

> == 2.1 ==
> [[The application enables search based on free text queries]].
> I assume this is search of the /metadata/, but perhaps this should be
> made clear.

"free text queries over the collection metadata"

> == 2.3 ==
> In this section there is a somewhat "throwaway" comment that
> [[Currently the Agrovoc system lacks distributed maintenance, but it
> is expected that a new system will soon solve this problem]]
> I would imagine that the problems of distributed management and
> maintenance would introduce many requirements on a scheme, in
> particular relating to provenance.

I would prefer leave this out for the moment. I find it debatable whether SKOS
should provide this feature, or if it should be dealt with a the level of a
"versioning" system.
I'll ask the WG (during a teleconf?) whether we should include this in the lists
of candidate requirements (similar to what we did in Boston for the other

> == 2.4 ==
> In the product life cycle use case:
> [[It may be useful, where ontologies diverge, to map terms between
> the diverging branches, either to indicate where terms can be
> harmonized to their equivalent, or to identify that there is no exact
> equivalence.]]
> I found this a little unclear. Is this calling for conceptual mapping
> links that indicate /inequivalence/?

"identify that there is a similarity link that is not exact equivalence."

> == 2.6 ==
> In this section (BIRNLex), there's a great deal of information
> here, but without actually explicitly introducing or stating any
> requirements. The voice of the section differs from others (e.g. it
> talks about what "we" will do and "our" intentions, which I assume are
> not those of the WG).

Daniel has edited further the case.
But I don't understand your point on the fact this section does not introduce
requirements. There were some...

> == 2.7 ==
> In this section (RadLex) in contrast, there is a very short piece
> describing the functionality, followed by a number of requirements,
> without so much detail motivating those requirements. Later in 2.7,
> there is a large list of relationships used among terms. This could
> probably be condensed down.

[Daniel] Actually, I disagree with the comment--I think we need the detail on
the metadata as this is setting forth the scope of metadata which is at the core
of this use case! Thus, I have not modified 2.7.

> == 2.8 ==
> Includes a chunk of sample SKOS. Is this needed here?


> Requirements
> In R-CompatabilityWithOWL-DL, there is a requirement that SKOS should
> comply with OWL-DL. What does this mean? There is also a statement
> that this may require OWL to change -- is this document an appropriate
> place for such a statement?

R-CompatabilityWithOWL-DL requirement now reads:
"SKOS should provide a legal OWL-DL ontology, to be compatible with most common
editors and reasoners."

> R-MappingProvenanceInformation
> Is there also a case for Provenance information relating to a single
> vocabulary (cf the comments relating to Use Case 2.3 above)?

DONE (already present)
This is actually R-ConceptSchemeContainment, which state that every SKOS
statement could be related to a  concept scheme from which it originates.
Notice that this is different to your comment on UC2.3, as far as I understand.
R-ConceptSchemeContainment is about "concept scheme provenance" while your
comment was about general provenance ("who created this statement?") which is
generally needed in distributed creation environments.

-----------------------  Elisa's comments:

> Overall -- I agree substantially with Sean's comments.  There appears to be 
> some inconsistency in the level of detail across use cases.  This may be 
> because of inconsistencies in the submitted use cases, but could possibly be 
> allieviated by introducing a bit more structure across use cases, e.g.,
> Summary, Required SKOS Features, Detailed Description, Link(s) to Complete 
> Use Case Submission, and consistent subheadings if used.  This is there 
> informally, but providing the same headings for each use case, and 
> collecting required elements in one place for each might make this easier 
> to read. 

Sean seems to complain about formulaire's sub-heading still being there, and you
seem to prefer having sub-headings. Which direction shall we go to?
Personnally, I prefer the versions without subheadings, just for the sake of
readability: introducing sub-headings in the HTML layout makes the use case
descriptions significantly longer. And if readers are interested in detailed
information (which shall not always be interesting with respect to SKOS
requirements, oherwise it would be in the edited versions ;-) they can go and
check the detailed descriptions. Daniel is also in favor of having less structure.
Also, I disagree with gathering requirements in a single place: in the current
setting, the requirements are 'closer' to the use case feature that motivates

> I think it would be useful to provide comments on the vocabulary maintenance
> methodology in all cases (if known) as well (of course, I'm biased, but it's
> there in a number of cases), but for example, I'm not sure that maintenance 
> in Protege is what I mean by this. If we know it, information regarding the
> methodology would be useful for readers (i.e., organization and process related
> insights), even if it's a short sentence, again consistently across use cases.

As you might have seen in the original descriptions, we got very limited
feedback regarding the maintenance.
I could try to go back to the contributors, or re-interpret what they wrote
(e.g. a "Protégé" answer just means "no special maintenance strategy") but this
is riskier.

> The same is true for information regarding the size and coverage scope for
> each.  These could be managed in consistent subheadings under detailed
> description.

This information is quite consistently present in the subheading "General
characteristics of the vocabulary"
To clarify it, I'vs changed it to "General characteristics (size, coverage) of
the vocabulary"

> Introduction - this section could do with another detailed editing pass, but
> provides a decent introduction to the document itself.

Daniel has made this extra editing pass on my previous material

> Use case 2.4 - I agree that this one is a bit muddy, 

cf Antoine's modifications for Sean's comment on 2.4

> and 2.6 might not need all of the examples; some of the detail captured in
> subheadings could simply be bulletized.  

Daniel has removed 2 of the 4 examples.

> I also agree with Sean on 2.7 -- I'm not sure that all of the detail on
> metadata and relationships among terms used are needed, but one or two
> additional summary motivation sentences would help.

Cf Daniel's answer to Sean's comment

> Other use cases should be under a separate heading, 

Actually it was under a separate heading. It was just not materialized by the
appropriate number (2.9)

> perhaps clustered/categorized to a degree if possible.

I don't really see any clustering beyond what I did for these use cases in 2.9.
Did you have something in mind?

> Numbering over sections also needs to be fixed (at least in the emailed
> version I have from Antoine), 


> and additional structure in the requirements section, clustering of
> requirements, etc. would be helpful for readability.

I have tried to change the visual aspect of this section (using indentation),
but this is only cosmetic.
I have also tried to cluster requirements into "functional" and "non-fonctional"
requirements (as defined in the introduction of section 3), but this isn't an
obvious task since I am not completely aware of these things, and some cases are
borderline (would you say that the requirement that states that SKOS shall be
OWL-DL is functional or not?)
To be honest, I've done that as an experiment, I'd rather do without. Elisa,
could you say if this was the kind of things you expected? Could someone else
eventually validate this classification?

> Also, some kind of concluding paragraph regarding summary of findings, next
> steps, etc. would help balance the document.

I have written a small conlusion in the new version.
Received on Tuesday, 17 April 2007 12:23:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:49 UTC