- From: Paolo Ciccarese <paolo.ciccarese@gmail.com>
- Date: Thu, 10 Jan 2013 07:56:59 -0500
- To: Antoine Isaac <aisaac@few.vu.nl>
- Cc: public-openannotation <public-openannotation@w3.org>
- Message-ID: <CAFPX2kA+7ZSPzq6E+UFwYT3Up=2KFYzUu041zGa0jmmgUufhKA@mail.gmail.com>
On Thu, Jan 10, 2013 at 3:44 AM, Antoine Isaac <aisaac@few.vu.nl> wrote: > Hi Rob, > > This looks good! > The only issues are a small typo (AnotherSchemne->**AnotherScheme), the > fact that I would have lower-cased the instance ids (with my RDF eyes, my > first reaction would be to read oa:MotivationSheme as a subclass of > skos:ConceptScheme, not an instance of it ;-) ). > > Also, I think all the broadMatch can be replaced by broader: the semantic > relations are embedded in the design of the concerned concepts, they are > not post-ante reconciliation of concepts that were created in isolation. > Agree, that is a mapping property that we could use at one point to align different 'motivation-extensions' if any. > > On comment 1: I agree for keeping oa:Motivation makes much sense. But part > of my point was to get rid of the general oa:annotating concept. Asserting > that a concept is narrower than oa:annotation doesn't had much information > to asserting that this concept is a member of oa:motivationScheme, I think. > I think as the oa:Motivation comes from our namespace it can be interpreted as 'motivation for annotating'. So I am in favor of removing oa:annotation that we probably won't use directly either. Paolo > > Cheers, > > Antoine > > > > >> Hi Antoine, and all, >> >> Could you verify that the below RDF is what is intended by your >> suggestions? >> >> ------------------------- >> oa:MotivationScheme a skos:ConceptScheme ; >> skos:hasTopConcept oa:annotating. >> >> oa:Motivation rdfs:subClassOf skos:Concept . >> >> oa:annotating a oa:Motivation ; >> skos:prefLabel "Annotating"@en . >> >> oa:editing a oa:Motivation ; >> skos:inScheme oa:MotivationScheme ; >> skos:broadMatch oa:annotating ; >> skos:prefLabel "Editing"@en . >> >> new:correcting a oa:Motivation ; >> skos:inScheme new:AScheme ; >> skos:broadMatch oa:editing ; >> skos:prefLabel "Correcting a Mistake"@en . >> >> new2:fixing a oa:Motivation ; >> skos:inScheme new2:AnotherSchemne ; >> skos:broadMatch oa:editing ; >> skos:closeMatch new:correcting ; >> skos:prefLabel "Fixing a Mistake"@en . >> --------------------- >> >> And to your comments... >> >> On Sun, Jan 6, 2013 at 8:59 AM, Antoine Isaac <aisaac@few.vu.nl <mailto: >> aisaac@few.vu.nl>> wrote: >> >> 1. Is oa:Annotating really needed? It should be enough that >> motivations are in oa:MotivationScheme (or are defined to be a sub-concept >> of a concept that is in oa:MotivationScheme) to infer that these are kind >> of annotation purposes. >> >> >> The thought was that it would be easier to assert that the range of >> oa:motivatedBy is a oa:Motivation, rather than any skos:Concept. Also, as >> below, they may not be in any Concept Scheme. Unless there's a reason not >> to, I think this would be good to keep. >> >> 2. Using skos:topConceptOf is valid, but this property was coined for >> technical reasons. It would be better to keep to the property in the other >> direction, skos:hasTopConcept. >> >> >> Fixed in to-be-published revised draft. >> >> >> 3. I am not sure that putting all new motivation concepts >> (new:Correcting and new2:Fixing) in the reference oa:MotivationScheme. If >> several applications create their own, potentially overlapping motivation >> concepts, then oa:MotivationSheme risks becoming difficult to use. For >> extensions, knowing that a concept defined to be a sub-concept of a >> "reference" concept that is in oa:MotivationScheme (possibly indirectly, >> via skos:broaderTransitive) should meet most requirements I can think of >> >> >> Agreed, fixed this. >> >> 4. It is good practice to use language tags with SKOS labels. This >> should appear in the machine-readable file, but also be reflected in the >> example. >> >> >> Fixed. >> >> With all these suggestions, Figure B could be reworked to look more >> like the attached diagram (not trying to enforce any graphic convention >> here! It's just that I don't have time to refine it...) >> >> >> This, too, will be fixed and published very shortly :) >> >> Rob >> > > > -- Dr. Paolo Ciccarese http://www.paolociccarese.info/ Biomedical Informatics Research & Development Instructor of Neurology at Harvard Medical School Assistant in Neuroscience at Mass General Hospital +1-857-366-1524 (mobile) +1-617-768-8744 (office) CONFIDENTIALITY NOTICE: This message is intended only for the addressee(s), may contain information that is considered to be sensitive or confidential and may not be forwarded or disclosed to any other party without the permission of the sender. If you have received this message in error, please notify the sender immediately.
Received on Thursday, 10 January 2013 12:57:27 UTC