Re: RegOrg update + co-editor

Hi Phil,

Thanks for the fast turn-around! See below for my responses. I've removed any points where I'm okay with the resolution.

On 23 Oct 2012, at 15:55, Phil Archer wrote:
> 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.

(FWIW, I think it's best to spell things out even if it results in fairly long names. In the long run, we'll all have autocompletion and the cryptic stuff will look silly. But I'm sure I've often violated this myself.)

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

I note that the property is gone from the UML. I thought it was useful in the UML even without a defined range. I guess it should emanate from org:FormalOrganization?

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

In http://www.w3.org/2011/gld/track/issues/40 I see that this problem just disappeared.

If the property applies to anything, then it shouldn't be emanating from the Registered Organization box in the UML.

The example still uses rov:identifier, this should be adms:identifier.

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

Okay. Will need to think more about this.

> We need to think about XML encodings as well at some point.

I wanted to say that we don't *need* to, because that's not in the charter; double-checking the charter I was surprised to find this:

[[
1.1 Out of Scope

	• Any XML technologies, such as XML Schema and AtomPub, which are not part of the RDF stack. Although these technologies are widely deployed and can be effectively used for government data, standardization work on them, if undertaken, is separable enough from the work of this group to be better done in a parallel, coordinated, group.
]]
http://www.w3.org/2011/gld/charter#scope

This creates a pretty strong case against conceptual models that are more generic than RDF.

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

Well, see above.

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

Is the intention of the Editor's Note to flag an (untracked) open issue that will be resolved before LC? If so, fine. What do you think about having an actual issue in the tracker and linking to it from the editor's note?

>> 13. What's an “abstract data type” anyway? Can we have a reference?
> 
> I offer http://en.wikipedia.org/wiki/Abstract_data_type

Hm... The various definitions all talk either about behaviour or about programming languages, neither of which seems appropriate here.

I note that ADMS calls the same thing simply “data type”.

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

Well, whether I need to remove the line numbers or find the external file, either way it messes with easy copypasteability.

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

Well, see above. We can link to an XML schema informatively.

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

Well, that'll do.

Nitpick: The subsection doesn't need to say again that it's informative.

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

The gain would be saving half a page of text?

I'll try to come up with some wording and send a separate message if I do.

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

?a rov:registration ?b implies ?a adms:identifier ?b. One cannot use rov:registration without also implicitly asserting the rov:identifier relationship.

This is like saying: “Don't type a resource as an Agent if it actually is a Person.” You can't do it -- typing something as a Person also types it as an Agent.

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

Yes. Also, people print these things. Safari just cuts off half of the table.

At least pull the Turtle/SPARQL bit out of the table.

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

Oh, sorry, I actually failed to come up with a better proposal and forgot to take that sentence out again.

> If you see skos:altLabel don't you always look for prefLabel too?

Well, yes, but I don't see how skos:altLabel and skos:prevLabel are any different in that regard compared to dc:alternative and dc:title. So my vote is for skos:altLabel, and for skos:label as superproperty of rov:legalName. (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

You're right, I was wrong. Sorry. It would be correct to use the OC identifier as the IRI of the rov:RegOrg, but that would just make the example more confusing.

Random thought: Use xsd:anyURI for the data type of the OC identifier (instead of ex:OCid)?

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

There is no hyperlink to ADMS at all, except in the references. Why can't the word “Identifier” hyperlink to the point in the ADMS spec where that “abstract data type” is defined?

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

Sure, but it's the one single thing in the entire spec that will receive most eyeball seconds, including from repeat visitors, so why bury it halfway towards the end? My experience with vocabulary specifications is that I keep coming back to look at the diagram.

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

Well, given the charter of this WG, there is no question that you cannot normatively require the use of some alien datatype, and then not say how to express that datatype in RDF.

I'm also not entirely sure why someone who wants to specify a company type in RDF has to be dragged into the world of UN/CEFACT.

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

But these are properties in a conceptual model, not RDF properties. I don't really see the benefit of treating them as “code”. I suggest treating them as natural language terms as much as possible, and not setting them in monospaced text. Just like you do for abstract datatypes already.

Note that the UML is a bit inconsistent in this matter, some properties are camelCased, others treated just like natural language phrases.

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

Okay. Maybe this is a shared issue that should be filed against both specs then? It would be unfortunate if ORG requires one encoding for the address, and RegOrg requires an incompatible second one.

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

Nothing wrong with being a pedant (or being a Brit), but:

[[
W3C uses U.S. English (e.g., "standardise" should read "standardize" and "behaviour" should read "behavior").
]]
http://www.w3.org/2001/06/manual/#Spelling

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

Well, I'd really like to see actual prefixed names in the UML diagram because that's so much easier than having to hunt for the subsection that defines the abstract property to find the RDF encoding. This is a simple matter of usability for the constituency I care most about. Is the only way to avoid a religious war to forfeit this usability?

Best,
Richard



> 
> 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 Wednesday, 24 October 2012 00:17:24 UTC