Thomas Baker wrote:
> Andy's DCPropertyDomainsRanges draft [1] uses 30-40
> "possible classes" as proposed domains and ranges for all
> DCMI properties. For the domains and ranges to be declared
> machine-readably, these classes would presumably need to be
> defined, approved, given URIs, and maintained. Giving them
> URIs would involve either expanding the DCMI Type Vocabulary
> or creating a new Vocabulary.
Or they could be give "dcterms" URIs.
Note that for some of the classes suggested for domain/ranges, there are
already existing classes in the DCMI Type Vocabulary (collection,
service) that fit the bill, so it would be redundant to create new
classes for those two. I'm not necessarily using that as an argument for
saying that it follows that they should all be given "dcmitype" URIs,
just pointing out that those classes exist.
> Creating a new Vocabulary
> would involve revising the DCMI Namespace Policy.
>
> Giving them definitions would presumably also involve deciding
> on a style for definitions that is consistent between the DCMI
> Type Vocabulary and this new Domain-Range Vocabulary:
Maybe worth noting that the "vocabulary encoding schemes" in the dcterms
vocabulary are also classes, so ideally there should be consistency with
the literals in those descriptions too.
> -- Current DCMI Type Style: "A service is a system that provides..."
>
> -- DCMI Type Style, Renaud style: "A resource which is a system..." [2]
>
> -- Domain-Range Vocabulary style: "The class of all services..." [1]
Strictly speaking the resource identified by the URI is a class and the
third form is probably a more literal(!) reflection of that. The first
two styles describe/define the class by describing/defining an instance
of the class. I think that is quite widespread practice and I don't see
it as a problem. But I agree that a consistent approach would be good.
> Andy, how do you propose we approach this, and what would be
> the goal for the Seattle discussion?
Pete
|