Re: Business Voc and ADMS

Dave, everyone,

I've made more edits to the legal RDF schema in line with this. I've 
also corrected some minor errors - which I need to check again before 
pushing this to the namespace itself.

Changes:
- declared object and data type;
- tidied up definition of legal:identifier
- tidied up the metadata

Updated version available at same URI:
http://dvcs.w3.org/hg/gld/raw-file/default/legal/legal20120906.rdf

Need to go through ADMS schema with same intentions.

Cheers

Phil.

On 06/09/2012 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.
>
>>
>> (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.
> 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.
>
>>
>> (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.
>
>>
>> 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.
>
>>
>>> Alongside the spec, I'd like to publish the RDF schema and associated
>>> namespace document. Currently there is a holding page at
>>> http://www.w3.org/ns/legal# that is becoming increasingly embarrassing.
>>
>> I've no objection to this.
>>
>> Minor: I would prefer use of owl:DatatypeProperty and owl:ObjectProperty
>> where appropriate rather than making everything an rdf:Property - that
>> conveys intention a little more clearly.
>
> Irene made a similar comment, I'll do that before pushing the schemas to
> /ns
>
>>
>>> 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).
>
>>
>> Suppose I use a URI there, such as one minted by UK Companies House but
>> not declared as an adms:Identifier, am I conforming?
>
> One could take a narrow view and say yes. The inference being that the
> Companies House URI is an adms:Identifier. However, the model breaks at
> that point since all the data you get back from a Companies House URI is
> about the particular company whereas the properties of the
> adms:Identifier class are about the identifier (it has a skos: notation
> of 04285910, it was issued by Companies House on 12/09/2001 etc.) ... so
> it would be a case of GIGO.
>
> Actually, something analogous to skos-xl might be useful for this and
> other cases - i.e. "notation-xl". There is a string, like "04285910" and
> I want to make statements about it beyond just its type. That
> potentially gets us into provenance as well?
>
> 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?
>
> Phil.
>
>

-- 


Phil Archer
W3C eGovernment
http://www.w3.org/egov/

http://philarcher.org
+44 (0)7887 767755
@philarcher1

Received on Thursday, 6 September 2012 17:18:03 UTC