Re: RegOrg update + co-editor

Phil, Agis,

Some quick comments, trying to figure out how the vocabulary works without actually reading the whole document:

[Edit after finishing the email: This accidentally turned into an in-depth review.]

1. rov:regOrg should have a domain. If a person has a rov:regOrg, then what does it mean? Do they own the organization? Do they work for it?

2. rov:regOrg cannot have dc:isPartOf as inverse. “A dc:isPartOf B” does not imply “B rov:regOrg A”.

3. “In RDF terms, registeredAddress is a sub property of the more general address property” -- What address property does this refer to?

4. Table of properties in 6.9: Instead of “domain: undefined”, can we say rdfs:Resource?

5. The UML diagram contains two properties “identifier”. Are they the same? This is really confusing.

6. Shouldn't the domain of rov:identifier be foaf:Agent or dcterms:Agent? Or Legal Entity? I basically find it hard to understand what's going on with the identifier properties.

7. The class “Legal Entity” in the UML, what does it map to in RDF?

8. Wouldn't everything be much simpler if the UML actually showed RDF classes and properties? The two layers here with an abstract conceptual model in between don't help at all. It's especially unhelpful for the Identifier class where one has to go through several layers of indirection and through several specs to finally find out what RDF properties are to be used. (But then I recognize the value of separating a conceptual model from its binding into RDFS/OWL. So, one conceptual UML diagram and a second with the RDF terms? Perhaps there's a broader issue here for all vocabularies -- shouldn't there be one consistent approach?)

9. The Code and Text abstract types could be easily replaced by just saying “skos:Concept” and “RDF string literal” where they are used. Section 6.1 is unnecessary, I think.

10. s/rdfs:literal/rdfs:Literal/

11. Okay I think I start to understand what's going on. I'm a bit dubious about the inclusion of rov:identifier. It doesn't seem to have anything to do with registered organizations and thus might be misplaced in the vocabulary.

12. The abstract data type “Address” is used but it doesn't say what that is in RDF.

13. What's an “abstract data type” anyway? Can we have a reference?

14. I'd prefer switching Sections 2 and 5. Have an example as early as possible. Also make the example so that it can be copy&pasted -- the line numbers prevent this up. Lines can be referred to quite unambiguously via property names used there. I dislike the comments inside the example -- now we have parallel explanations in the Turtle and in the following text. If necessary, split the example into several short blocks.

15. The text following the example is too long and IMHO contains too much information that isn't about the example itself but about the nature of registration and legal entities in general. This stuff should go elsewhere. The text after the example should be as short as possible or it discourages reading.

16. “The Registered Organization Vocabulary is technology-neutral and a publisher may use any of the terms defined in this document encoded in any technology although RDF and XML are preferred.” -- I'd just drop that sentence. No objection against using this in XML, but the spec actually only defines a binding of the conceptual model to RDF, and defining one to XML is quite clearly out of scope for this WG.

17. A good bit of the Introduction seems to fit better into the Acknowledgements.

18. Off-the-cuff thought: Can the Conformance section be replaced by a simple statement that it is an ORG profile that adds a number of terms and otherwise inherits its conformance criteria?

19. Actually reading the example makes me realize why rov:identifier is useful. Nevermind. I still think it should have a tighter domain (Agent).

20. All references are informative. Anything that is referenced in normative text ought to be a normative reference, really.

21. The paragraph starting “There are several vocabularies in use with a property of 'identifier.'” and the following table should be in a Note, as they're not relevant to defining RegOrg itself, they are just additional information. In fact, that table might best be moved into an appendix.

22. “The identifier relationship should not be used to link to the identifier issued by the authority that conferred legal entity status on an organization.” -- But it's a subproperty of rov:registration, so by using rov:registration, one automatically uses rov:identifier! Change this to say that the more specific sub-property rov:registration is available for identifiers that confer legal entity status.

23. To be honest, the table in Section 2 would be more readable if it was just a Turtle snippet for the subclass/subproperty relationships, plus normal “vertical” text for the SPARQL query and example transformation.

24. s/rdfs:subClass/rdfs:subClassOf/ s/rdfs:subProperty/rdfs:subPropertyOf/

25. Now having read more of the spec, I think it ought to be re-organized a bit. 

26. I suggest making rov:legalName a subproperty of skos:prefLabel. This is in line with recommended ORG usage.

27. I suggest mapping the alternative name to skos:altLabel. This is in line with ORG.

28. In the example, wouldn't it make more sense to use the OpenCorporates ID directly as the URI of the supplementary identifier? (Still keeping it as the skos:notation as well, of course.)

29. Actually, shouldn't the "registered organization" property simply be mapped to org:hasSubOrganization? The status of the sub-organization as a registered one can be easily determined via the sub-organization's type and/or presence of a rov:registration.

30. HTML entity breakage in the last sentence of 6.2

31. Given that all properties receive these nice little tables, the one class defined should have the same.

32. Sections 5, 6.8, and 6.9 should include direct hyperlinks to the Identifier section of the ADMS spec

33. How about moving the UML diagram into the Introduction? The earlier the better.

34. The UML diagram shows a field dateOfIssue on Identifier that doesn't exist in ADMS.

35. Really an ADMS issue, but the ADMS definition of Code is a) incomplete (doesn't have an RDF mapping) and b) doesn't follow SKOS practice (sticks attributes that should be on a skos:ConceptScheme directly onto the skos:Concept).

36. Any particular reason why many subsection titles are not written in title case or sentence case?

37. It seems there is a relationship between rov:registeredAddress and org:hasRegisteredSite/org:siteAddress that should be documented.

38. Why the consistent use of single quotes instead of double quotes throughout the text?

(As you can tell, I ended up reading the entire spec in the process of writing this.)

It's a nice spec -- I like it very much. The main thing that makes me a bit uncomfortable is the “overlay” of a conceptual model over the RDF Schema model, which makes the spec harder to digest than it needs to be. I'm keen on learning more about why this approach was chosen.

All the best,
Richard


On 22 Oct 2012, at 17:49, Phil Archer wrote:

> Dear all,
> 
> Following the resolution of the name, I have updated the draft spec and RDF schema for the Registered Organization Ontology [1].
> 
> Even better news, I'm delighted that Agis Papantoniou of NTUA, who joined us recently as an IE, has also agreed to co-edit this spec. I asked Agis based on the work he's told us about at NTUA on publicspending.gr which is using RegOrg I believe (it will now whatever ;-) )
> 
> I've added a new section that makes the relationship with ORG explicit.
> 
> It refers to ADMS for some of its datatypes, notably adms:Identifier. I've actually amended the latter [2]. The UN/CEFACT complex type on which adms:Identifier is based has separate fields for the actual identifier string and its type. I've tightened up the definition to make it clear that the type should be provided as a datatype on the skos:notation value. This keeps the SPARQL query that derives the org:identifier as simple as it is. Earlier on today I was playing with SPARQL queries that included STRDT() functions to append the value of a dcterms:type property as the datatype for a skos:notation property and it was just horrible. :-(
> 
> The change in name also made it seem better the rename what was originally the legalIdentifer property to rov:registration.
> 
> Taking on board the comments received about ADMS I have included RDF encodings throughout.
> 
> If folk have time to review this actually very short vocab spec, I would be very grateful. There is a team in Brussels actively promoting it and ORG so if the WG agrees, then its publication as an FPWD would be very welcome. Also, Peter Krantz [3] is busy implementing it in Sweden (and screaming at me to get the schema in place!)
> 
> Thank you
> 
> Phil.
> 
> [1] http://dvcs.w3.org/hg/gld/raw-file/default/legal/index.html
> [2] http://dvcs.w3.org/hg/gld/raw-file/default/adms/index.html#data-types
> [3] https://twitter.com/peterkz_swe
> 
> 
> 
> -- 
> 
> 
> Phil Archer
> W3C eGovernment
> http://www.w3.org/egov/
> 
> http://philarcher.org
> +44 (0)7887 767755
> @philarcher1
>

Received on Monday, 22 October 2012 19:54:46 UTC