Re: Revisiting foaf:maker (was Re: PROPOSED RESOLUTION: use dcterms for the maker element and rename to creator)

Smith, Kevin, (R&D) VF-Group wrote:
> Regarding the XML Schema part: yes; you can enforce a choice.
> Kev

Aha! Right, thank you, I think that gives us a way forward, cake and 
eating-wise. Taking all this on board (and not without sympathy to 
Paul's point!) how about this:

We use <creator> -> dcterms:creator -> dcterms:Agent in our examples

We state that <maker> -> foaf:maker -> foaf:Agent is an acceptable 
alternative, noting that, at the time of this writing, it seems likely 
that the two will come into even closer alignment



> ----- Original Message -----
> From: <>
> To: Charles McCathieNevile <>
> Cc: Public POWDER <>
> Sent: Wed Jul 09 07:38:47 2008
> Subject: Revisiting foaf:maker (was Re: PROPOSED RESOLUTION: use dcterms for  the maker element and rename to creator)
> I've been much vexed by this discussion. In summary:
> - We have used FOAF so far for the reasons Charles articulates
> - And yet Dan Bri himself says: "my recommendation would be to make sure 
> the basic creator/Agent thing is doable in plain DC terms, but allow 
> FOAF for adding more optional detail" [1] (did you see that Charles?)
> There's nothing to stop you putting FOAF properties inside a 
> dcterms:Agent class.
> - Kai asked whether we could let users choose. Doing this does make it 
> harder to check for validity against the schema - but does harder mean 
> impossible? i.e. is it possible in XML Schema to require either of 2 
> choices be used? Kev/Andrea?
> - Would defining our own property that had a a range of both 
> dcterms:Agent and foaf:Agent fix this? Well, it gives us a sort of fix 
> but a putative wdrs:author isn't dcterms:creator or foaf:maker so it 
> might make matters worse, not better.
> Ever wish you'd never asked a question?
> Phil
> [1]
> 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 Wednesday, 9 July 2008 07:01:32 UTC