The dcterms properties which are currently subproperties of DCMES properties could be subproperties of both the DCMES property and the new cloned property, right?
i.e.
dcterms:modified rdfs:range someclass:Period .
dcterms:date rdfs:range someclass:Period .
dcterms:modified rdfs:subpropertyOf dcterms:date .
dcterms:modified rdfs:subpropertyOf dc:date .
And probably better would be:
dcterms:modified rdfs:range someclass:Period .
dcterms:date rdfs:range someclass:Period .
dcterms:modified rdfs:subpropertyOf dcterms:date .
dcterms:date rdfs:subpropertyOf dc:date .
I guess it depends whether we want systems to go on inferring the dc:date triple - but I think we will? We want to continue to support systems that only grok the current DCMES 15. i.e we want systems that find
doc:x dcterms:modified date:y .
to infer not only
doc:x dcterms:date date:y .
but also
doc:x dc:date date:y .
Neither of these approaches above would imply a range for dc:date, so they don't break any of the systems using literal values for dc:date.
Pete
-----Original Message-----
From: DCMI Architecture Group on behalf of Dan Brickley
Sent: Wed 9/27/2006 7:02 PM
To: [log in to unmask]
Subject: Re: ODF Metadata and DC
Bruce D'Arcus wrote:
> On Sep 27, 2006, at 10:54 AM, Pete Johnston wrote:
>
>> I think the suggestion was that we _do_ assert domains/ranges for those
>> properties, on the grounds that - based on the dat Mikael got via
>> Swoogle - they are much less widely used than the DCMES 15. So, yes,
>> there would be an impact, but less so than if we did it for the DCMES
>> 15.
>
> So in that case, you'd assert domains/ranges for them, AND change them
> to be sub-properties of the new dcterms properties?
Sounds like a plan. Is tommorrow too soon to implement it?
Dan
|