tis 2009-09-01 klockan 18:50 +0200 skrev Bernard Vatant:
> Hello all
>
> I've had last week private exchanges with Tom Baker about the
> definition of the range of a certain number of dcterms properties,
> which are currently let open in the specification document at
> http://dublincore.org/documents/dcmi-terms/. Among those are
> dcterms:language and dcterms:subject. I will let the former for a
> further message, and focus here on the latter.
Umm, dcterms:language has range
http://purl.org/dc/terms/LinguisticSystem
(leaving the rest of your message for later comments)
/Mikael
>
> Now that the SKOS specification has been cast in stone by W3C, it
> seems that instances of skos:Concept should be natural candidates for
> being values of dcterms:subject, but it is too restrictive to have in
> the specification something like the following
>
> dcterms:subject rdfs:range skos:Concept
>
> Nevertheless, it would be a good idea to express that instances of the
> class skos:Concept are among the ones that can be used as values of
> dcterms:subject.
> So I've came to the following idea, which I would be happy to discuss
> here. Since we don't know how the RDF landscape will evolve, we
> certainly don't want to specify the range of dcterms:subject beyond
> the fact that it contains skos:Concept. The way to do this is as
> following :
>
> dcterms:subject rdfs:range _:b
> skos:Concept rdfs:subClassOf _:b
>
> The semantics of rdfs:range and rdfs:subClassOf entails that the blank
> node _:b is of type rdfs:Class, but the two above statements keep
> agnostic on the extension or any description of this class, beyond the
> fact that it is a superclass of skos:Concept.
>
> Note that those statements, although apparently perfectly valid and
> capturing the intended semantics, are not well handled by
> out-of-the-shelf ontology editors. Having a class declared only as the
> object of predicates, with no description, and morever no URI, does
> not make Protégé and Swoop very happy (not tried others). You can't
> construct this using the interface, and the import is not very
> successful either ...
>
> Can we proceed from this to something understandable by specification
> human readers, and tractable by current RDF tools?
>
> Best
>
> Bernard
|