[iaoa-swao] IAOA SWAO SIG Meeting TODAY Monday 10 April 2017 1:30pm Eastern Time

Mon Apr 10 19:39:46 CEST 2017

Mike, et al.,

Here is the updated paper and my replies on all the comments ... It is rev
#505-1485.

Andrea Westerinen
T: 425.891.8407
arwesterinen at gmail.com or andreaw at ninepts.com
organizingknowledge.blogspot.com

On Mon, Apr 10, 2017 at 12:21 PM, Mike Bennett <mbennett at hypercube.co.uk>
wrote:

> Everyone,
>
> Our next meeting of the SWAO SIG will take place TODAY Monday April 10,
> 1:30 pm EST / 10:30am PST and 6:30pm London (BST) / 7:30pm Europe / 17:30
> GMT/UTC, postponed from last week.
>
> Please see http://ontologforum.org/index.php/IAOA_SWAO_SIG-confcall_n_42
>
>
> Agenda
>
> 1 Issue of the Journal of Applied Ontology
> • Status update
> • Revised Papers status and progress
> • New papers?
>
> 2 Housekeeping, blog etc.
> • updates
>
> 3 AOB
>
> 4 Next Meeting
>
> Note that our monthly meetings are normally on the first Monday of every
> month, at the above time of 1:30pm Eastern Time.
>
> Please see the SIG wiki page above for link to dial-in details.
>
> For more information please see the SWAO SIG website at:
> http://www.iaoa.org/sig/swao/
>
>
> Best regards,
>
>
> Mike Bennett
>
> ____________________________________________________________
> _______________
> Msg Archives: https://listserv.ovgu.de/pipermail/iaoa-swao/
> To join:      please email the SIG chairs or to: info[at]iaoa.org
> IAOA website: http://iaoa.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.ovgu.de/pipermail/iaoa-swao/attachments/20170410/80b88662/attachment-0001.html>
-------------- next part --------------
- - - — -
KenB:

While I liked the paper very much, I have some suggestions for improving the readability of the article.

The article should be more consistent in its use of prefixes. I mention some examples here, but I they are by no means complete.

<arw>Went through and updated all the class and property names with either a prefix, or the use of Schema's, GoodRelations' or ROC's possessive adjective.</arw>

For example, the first paragraph of 4.1 on page 6 is unclear because the classes do not have prefixes. ClimbingGear should be roc:ClimbingGear, Clothing should be gr:Clothing (I assume), etc. Later on page 6, Carabiner should be roc:Carabiner, and the awkward phrase "Good Relations' QualitativeValue" should be simply "gr:QualitativeValue".

Here are some more examples of this. On page 7, "...since the hasCondition property of ROC appears..." should be "...since roc:hasCondition appears..."

<arw>Addressed above.</arw>

Furthermore, the discussion of Condition on page 7 suggests that the roc:hasCondition should be a subproperty of gr:Condition. Is there a reason why this wasn't specified?

<arw>Because gr:Condition is a datatype property and roc:hasCondition is an object property. We would have had to go down the path of literal reification - which still is not = gr:Condition, and that got a bit too complex to be worthwhile (at least in this paper).</arw>

On page 8, "equivalencies" should be "equivalences".

<arw>Changed.</arw>

The paragraph starting "It is assumed..." on page 13 is confusing to read. A little wordsmithing could easily make it clearer.

<arw>Changed to "By default, it is assumed that there is one instance of a product included in an offering. If this is not a valid assumption, then Offering can define the exact quantities using the gr:includesObject property (one of the semantics mapped in Schema). gr:includesObject references an instance of the class, gr:TypeAndQuantityNode. gr:TypeAndQuantityNode exemplifies the use of reification in ontologies (to support n-ary relationships), and has properties, gr:typeOfGood (which references a product or set of products in an inventory), and gr:amountOfThisGood to specify the quantity in the Offer."</arw> 

On page 13, it would be better to say that gr:PriceSpecification is the union of three classes than that it is abstract. The abstract class concept is problematic in an ontology where one can easily construct additional classes (using OWL class constructors, for example) which would have the (usually unintended) consequence of changing the meaning of an abstract class by making it the union of a different set of classes.

<arw>"Abstract" was the word used by GR, but that text has been changed to simply "superclass".  I changed the words similarly.</arw>

On page 16, the phrase "the hasCondition property defined in the ROC climbing ontology" could more succinctly be written "roc:hasCondition".

<arw>Changed</arw>

Footnote 10 on page 17 mentions closed world assumptions used for reasoning. This should be explained a little better, and not confined to a footnote, as it has significance for ensuring that reasoning processes are valid. One way to do this is with the notion of a situation. Situations are a mechanism for supporting closed world semantics within an overall open world without invalidating either one.

<arw>Not changed. As this functionality is provided by Stardog, I cannot comment on how it was accomplished. That is why I provided the reference to the web page where it is described.  I am not comfortable saying more than this and could remove the discussion altogether, but that leaves open questions on how integrity constraints are validated.</arw>

Regarding footnote 11 on page 18, see K. Baclawski, C. Matheus, M. Kokar and J. Letkowski. Toward a Symptom Ontology for Semantic Web Applications. In ISWC'04, pages 650-667. Lecture Notes in Computer Science 3298:650-667. Springer-Verlag. (2004) for possibly the earliest example of this kind of error recording. An interesting aspect of such error recordings is that a single error could cause multiple reports. Abductive reasoning can be used to suggest a common cause for multiple reports. This is just for your information. I am not suggesting that this be included in the bibliography as it is dealing with a tangential topic.

<arw>Thanks. I appreciate the reference!</arw>

On page 20, "a percentage discount that can is set by the retailer" should be either "a percentage discount that can be set by the retailer" or "a percentage discount that is set by the retailer".

<arw>Changed to "can be set".</arw>

- - - - -
MikeB:

Very impressive application that extends real, available ontologies. Some re-work is required on the use of language which is too casual in places. Some intended usages of the ontology are introduced late in the paper – please consider minor restructuring to bring these considerations forward to an initial discussion of scope and requirements and how these informed ontology considerations such as ontological commitment. For example a brief sentence on scoping / use case in the final paragraph of the Introduction section.

<arw>Updated the introduction to include the sentence, 'The goals of the work are to show how ontologies can be integrated with Schema, and to illustrate the value of the integration by describing several, concrete, retail solutions.'  This sentence really describes the scope. I tried various approaches to put more specific scope/use case information into the Introduction - but could not do so without providing all the background that leads up to Section 4. 

In the intro to Section 4, I changed the first paragraph to read, 'The Retail Ontology for Climbing (ROC) was originally proposed as a way to test our methods for knowledge engineering and ontology reuse and integration. However, once initial development was complete, we worked with several retailers to expand it to address better managing their inventory and pricing strategies, and to assist customers regarding their gear and purchases. These use cases are discussed in more detail in the following sections.'</arw>

An example is the decision of whether to segregate things as products from things in themselves – the implications of either choice are apparent i.e. ability to re-use an ontology that does not have such a distinction, and possibly performance issues on one side, versus having instances that selectively use or don’t use particular properties depending on whether they are in retail inventory or personal inventory. As it reads, the reader may conclude you did not consider these issues and the balance of pros and cons but 
simply stumbled upon the implications of this semantic choice.

<arw>This "decision" was actually made by GoodRelations and Schema, and not in ROC or the ODPs. We are reusing their semantics. As this paper is not about critiquing or re-designing GoodRelations - but about using it - I don't feel that I should go into detail about the design decisions of the "standard".</arw>

The introduction to the notion of an ontology in the context of GoodRelations still needs to be stronger. As written, a typical OWL user will see no issue but will not be challenged about the perceived equivalence of “ontology” and “OWL file” whereas the non-OWL using “Applied Ontology” audience will not understand where and why OWL was selected. This issue aims to find common ground between those two kinds of reader. Conflation of “Ontology” with “Ontology in OWL” will get us into trouble with the AO editors.

<arw>Section 3 includes a paragraph that explains what an ontology is, what an ODP is and why OWL 2 was chosen for ROC. I am not sure what more I can say since I cannot make any statements about why RDF/XML (i.e., OWL) was chosen for GoodRelations. If you could make some specific suggestions for changes to the paragraph, that would be great. Here it is: 'Whereas an ontology describes the concepts, relationships, properties, axioms and individuals of a domain, an ODP is that same information but focused on a specific and commonly recurring modeling problem. In this paper, both the semantics of a set of retail ODPs and their rendering using OWL 2 ("OWL 2", 2012) are discussed. For the retail ODPs, OWL 2 was chosen since it is built on RDF, which is an underpinning of the Linked Data and schema.org environments.'

Language:
The word "underwhelming" is only intended to be used as ironic construction. Please do not use it in this paper, as it sets a casual tone that would be out of keeping with the Special Edition. Please keep all language formal.

<arw>Removed.</arw>

Schema – as an abbreviated name for schema.org – please introduce this usage the first time it is used

<arw>This was stated in the second sentence, second paragraph of the Introduction ('The data is structured by the semantics of the schema.org vocabulary (hereafter referred to as "Schema")').</arw>

References in text – e.g. OWL 2 ("OWL" 2012)
should use a numbered reference to the entry in the References section, viz:
OWL 2 (9)

<arw>But this is not what is required by APA guidelines - specifically, 'in-text citations consist of the surname(s) of the author(s) and the year of publication - if there is no author, use the title (or a short form of the title, if it is lengthy) and the year'.</arw>

Page 6:
ROC will be available in full on GitHub in 2017.
Not sure this is relevant, at least without a reference or link.

<arw>Removed</arw>

Introduction
GoodRelations is introduced simply as “an ontology”. Please briefly explain what sort of ontology it is e.g. this is an ontology that uses OWL, or OWL-DL or RDF Schema or whatever. That is, what does it mean to be an ontology at the point where this word is introduced with reference to GoodRelations. Do this before we get to the mention of ontology design patterns so this has a context.

<arw>I added text clarifying that GR is an RDF/XML (OWL) ontology. I don't know what more to say, as I noted above in reply to an earlier comment.</arw>

Also some discussion needed on intended scope and the implication of this on design and re-use – see comments on 4.5 below.

2. GoodRelations Ontology in schema.org
You note that “the semantics behind the words remain roughly the same”. Elsewhere in schema.org words are often used polysemically. Is that the case for the words used (or replaced) from GoodRelations, given that the latter is an ontology and therefore not polysemic?
If this is not known, consider changing this to read that the concepts (not the words) remain roughly the same. This fits better with the paragraph and listings that follow.

<arw>Changed to the "semantics of the concepts".</arw>

3. Retail Ontology Design Pattern
Semantics:
Is there any attempt, either in GoodRelations or in the Climbing ontology, to distinguish between a thing in itself and a thing as offered as a product? 

<arw>Yes, this is discussed in the distinctions between Section 4.3 (Product Model Ontology) and Section 4.4 (Instances in a Retailers Inventory).</arw>

If not, is it explicitly intended that this ontology not be reusable outside of the context of retail? 

<arw>As noted in the overall Introduction, GoodRelations is defined for businesses and e-commerce. As noted in the introduction to Section 4, ROC is targeted at climbing gear retailers. Although concepts could be reused, I clarified Section 4.5 (personal inventory -> personal inventory of purchased items) to be more about the retailer maintaining a list of the purchased items.</arw>

Was this choice considered e.g. balance of efficiency in conflating things with things-as-products versus reusability in non retail contexts (e.g. safety / incident reports)? 

<arw>Even in the case of safety/incident reports, the retailer would use the personal inventory to notify the customer. This still comes down to a retail use.</arw>

Was there a conscious decision to retain the GoodRelations conflation of these concepts in order to support re-use?

<arw>Actually, GR does not conflate the concepts, but clearly distinguishes a product from an instance of the product - as noted in Sections 4.3 and 4.4.</arw>

See also my comments on 4.5 where you do in fact introduce a second, non retail usage.

4.1 Climbing Domain Ontology
Really good explanation about the use of enumerations in ROC as opposed to literals in GR. It is worth also highlighting that this makes the ROC ontology one about the things in the domain rather than data literals about the things in the domain – highlighting a difference in model theory between GR and ROC and showing how this influences what you did. Not critical, just a suggestion.

<arw>I did not add more text (sorry) since the paper is already pretty long and targeted at a Schema.org user. I would rather not add too much more theory.</arw>

4.5 Personal collection catalog
It is unclear why this might exist – as you note later in this sub section. Better to start with the rationale.

<arw>We have not had anyone use the personal inventory - although the retailers did find a use.  I updated Section 4.5 to discuss this.</arw>

Also this is where the semantics of the thing in itself versus thing-as-product becomes apparent. You mention that one property in the ROC ontology, hasCondition, is only used for personal collections but could be used for resold products.

<arw>Clarified the use of hasCondition . . . 'Beyond the date of purchase, the condition of the gear could be captured using the roc:hasCondition property. This is important if the retailer resells used equipment. However, the retailer could also allow a user to maintain the condition of the equipment in their personal inventory. A motivation for labeling products in poor or damaged condition would be to receive notification when there are sales on replacement gear.'</arw>  

If there is a motivation to use the ontology for personal collections as well as retail, this should be part of the up-front discussion linking intended uses of the ontology with deciding on these kinds of ontological commitments in light of those use cases. As a practical result for instance, do you have a product class with the properties related to the sale of that thing being optional or do you now have a different class for the thing in the collection, without inventory properties? Doesn’t this loosen the semantics on the retail side? Again the rationale is needed.

<arw>As noted above and shown in Figure 3, there are different superclasses for ProductModel and Individual, with different properties. This is as designed in GoodRelations.</arw>

I see that creating purchase lists is an important use cases – again, to the up front scoping and design discussions – this kind of thinking doesn’t emerge during the design process but is the set of business requirements you started with. The paper should try to reflect this progression of thought.

<arw>This is highlighted in the intro to Section 4. '. . . we worked with several retailers to expand it [the ontology] to address better managing their inventory and pricing strategies, and to assist customers regarding their gear and purchases. These use cases are discussed in more detail . . .'</arw>

- - - - -
ToddS:

0) I still think there's an issue with the way references are made.
In some cases parenthetical references are given in others
endnotes are used. Have you consulted the IOS reference for
attributions and references (which in turn points somewhere
else)?
<arw>Yes, I reviewed the requirements (APA style guidelines). Web sites can be referenced 'in-line' ("For a passing reference to a website in text, the URL is sufficient; no reference list entry is needed.").</arw>

1) In the first sentence of the second paragraph of section 1,
"Search results are improved by embedding "structured data" markup within a web site's
HTML." 'HTML' should be changes to either 'HTML content', or better yet
'web site's pages'.

<arw>Changed to 'pages'.</arw>

2) In the second sentence of the third paragraph of section 1,
"... over a third of all Google search result ...", I think 'result' should
be plural, 'results'.

<arw>Changed.</arw>

3) In the first sentence of the sixth paragraph of section 1, the term
'overviewing' should be replaced.

In the same sentence there's an inconsistency with an assertion in
a preceding paragraph, " ... then defining Ontology Design Patterns and ...".
In paragraph 4 of section 1 there's the following assertion,
"... this paper defines a simple Ontology Design Pattern".
That is only a single design pattern in defined in the paper.

The construction 'proceeds by' is also unfortunate. Both my concern and yours are, I think, reflections of the implicit and discomfiting anthropomorphizing of the word paper. Papers are inanimate.  An author might proceed, but paper's aren't known for their mobility. I'd probably strike the notion of procedure altogether.

But to your point: the verb "overview", from Wiktionary means: "To engage in an overview; to provide a brief summary". Again, an inanimate or passive object like a  paper might contain an (noun) overview but wouldn't  be able to (verb) overview anything.

So here is my suggestion (brackets show alternatives that may be needed depending upon context):

 "[In their paper], the author [or authors] then [proceed to] provide[s] an overview of ....", or shortest form "The author then provides an overview of ..."

<arw>Revised to read: 'The paper is structured as follows: Section 2 is an overview of the GoodRelations components of Schema, while Section 3 is an overview of Ontology Design Patterns in general and the authors' proposed retail patterns. Section 4 . . .'</arw>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IntegratingGRInADomainOntology-FinalRevision.pdf
Type: application/pdf
Size: 1539640 bytes
Desc: not available
URL: <http://listserv.ovgu.de/pipermail/iaoa-swao/attachments/20170410/80b88662/attachment-0001.pdf>