Fix Issue #153; add missing labels

[marksem]

Fixes #153

Had to do 1 re-serialize commit first, so that the "real" changes would be easy to see. See latter 3 commits for the actual changes. Note that the fix to labeling property goal was to fix the fact that it was a typo in the Artifact restriction.

[sa-bpelakh]

We'll need to mention the goal/hasGoal change in the restriction in the release notes, since it is functionally different (even though it just corrects an obvious problem, so still patch-level).

[marksem]

Yes @sa-bpelakh . I guess when we know which commits/PRs make the cut for the next release, and we have a release branch for it, we'll need to edit the OntologyFiles/ReleaseNotes.txt file on that branch with the appropriate notes. @rjyounes , perhaps that needs a place in some release checklist you may be developing for SA?

[DanCarey404]

I definitely do not remember agreeing to sentence case for labels. And a quick search of the notes in #20 show nothing like that. I, for one, do not like the idea of sentence case labels. We should resolve this issue quickly. From: Rebecca Younes <notifications@github.com> Sent: Monday, January 27, 2020 7:59 AM To: semanticarts/gist <gist@noreply.github.com> Cc: Dan Carey <dan.carey@semanticarts.com>; Review requested <review_requested@noreply.github.com> Subject: Re: [semanticarts/gist] Fix Issue #153; add missing labels (#156) @rjyounes requested changes on this pull request.

________________________________ In OntologyFiles/gistIoT.owl<#156 (comment)>:

@@ -61,6 +61,8 @@

</owl:Class> <owl:Class rdf:about="&gist;ControllerType"> + <rdfs:subClassOf rdf:resource="&gist;Category"/> + <rdfs:label rdf:datatype="&xsd;string">Controller Type</rdfs:label> We agreed on sentence case rather than title case for all labels - thus "Controller type" rather than "Controller Type." See discussion on issue #20<#20> - sorry, I forgot to copy over our decisions when I split up the issues. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub<#156?email_source=notifications&email_token=ABDGWJGTZ5RKD3POTF674UDQ73K7RA5CNFSM4KLUZFB2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCTD5TZA#pullrequestreview-348641764>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABDGWJBOZJSIPRWDHEYLTB3Q73K7RANCNFSM4KLUZFBQ>.

[rjyounes]

@DanCarey404 I am copying your comment to #20, which is where the original discussion took place.

Let's move the discussion to that issue.

[uscholdm]

This change is a bit confusing, but on careful inspection, on each commit, its fine.

[uscholdm]

gist has always used xs not xsd. Making this change should not be done here. It should be first put up as an issue to discuss, and if approved, make the change across all files.

[marksem]

The serializer changed it. Or protege. I fought with it for a while, but then decided to do the format change as 1 commit, and the real fixes next, as otherwise I was at an impasse. The reformat should be a 1 time thing if we use the same serializer going forward.

[uscholdm]

Should not be changing xs to xsd here. Should be raise as an issue and go through normal process. All gist files have always used xs, not xsd. We can decide to change that if we wish.

[rjyounes]

I find this a strange point. The use of a prefix is file-based and has no formal significance. It could be called xyz as long as it points to the right URI. The prefix itself has no consequence and no semantic value. xsd seems to me to be more commonly used.

[sa-bpelakh]

It's primarily convention, right? If I am going to edit the file, I don't want to have to scroll back to the prefix declarations for commonly used namespaces. I could name rdf: and owl: as foo: and bar:, respectively, but it would result in confusion. We should pick one for xs vs xsd and be consistent with it. I have always used xsd (and platts-ontology uses it throughout), but I am OK either way. The actual W3C standard (https://www.w3.org/TR/xmlschema11-1/#xsd-namespace) uses xs:.

[rjyounes]

I've always used xsd as well. Interesting that the standard uses the prefix xs when the uri itself has "xsd-namespace."

[sa-bpelakh]

¯\_(ツ)_/¯

[uscholdm]

I also prefer xsd.

[rjyounes]

@sa-bpelakh At first I thought that was a pushme-pullyou (are you familiar with Dr Doolittle?), which would have been equally applicable.

[rjyounes]

Anyway, I agree with @uscholdm that we should raise this as a separate issue and have created one: #158. @marksem should change the prefixes back.

[rjyounes]

@marksem Re release notes: Boris is responsible for these as he is our release facilitator for the January release. We probably want to come up with a template for these at some point.

[rjyounes]

I'd like to propose the following so we can merge this PR:

1. Use Mark's current labels and resolve this matter in the discussion of Update all labels according to a standard convention #20.
2. Restore xs: prefix and defer to issue Change prefix xs to xsd throughout #158.

Apparently it was rdf-toolkit that changed the prefix, so if we're going to use it we have to opt for xsd. How did we avoid that in the past?

[uscholdm]

I'm happy with @rjyounes 's suggestion.
I doint think the serializer changes the prefix. We use .xsd for PLEO.

[rjyounes]

The reason I suspected the serializer was that the prefix changes occurred in the commit that was only reformatting with the serializer. PLEO files are ttl; I wonder if the serializer behavior is different between the file types. It seems unlikely but I don't know how else to explain it.

[marksem]

@marksem should change the prefixes back.

For pragmatic reasons, I disagree. It is now in the form that serializer wants. And that form uses xsd, our preferred ns. To put it back means more maintenance next time. We need to be avoiding changes that add maintenance time.

[rjyounes]

Technically we have enough approvals to merge, but I don't want to act by fiat. We should be able to merge this and continue the discussion of label formats in issue #20.

[rjyounes]

@marksem There are merge conflicts because the changes from Steve's recent PR, which has been merged to develop, need to be pulled in. His were all typos that I assume you can just accept. Once this is done I'll approve and merge.

[sa-bpelakh]

👍

[sa-bpelakh]

So the transition I am seeing in several places here from

gist:SomeClass owl:intersectionOf ( FirstClass, SecondClass ) .

to

gist:SomeClass owl:equivalentClass [
  a owl:Class; 
  owl:intersectionOf ( FirstClass, SecondClass ) .
]

Is it because the original declaration was never compliant and we are fixing it? Or are both forms valid and we are just choosing a preferred form?

[Jamie-SA]

IIRC there are a bunch of these owl:intersectionOf constructs in gist that the old E6 tool wrote out that way but that Protege will rewrite into owl:equivalentClass (as above).
We (devs) tried to decide if the OWL spec requires it or not. I'd be interested in a more official answer from anyone that wants to go interpret the OWL spec.

[rjyounes]

Fixed merge conflicts. Will address formatting of label in #20.

[rjyounes]

@Jamie-SA @sa-bpelakh I've had Protégé play this trick on me as well. It seems like the simpler version should be valid OWL and that the other is more verbose than necessary. Another reason not to like Protégé.

[uscholdm]

If possible, just do what the serializer does. What Protégé or E6 do should not matter.