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

Hi,

> The problem is that preferred labels should be unique within the context of a given language, but a concept may have a preferred label in english and a preferred label in french, for example.  E.g.
> 
> <skos:Concept rdf:about="X">
> 	<skos:prefLabel xml:lang="en">Fish</skos:prefLabel>
> 	<skos:prefLabel xml:lang="fr">Poisson</skos:prefLabel>
> </skos:Concept>
> 
> As far as I know, you cannot represent that constraint using OWL.  

The only way to do it would be to introduce properties 
"englishPrefLabel", "frenchPrefLabel" etc. and put cardinality 
constraint on that, but I don't think that's a nice approach...



> You're right, this relationship should be captured somehow.  One (hack) way would be to assert {skos:inScheme owl:inverseOf skos:hasTopConcept.}, although a better way would be to declare a new property {skos:hasConcept rdfs:subPropertyOf skos:hasTopConcept; owl:inverseOf skos:inScheme.}.  I wouldn't object to making this addition.  

That's also fine with me. Actually it's one of the few object 
properties without inverse now (others are the various label properties).

But why not just have an inverse of hasTopConcept, e.g. 
isTopConceptOf? In any case I think the subPropertyOf relationship 
should be the other way around.

When I was reading the Core Spec [1] I noticed some other things:

- the note properties do not have domain and range declared for them
- the deprecated (moved to extension vocab) narrowerGeneric, 
broaderPartitive, etc. should be declared transitive (transitivity is 
not inherited in OWL)
- the note/label properties have no domain defined for them (I would 
expect skos:Concept?)


> Again I wouldn't object to an inverse property, although the whole PSI area probably needs further study.

This pops up the question with me whether it should be good practice 
to always provide all the inverses of all object properties.


> I depends on the situation.  You can probably re-use other people's concepts, if you trust that those concepts are stable.  The problem would come if you re-use someone else's concepts and they get changed.  I'm glad you brought this up, we probably ought to directly address the issue of 're-use' in the guide.

There are always situations in which you would go for either option 
depending on your situation (hence some mapping vocabulary might be a 
good idea).

> Flexibility is one factor.  For example, currently you can use the SKOS Core documentation properties with either a literal or a blank node or a named resource.  Without this flexibility we would have to add a lot more properties or classes to SKOS, and the extensibility would be complicated.  Also several of the SKOS Core constraints cannot be expressed in OWL, as described above.  However, if there are any particular semantics or rules that could be expressed in OWL, I'd be more than happy to have them added.  Should we declare that {skos:semanticRelation a owl:ObjectProperty.} for example?

Would there be a reason not to declare it for all object properties?

Cheers,
Mark.

[1] http://www.w3.org/TR/swbp-skos-core-spec/


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

Received on Monday, 11 July 2005 08:56:05 UTC