Re: PROPOSED RESOLUTION: use dcterms for the maker element and rename to creator

Hmmm... very interesting.

Maybe we should return to Kai's question and see whether we really could 
have our cake and eat it - i.e. allow either FOAF, DC... or anything else.

Let me think aloud here... imagine a POWDER property of wdr:author that 
had a range of anything, that would allow you to use either FOAF or DC - 
but it would also allow you to use neither and just stick in any old 
thing that may or may not have a meaning, so that doesn't sound too good 
to me

If we define the range of wdr:author as both foaf:Agent and 
dcterms:Agent we clearly support both but restrict it to those (at least 
formally). Doing this means we still reference FOAF directly in our 
documentation therefore won't need to think about creating our own logo 
property in favour of foaf:logo.

How would that be?


Charles McCathieNevile wrote:
> There are a few points in this discussion that make me not vote for the 
> proposal.
> I think that it is important to have something where RDF machines can 
> actually process RDF. foaf:Agent has real subclasses we want, dc:Agent 
> doesn't, yet. There are also the useful properties of an Agent the foaf 
> provides to describe it.
> I think the foaf:logo property is useful (although non-critical).
> FOAF is, in practice, remarkably widely adopted, and probably in overall 
> quality the use is no worse and perhaps better than DC. As an 
> implementor, we don't see that there is any special problem using this 
> vocabulary - the people who maintain it have shown themselves to 
> understand normal standards processes, be responsive and helpful, 
> provide the kind of stability that is needed for a standard, and I don't 
> see evidence that the community around FOAF is any different.
> If I am the only one voting against, I will withdraw. If foaf:Agent were 
> defined as a subclass of dcterms:Agent, then the point would become 
> moot, although we would still have a messier schema. But as things 
> stand, I don't see the need for this change.
> cheers
> Chaals
> On Tue, 08 Jul 2008 16:56:35 +0200, Phil Archer <> wrote:
>> All valid points Andrea.
>> I'm not sure how strictly property ranges are ever actually enforced. 
>> There are plenty of instances of <dc:creator 
>> rdf:resource="http://...foaf.rdf#me" on the Web and the range of 
>> dc:creator is string. Actually, I believe it is this fact, that 
>> emerged at the 2005 DC conference that I had the pleasure of 
>> attending, that was one of the drivers for the change to dcterms:creator.
>> In other words, my guess is that we may well see quite a few 
>> dcterms:creator elements pointing to a foaf:Organization class... and 
>> UAs may or may not notice.
>> P
>> Andrea Perego wrote:
>>>  +1 from me too.
>>>  The only issue I see here is that, this way, DR authors should use 
>>> dcterms:Agent instead of foaf:Person / foaf:Organization in their RDF 
>>> (FOAF?) /profile/ (i.e., the set of RDF statements describing the DR 
>>> author). And foaf:Person / foaf:Organization are more "popular" than 
>>> dcterms:Agent, as far as I know. And it may be often the case that a 
>>> DR author already has a FOAF profile to pointing to: should he/she 
>>> modify it?
>>>  Probably this will be fixed in the future. According to their formal 
>>> definition, between foaf:Agent (and its subclasses) and dcterms:Agent 
>>> there does not exist any subClassOf / equivalentClass relationship. 
>>> However, they look pretty similar - at least based on their NL 
>>> definition:
>>> - foaf:Agent: "An agent (eg. person, group, software or physical 
>>> artifact)." [1]
>>> - dcterms:Agent: "A resource that acts or has the power to act. 
>>> Examples of Agent include person, organization, and software agent." [2]
>>>  If I'm not mistaken, this may correspond to one of the 
>>> foaf<->dcterms mappings that Dan mentioned in his mail [3].
>>>  Andrea
>>>  [1]
>>> [2]
>>> [3]
>>>   Phil Archer wrote:
>>>> Following my exchange with Dan Bri just now [1], I'd like to propose 
>>>> that we change the name of the POWDER <maker> element to <creator> 
>>>> and change the transform so that this becomes <dcterms:creator>.
>>>> Note that the legacy (and commonly seen) dc:creator just takes a 
>>>> string whereas dcterms:creator has the range of dcterms:Agent.
>>>> This does not prevent using FOAF terms within a dcterms:Agent class 
>>>> (which is good because FOAF has some very useful terms already) but 
>>>> it does eliminate POWDER's formal dependence on FOAF.
>>>> We can consider the resolution properly next week at the f2f but if 
>>>> there are any comments ahead of that, please speak up.
>>>> Thanks
>>>> Phil.
>>>> [1] 
>>>> onwards

Received on Tuesday, 8 July 2008 16:22:38 UTC