Re: Business Voc and ADMS

Hi Phil,

On 06/09/12 17:40, Phil Archer wrote:
> Thanks very much Dave, answers below:
>
> On 06/09/2012 15:03, Dave Reynolds wrote:
> [..]
>>
>> The issues I've noted on skimming through the current state are:
>>
>> (1) legal:companyType appears to duplicate org:classification. The RDF
>> states a subclass relationship but that is not reflected in the
>> specification text and it is not clear why they are not equivalent.
>
> The Business voc makes three sub properties of org:classification:
>
> - companyType (for Plc, LLP, GmbH etc.)
> - companyActivity (NACE code, SIC code etc.)
> - companyStatus (trading, in receivership etc.)
>
> The intention is to provide specific semantics for those. My reading of
> the org:classification property was that this kind of specialisation was
> encouraged, no? In RDF, all of the sub properties (helpfully) inherit
> the range of skos:Concept from org:classification.

Indeed, that is fine. In the few minutes I had before the meeting I 
missed those relationships. It would help if the text pointed out when 
there are subproperty relations. Objection withdrawn.

>> (2) The relationship between legal:identifier and org:identfier needs to
>> be clarified. Org extends skos:notation and adopts existing practice
>> there, it would be helpful to at least explain why that's not
>> appropriate for legal:identifier.
>
> Sure. It's because skos:notation is a datatype property, usually used
> with typed string, whereas legal:identifer is an object property with a
> range of adms:Identifier which is based on the UN/CEFACT complex type.

I realize that is the difference :) The questions are:
  - whether that difference is justified
  - whether it is adequately communicated in the text
  - whether there is some useful relationship that can be stated.

Having now had a chance to look at the spec in more detail I think the 
Business Voc approach is justified and compatibility with UN/CEFACT 
(which I know too little about) is a good argument.

There is the question then of whether org should deprecate 
org:identifier and shift to using the same approach. On balance I think 
not. Org adopted the SKOS approach because that is common practice for 
representing identifier codes in Linked Data including Government Linked 
Data. Indeed at the time org was developed there were already groups 
using this approach to represent company identifiers.

So it may be that all that is needed is a bit of explanation in the text 
about why there is this divergence.

We may be able to go further and define a more formal relationship. It 
seems to me that one property on an adms:Identifer should be a notation 
that can be used for it in normal SKOS style. Then we could say that:
       org:identifier = legal:identifier o adms:notation

The UML diagram suggests that what I would call a notation is split 
between adms:identifier (lexical form) and adms:identifierType and that 
the latter is just a string (!!). So close but not quite there yet.

> This is relevant to your next point too.
>
>>
>> (3) The specification uses the term "Abstract Data Type" but does not
>> define it. Presumably it is defined in ADMS but (a) that means this spec
>> fails to standalone, (b) this should simply be rdfs:range.
>
> Right - I need to be clearer. The ISA Programme vocabs are concept
> schemes that can be expressed in any technology, notably RDF *and* XML.
> Something I need to bring to the group is how we handle the latter.
> Ideally conneg would return the relevant schema. Therefore, it really as
> an abstract data type, made less abstract by the (multiple) schemata.

Yes it needs to be a lot clearer and you need to state how his notion of 
"concept scheme" maps into RDFS/OWL.

By the way I was specifically thrown by the term "Abstract Data Type" 
because that has connotations for me going back to formal methods 
days[1] and you don't mean an ADT in that computer science sense. I 
notice that the ADMS draft uses "Data type" instead. Well it also uses 
"Target" which just adds to the confusion. The documents should be 
internally and mutually consistent.

>> (4) Specific Abstract Data Types are mention but none of them are
>> defined: Text, Code, Identifier, Address, Legal Entity.
>> [Of course, I realize that "Legal Entity" is supposed to refer to
>> legal:LegalEntity but that should be explicit.]
>
> Yes, I should have defined Code, Text etc. that's sloppy (I need to copy
> and paste the defs from the ADMS spec). In RDF, Code = skos:Concept,
> Text = rdfs:Literal but that doesn't apply as neatly in XML.

In ADMS there is "text" as opposed to "Text" but there it specially 
refers to a language tagged string. I'm not sure you mean that here but 
it seems like it is more specific than rdfs:Literal.

>> The latter two worry me, I'd rather we didn't end up introducing new
>> terminology for expressing RDFS/OWL vocabularies.
>
> Absolutely not! But I need to make it triply clear that we're not trying
> to do anything like that.

Yes. Among other things it might help if both Business and ADMS used 
curis for talking about the classes and properties, instead of the 
informal names in the UML and tables.

>>> Conformance
>>> ===========
>>> Both of these documents include a suggested text for conformance on
>>> which I would be grateful to receive feedback and, when appropriate, WG
>>> approval. I *think* it's what the group decided on the call we had a few
>>> weeks back with Rufus but it needs WG review.
>>
>> I thought we talked about conformance also requirement conformance with
>> the given semantics for the terms.
>>
>> If I use legal:legalIdentifier but give it's value as a string am I
>> conforming?
>
> No. It's an object property that has a range of adms:Identifier for
> which the advice is to use skos:notation to provide the string (plus
> other properties that effectively provide metadata about the string -
> based on the UN/CEFACT model).

That's what I expected. It was a rhetorical question.

So shouldn't the conformance statement have a clause that if you use a 
term from the spec you should use it compatibly with the spec's 
semantics for that term?

That does raise the question of how you specify that semantics if the 
normative for is this "concept scheme" style and how that relates to the 
more precise semantics given in the OWL rendering of that.

 > ... which the advice is to use skos:notation ...

Where is that advice?

The entire description of adms:Identifier in the ADMS spec seems to be: 
http://dvcs.w3.org/hg/gld/raw-file/default/adms/index.html#dt_identifier
which doesn't specify the names or URIs of any of the properties 
involved let along say how they related to SKOS.

> On conformance, should we not only say that it means using the classes
> and properties presented rather than minting new ones, but also using
> them in accordance with the data model presented?

Yes, that's what I'm saying except that the term "data model" might 
cause problems. See above comment on what semantics is for the notation 
being used in these specs.

Dave

[1] http://en.wikipedia.org/wiki/Abstract_data_type

Received on Thursday, 6 September 2012 17:51:10 UTC