Re: [Moderator Action] RE: SKOS Public Working Drafts

Hi Alistair,

> Dan Connolly has found that inverse properties are actually costly for implementers [1].  I can see it both ways - that in some situations having inverse properties adds convenience, and in others it makes things more complicated.  So I'm not sure what our position should be re inverse properties in SKOS Core, I'm interested to hear other's experiences.

When were they too costly ([1] does not provide details)?

In any case it's a good point. From a modeling point of view I'd like 
to include max semantics, but if they are a nuisance instead of a help...

> The note properties have domain rdf:Resource, because we didn't want to constrain their use.  We anticipated that some note properties would be useful with e.g. RDF properties and RDFS classes (as e.g. SKOS Core uses skos:definition on it's own properties and classes).

Just some side-thoughts, not relevant to the review:

I see the point, but it makes me wonder why then do we ever supply a 
domain and range for a property? And what do we loose in this case by 
  not stating domain and range? Actually what we are saying is that 
these properties are so generic that they can be applied to any 
resource. This almost seems to me the same as admitting that the 
properties really belong to another (more general) vocabulary, like DC 
(although that's for metadata)?

> The note properties have no range because we're currently allowing either literals or resources in the range, according to the patterns described in [2].  Again, I look forward to hearing practical feedback on whether this type of flexibility proves too complex or costly to implement.

+1!

> Maybe I should put together a proposal that adds OWL datatype property and object property type statements for SKOS Core properties where appropriate?

More side-thoughts:

Because of the remark of Dan you quote, the actual question becomes: 
what should we do with OWL in general? Should we select the OWL 
statements we want to include according to implementation concerns? 
Should we include max semantics regardless of implementation? Or 
should we have e.g. different versions of SKOS that give increasing 
semantics at the cost of efficiency? E.g. place the 
object/datatype/inverseness statements in another namespace to be 
processed only when one wants to commit to the additional semantics? 
I've had this thought of "incremental schemas" with "increasing 
commitment" floating in my head for a while, but no clear view what 
the practical issues or consequences are.

Mark.

-- 
  Mark F.J. van Assem - Vrije Universiteit Amsterdam
        mark@cs.vu.nl - http://www.cs.vu.nl/~mark

Received on Tuesday, 2 August 2005 14:41:01 UTC