Re: RegOrg update + co-editor

Thanks very much indeed, Richard. This is extremely helpful. 
Answers/comments inline below.

Doc at 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."


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 

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?


> 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/

> 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

> 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.

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 

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

> 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

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 
( 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.

> (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...


> 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 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]
>> [2]
>> [3]
>> --
>> Phil Archer
>> W3C eGovernment
>> +44 (0)7887 767755
>> @philarcher1


Phil Archer
W3C eGovernment
+44 (0)7887 767755

Received on Tuesday, 23 October 2012 14:56:15 UTC