Re: domain/range for skos props

 I most excitedly support this direction.. It forms the basis of a bridge
between the Information Science use of fact & facet categorization and
the Information Technology use of object & process classification.

carl

<quote who="Miles, AJ (Alistair)">

> This opens up a very interesting area of discussion.
>
> Currently, SKOS Core has the following structure (inherited from the
> original LIMBER RDF schema which was the ancestor of SKOS Core):
>
> skos:semanticRelation  a  rdf:Property;
>   rdfs:domain  skos:Concept;
>   rdfs:range   skos:Concept.
>
> skos:broader  a  rdf:Property;
>   rdfs:subPropertyOf  skos:semanticRelation.
>
> skos:narrower  a  rdf:Property;
>   rdfs:subPropertyOf  skos:semanticRelation.
>
> skos:related  a  rdf:Property;
>   rdfs:subPropertyOf  skos:semanticRelation.
>
> What this means is that there are no explicit *constraints* on the way
> skos:broader/narrower/related are used.
>
> What it means also is that an RDFS inference engine, given the following
> data:
>
> ex:A  skos:broader  ex:B.
>
> ... will firstly infer (from sub-property statement) ...
>
> ex:A  skos:semanticRelation  ex:B.
>
> ... and then will infer (from domain/range statements) ...
>
> ex:A  a  skos:Concept.
> ex:B  a  skos:Concept.
>
> One question I have is: what is the value of this behaviour?
>
> Relating back to Benjamin's initial point: if we decide that
> skos:broader/narrower/related should only be used with skos:Concepts, then
> this behaviour seems appropriate; however if we decide that it's OK to use
> skos:broader/narrower/related with any type of resource, then this
> behaviour
> seems inappropriate (??).
>
> An alternative would be to remove domain/range statements on
> skos:semanticRelation, but to introduce OWL restrictions on the
> skos:Concept
> class, e.g.
>
> <rdfs:Class rdf:about="#Concept">
>   <rdfs:subClassOf>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="#broader" />
>       <owl:allValuesFrom rdf:resource="#Concept" />
>     </owl:Restriction>
>   </rdfs:subClassOf
> </rdfs:Class>
>
> This means that skos:broader/narrower/related could be used with any type
> of
> resource, but when used on a skos:Concept must point to another
> skos:Concept.  (Is this the type of constraint we want?)
>
> Another idea I wanted to air for comment is the following:
>
>  - Add a new class skos:SemanticRelationProperty (sub-class of
> rdf:Property)
>  - Add a new class skos:SemanticRelationStatement (sub-class of
> rdf:Statement)
>  - (And possibly drop skos:semanticRelation, although not sure about that)
>
> The main reason for this is to support RDF descriptions of explicit scheme
> membership of semantic relationships (a requirement that has come to me
> from
> several sources).
>
> The new vocab above could have the following constraints:
>
> <rdfs:Class rdf:about="#SemanticRelationStatement">
>   <rdfs:subClassOf rdf:resource="&rdf;Statement"/>
>   <rdfs:subClassOf>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="&rdf;subject" />
>       <owl:allValuesFrom rdf:resource="#Concept" />
>     </owl:Restriction>
>   </rdfs:subClassOf>
>   <rdfs:subClassOf>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="&rdf;predicate" />
>       <owl:allValuesFrom rdf:resource="#SemanticRelationProperty" />
>     </owl:Restriction>
>   </rdfs:subClassOf>
>   <rdfs:subClassOf>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="&rdf;object" />
>       <owl:allValuesFrom rdf:resource="#Concept" />
>     </owl:Restriction>
>   </rdfs:subClassOf>
>   <rdfs:subClassOf>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="#inScheme" />
>       <owl:allValuesFrom rdf:resource="#ConceptScheme" />
>     </owl:Restriction>
>   </rdfs:subClassOf>
> </rdfs:Class>
>
> ... allowing validation of statements like:
>
> <skos:SemanticRelationStatement>
>   <rdf:subject rdf:resource="http://foo.com/#foobar"/>
>   <rdf:predicate rdf:resource="&skos;broader"/>
>   <rdf:object rdf:resource="http://foo.com/#bar"/>
>   <skos:inScheme rdf:resource="http://foo.com/scheme"/>
> </skos:SemanticRelationStatement>
>
> All food for thought :)
>
> Al.


-- 
Carl Mattocks

co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC
co-Chair OASIS Business Centric Methodology TC
CEO CHECKMi
v/f (usa) 908 322 8715
www.CHECKMi.com
Semantically Smart Compendiums
(AOL) IM CarlCHECKMi

Received on Thursday, 21 October 2004 15:48:26 UTC