Re: SKOS Basic Extensions

Hi Drew

Comments and suggestions below - skipping all the "head" RDF syntactic sugar


                <rdf:Property rdf:about="&base;describedRelated">
>
>                                 <rdfs:domain rdf:resource='&skos;related'
> />
>

You can't really do that because &skos;related is not a class, but a
property. Actually this domain declaration would entail that "&skos;related"
is indeed a rdfs:Class (or owl:Class if you read this in OWL), leading you
to dangerous OWL-Full shores.
The domain of "&base;describedRelated" in your logic should be, if I catch
well the intention, the class of reified &skos;related statements, which I'm
not sure if it can be defined properly, and actually I'm not eager to wander
further down this scary reification track :))

A workaround we (at Mondeca) use for such situations is to create a class,
say "&base;skosRelation" with a "&base;isRelated" object property to attach
the (two) related concepts, and to this class you can attach through
rdfs:domain any property you want for a full information about the
relationship: description, creation date, modification date, source,
creator, basically all the Dublin Core elements can fit there if you really
want to track the full history of the relationship.

Formally, you can construct the instances of this Relation class from
skos:related predicates using SPARQL CONSTRUCT transformations.
(skipping again the prefix declarations). Note that the relation instances
are created as blank nodes.

CONSTRUCT { _:r  a  base:Relation.
                      _:r  base:isRelated ?c1.
                      _:r  base:isRelated ?c1.}

WHERE  {?c1   skos:related   ?c2}

And then you can add your metadata

_:r   dcterms:description   'bla bla'
_:r   dcterms:created  '2010-01-14'
_:r   dcterms:source   ex:foo

etc.


                <rdf:Property rdf:about="&base;defSource">

                                <rdfs:domain rdf:resource='&skos;defintion'
/>

Same as above, you can't use skos:definition as a rdfs:domain, for similar
reasons.

I would suggest instead either of the following :

- Use a subproperty of skos:note  such as base:definitionSource. This might
work if your concepts have only one definition.

- If you have several definitions with different sources for the same
concept, you have to go through a base:Definition class, in order to have
definitions declared as first-class citizen resources, and attach the
sources to those objects using there again e;g., dcterms:source. The
base:Definition instance is linked to the skos:Concept using a
base:hasDefinition object property. The text itself of the definition being
attached using a base:definitionText.

And again in the latter case you can construct the instances of
base:Definition using SPARQL

CONSTRUCT { _:d  a  base:Definition.
                       _:d   base:definitionText 'bla bla'.
                       ?c   base:hasDefinition _:d }

WHERE  {?c   skos:definition  'bla bla'}

And from there add the dublin core elements

_:d  dcterms:source  ex:foo

_:d  dcterms:created  '2010-01-14'

etc.

This is a very general principle. If you want further information on data
values, promote them to "resource" status in order to allow descriptions. An
illustration is SKOS-XL.

In the "definition" example one could define property chains like those
defined in SKOS-XL.

Beyond that, your extensions of skos:altLabel seem perfectly correct.

Hope that helps.

Bernard


-- 
Bernard Vatant
Senior Consultant
Vocabulary & Data Engineering
Tel:       +33 (0) 971 488 459
Mail:     bernard.vatant@mondeca.com
----------------------------------------------------
Mondeca
3, cité Nollez 75018 Paris France
Web:    http://www.mondeca.com
Blog:    http://mondeca.wordpress.com
----------------------------------------------------