- From: Phil Archer <phila@w3.org>
- Date: Tue, 23 Oct 2012 15:55:43 +0100
- To: Richard Cyganiak <richard@cyganiak.de>
- CC: Public GLD WG <public-gld-wg@w3.org>
Thanks very much indeed, Richard. This is extremely helpful. Answers/comments inline below. Doc at http://dvcs.w3.org/hg/gld/raw-file/default/legal/index.html has been updated. On 22/10/2012 20:54, Richard Cyganiak wrote: > 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? Good question. The domain that makes sense to me is dcterms:Agent (equiv class foaf:Agent), which means that the agent, whether the agent is a Person, Organization or whatever, 'has' the RegOrg which is something like "is made legally manifest as." I have toyed with doing away with the property completely and just using org:hasSubOrganization or defining rov:regOrg as a sub property of it. The latter route means that it would then inherit a domain of org/foaf:Organization. But... org:hasSubOrganization - "Represents hierarchical containment of Organizations or Organizational Units; indicates an organization which is a sub-part or child of this organization." and org:hasUnit - "Indicates a unit which is part of this Organization, e.g. a Department within a larger FormalOrganization." Both of these indicate a hierarchy that may not be appropriate. For example, it is wrong to say that W3C has a subOrganization of ERCIM. It is correct to say W3C "has (a) legal manifestation in" ERCIM however. So I have: 1. Defined the domain as dcterms:Agent; 2. amended the definition of rov:regOrg to "The registered organization relationship can be used to link any dcterms:Agent (equivalent class foaf:Agent) to a Registered Organization that in some way acts as a registered legal entity for it. This is useful, for example, where an organization includes one or more legal entities, or where a natural person is also registered as a legal entity. rov:regOrg has a range of rov:RegOrg." I have been mulling over whether the fact that foaf:Organization and foaf:Person are disjoint causes any problems but I don't think it does. From this: ex:me a foaf:Person; rov:regOrg ex:MyTradingCompany . we can infer that ex:MyTrading Company is a foaf:Organization but not that ex:me is. This is good news since I know in Spain you can be both a natural person and a registered company (see Makx Dekkers for details!) I've also tidied up a bit of confusion that had crept in. I had written both rov:regOrg and rov:registeredOrganization. I've used the shorter form consistently now although I personally don't like the practice of having a property that points to a class where the only difference is whether the first letter is a capital or not. > > 2. rov:regOrg cannot have dc:isPartOf as inverse. “A dc:isPartOf B” does not imply “B rov:regOrg A”. The inverse relationship was not defined formally but I take the point. I have removed that from the text. > > 3. “In RDF terms, registeredAddress is a sub property of the more general address property” -- What address property does this refer to? Removed. Sorry, this is a hangover from the ISA Core Location Vocabulary (now in the hands of the LOCADD CG). > > 4. Table of properties in 6.9: Instead of “domain: undefined”, can we say rdfs:Resource? Done. > > 5. The UML diagram contains two properties “identifier”. Are they the same? This is really confusing. Yes it is (confusing). I'd forgotten to update the diagram altogether. now done. I've renamed the identifier property of the Identifier class as notation (which matches its RDF encoding as skos:notation). > > 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. No. Anything, Agent or otherwise an have an identifier. Au is an identifier for gold, for example. > > 7. The class “Legal Entity” in the UML, what does it map to in RDF? See above. Diagram now updated. > > 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?) +1 for a consistent approach. If two diagrams help then that can be done but that's what it would need. We need to think about XML encodings as well at some point. > > 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. Yes, it's a pain to cross between different documents - a pain that only goes away with more familiarity. I don't have to look up dcterms:creator these days ;-) I've added the RDF encodings directly. But I don't agree that section 6.1 is unnecessary. If we're to make public sector data interoperable, then we need to accept that not everyone uses RDF. There are very substantial tool chains based on XML and we can cross that boundary more easily if we think in terms of multiple encodings of a common set of concepts. > > 10. s/rdfs:literal/rdfs:Literal/ Fixed. > > 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. Hmm... yes, it could easily be part of ADMS which is there the Identifier class is. If that makes more sense I'm happy to see it move. > > 12. The abstract data type “Address” is used but it doesn't say what that is in RDF. Yes, again, hangover from earlier times. But there is an Ed Note above that explains this... > > 13. What's an “abstract data type” anyway? Can we have a reference? I offer http://en.wikipedia.org/wiki/Abstract_data_type > > 14. I'd prefer switching Sections 2 and 5. Have an example as early as possible. Done Also make the example so that it can be copy&pasted -- the line numbers prevent this up. Done, although I've achieved the same end by providing the example as a separate file. > Lines can be referred to quite unambiguously via property names used there. True but I find line numbers clearer. 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. OK, I've removed most of them from the HTML doc (but kept them in the external file). > > 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. I disagree, especially now that it's right after the intro. The aim of the example is to convey the nature of the vocabulary and the purpose it serves. I believe our main target market for this - company registers and the like - will feel more positive about the vocab if they can see near the beginning of the doc that it has been developed within their own context. See also point 17 below. > > 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, So far, yes. > and defining one to XML is quite clearly out of scope for this WG. But not others. The ISA Prog folk are very likely to create an update of the XML schema that exists for the original 'Business Core Vocabulary.' My belief is that such a schema will be published on the EC's Joinup portal and we can link to that. > > 17. A good bit of the Introduction seems to fit better into the Acknowledgements. Agreed. Main part of the intro is now just 2 short paragraphs long but, to pick up on your earlier point about the explanation of the example being too long, I've now made the example a sub section of the intro. > > 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? Hmm... I just tried wording it and it didn't feel right. I'm happy to do it but I don't see the gain. > > 19. Actually reading the example makes me realize why rov:identifier is useful. Nevermind. I still think it should have a tighter domain (Agent). See above :-) ISSUE-40 has been raised. > > 20. All references are informative. Anything that is referenced in normative text ought to be a normative reference, really. True. I've moved some of the refs. > > 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. Appendix created. > > 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. One of us has this the wrong way round. rov:registration is a sub property of the more general rov:identifier. I think the text is correct, no? > > 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. Hmmm... I felt it useful to set out all the formal relationships n a table. Yes it's a bit verbose and physically big but it helps to make the relationship with ORG very clear. However... I'm looking at it on a big screen where scrolling is not required. Is that at the root of the problem you describe (the <pre/> CSS doesn't allow white space wrapping). > > 24. s/rdfs:subClass/rdfs:subClassOf/ s/rdfs:subProperty/rdfs:subPropertyOf/ Yes, sorry. It was right in the schema but not the text. Fixed. > > 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. I sympathise but we can't do that. There are jurisdictions where a company can have more than one legal name. They're not translations and there is no order of preference. We'd have to allow multiple skos:preLabel properties which isn't good. > > 27. I suggest mapping the alternative name to skos:altLabel. This is in line with ORG. That would be OK but it's a toss up between skos:altLabel and dcterms:alternative. Given the alignment with ORG, skos:altLabel wins but the previous comment worries me. If you see skos:altLabel don't you always look for prefLabel too? Happy to change it but I don't think it's clear cut. That's ISSUE-41 > > 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.) Hmmm... one is Open Corporates' own ID for the company. The other is the ID of a class that describes the identifier. They're not the same. It's very easy in this vocab to find yourself saying that a company formed in 2001 was last updated at 2012-10-23T15:00:00Z > > 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. No. See earlier discussion. A hierarchy may not always be appropriate. > > 30. HTML entity breakage in the last sentence of 6.2 Fixed. > > 31. Given that all properties receive these nice little tables, the one class defined should have the same. Sorted. > > 32. Sections 5, 6.8, and 6.9 should include direct hyperlinks to the Identifier section of the ADMS spec I've added hyperlinks in what is now section 5.1 Datatypes. There are several other links to ADMS. > > 33. How about moving the UML diagram into the Introduction? The earlier the better. I see it as part of the section that includes all the classes and properties - it's the concept model that is then encoded. > > 34. The UML diagram shows a field dateOfIssue on Identifier that doesn't exist in ADMS. True. It's included in the namespace doc though (http://www.w3.org/ns/adms#Identifier). Gofran and I need to get these into alignment. > > 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). Although I sympathise, It's possible you have the telescope back to front. The code datatype is not skos:Concept. It's code, which comes from the alien world of UN/CEFACT that publishes vast spreadhseets of terms. The task we have is to try and make sense of all that, in this case, in RDF. skos:Concept is pretty close to it. Once I've done this mail (it's only taken me 4 hours so far) I'll get on to looking at ADMS and will tighten up that definition in the doc - yes, it can certainly be improved. > > 36. Any particular reason why many subsection titles are not written in title case or sentence case? Because properties are written in lower case. Look too odd? > > 37. It seems there is a relationship between rov:registeredAddress and org:hasRegisteredSite/org:siteAddress that should be documented. No. ORG uses vCard. That's fine in some circumstances but vCard is not INSPIRE conformant. Again, this relates to the LOCADD CG which is currently being held up by a bit of EC bureaucracy. We will need a registeredAddress property to link to an INSPIRE-conformant address class soon. > > 38. Why the consistent use of single quotes instead of double quotes throughout the text? Because I am English and a pedant for grammar. I was speaking to my son last night about why he has his alarm clock radio set to a really crummy local dance music station he hates. He said "oh that helps me wake up. I spend the first 10 minutes of every day silently screaming at the radio to correct them on their grammar." He makes me very proud. http://www.informatics.sussex.ac.uk/department/docs/punctuation/node30.html > > (As you can tell, I ended up reading the entire spec in the process of writing this.) And I remain very grateful. > > 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. Because, like ADMS, it comes from a group of people who think in terms other than RDF. That's an important constituency, maybe not to the GLD WG, but to the broader one. It's about avoiding the religious wars where, whichever technology you choose, some folk will exclude themselves because of that choice. I'm hoping we can avoid that. Right... you had some comments about ADMS that I need to look at... Phil > > 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 >> > > -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org +44 (0)7887 767755 @philarcher1
Received on Tuesday, 23 October 2012 14:56:15 UTC