native scheme membership and rdfs:isDefinedBy

> Lastly, I have two questions concerning the use of the 
> rdfs:isDefinedBy
> property in SKOS:
> 
> - If a skos:definition is used in conjunction with the "Document
> Reference Usage Style", is this equivalent to the 
> rdfs:isDefineBy property?
> 
> - I don't understand the "defining scheme rule"
>    (x isDefinedBy y -> x inScheme y) for two reasons:
> 
>    (1)     The RDFS spec says that isDefinedBy is used to point to a
>      resource y (possibly not web-retrievable) that defines x. What
>      is the relation to a property defining membership of a Concept
>      to a ConceptScheme? I don't think a ConceptScheme itself really
>      "defines" a concept in the same way a piece of text or a
>      document does.
> 
>    (2)    How does a general (x isDefinedBy y) statement in a 
> random RDF
>      graph imply that x is a skos:Concept and y is a
>      skos:ConceptScheme? Should the implication be the other way
>      around?

As Mark's comments above illustrate, I did get this bit completely wrong :)


What I was trying to do was to find a way for people to make a distinction
between a statement of the inclusion of a concept within its 'native'
conceptual scheme, and the inclusion of a concept within a 'foreign'
conceptual scheme (where it has been 'imported').

I.e. we have the usage scenario that people will publish concepts as part of
a conceptual scheme, and then others will reuse those concepts piecemeal and
include them in their own schemes.  Where a concept is included in more than
one scheme, it would be good if you could assert which of the schemes was
the 'original' or 'native' scheme.  But rdfs:isDefinedBy is obviously to
broad for this purpose.

Some suggested alternatives (if it is agreed that we should have vocab to
support this) ...

(1) We create a new property like e.g. skos:inDefinitiveScheme as a sub-prop
of skos:inScheme to assert a relationship between a concept and its original
scheme.

(2) We create a new property like e.g. skos:importedInScheme as a sub-prop
of skos:inScheme to assert a relationship between a concept and a concept
scheme in which it is imported.

(3) We create a new property like e.g. skos:importsConcept (essentially
inverse of (2)).

(4) We re-use owl:imports somehow ???

Anyone got any good ideas?

Cheers,

Al.

Received on Monday, 24 January 2005 16:07:38 UTC