W3C home > Mailing lists > Public > public-esw-thes@w3.org > April 2014

Re: TGN place types (broader/narrower spanning ConceptSchemes)

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Fri, 11 Apr 2014 09:22:09 +0200
Message-ID: <53479821.70408@few.vu.nl>
To: <public-esw-thes@w3.org>

Just a quick reaction on some points

>> In theory I agree it would be interesting to model the 'place-dependency' of place type links with a (possibly CIDOC-CRM inspired) event.
>> (btw the CRM pattern would have the same sort of complexity I believe, so TGN won't be really worse if they use reification).
> Indeed. One would use:
> - a direct link P2_has_type (shortcut), and
> - a reification E17_Type_Assignement (longcut) together with P42_assigned and P41_classified
> But note that there's no way to say when a Type stopped being used:
> there is E15_Identifier_Assignement.P38_deassigned, but no similar property for E17_Type_Assignement

Hmm. I'm not sure I understand the need to define a property as specific as P38, which couldn't be applied to another kind of assignment...
Anyway, I believe it would be acceptable to use whatever property CRM has for the ending of a (long) event.

>> 'type' usually indicates the class of which something is a member.
>> gvp:placeType should be a sub-property of rdf:type.
>> If the place-types have been modelled as individuals, then you need to 'pun' them to classes when using them this way.
> rdf:type brings a lot of ontological commitment (and baggage) with it.
> I think the thesaurus people would explain better than me why skos:broader has no relation to rdf:type and rdfs:subClassOf
> But here are a couple of considerations:
> - if we do that, surely we should also make every broaderGeneric be rdfs:subClassOf.
>    And for uniformity we need to do it for all AAT concepts, not just place types.

(also to complement what Osma said about our 'good reasons')
I'm not sure I count as 'thesaurus people' but I was closely involved in SKOS...
In fact the idea of having BTI = rdf:type and BTG = rdfs:subClassOf was strong when we considered making the old SKOS extension in the standard.

As a matter of fact as a W3C group we should have clarified the relationship of these BTI/BTG properties to RDFS/OWL, as they looked so close to what RDFS/OWL allow.
But it seemed to us going a bridge too far. The composition rules had not been studied too much (as the discussion we're having now proves it, years after). And we were really not sure that the quality of the data would have allowed that. Rather, we anticipated that this sort of equivalence would result in countless buggy classes and sub-class links, after OWL inference.
The inability to fix these formal semantics was actually a strong point in not including the extension altogether.

Received on Friday, 11 April 2014 07:22:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:46:36 UTC