Re: RegOrg update + co-editor

On 24/10/12 01:16, Richard Cyganiak wrote:

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

Agreed, these are not abstract data types in the computer science sense. 
I seem to recall mentioning this before.

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

+1

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

+1

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

Definitely should be on the ISSUES list.

I don't believe that "INSPIRE compatibility" (with its European focus) 
should be a requirement for a W3C spec, though I understand why it is 
for ISA.

Among our options are:

(1) To find a way to encode INSPIRE conformant addresses within vCard.

(2) Have RegOrg use org:hasRegisteredSite and then have it or some other 
(possibly non-GLD) vocabulary provide a non-vcard means to express 
addresses of a site. Using a resource to identify a site, independent of 
the particular serialization conventions for its address, seems to me 
like a good thing (not that I'm biased or anything :)) and may be 
something that RegOrg could adopt. There's nothing to stop an org:Site 
having other expressions of address information.

Dave

Received on Thursday, 25 October 2012 07:53:21 UTC