W3C home > Mailing lists > Public > public-powderwg@w3.org > July 2008

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

From: Paul Walsh <paul@segala.com>
Date: Wed, 9 Jul 2008 07:38:55 +0100
Message-Id: <0C565A92-1204-409F-ABC0-5D12805B864D@segala.com>
To: Phil Archer <parcher@icra.org>
Cc: Charles McCathieNevile <chaals@opera.com>, Public POWDER <public-powderwg@w3.org>

Charles said he would withdraw if he was the only one, so let's move  
on :)

---
http://paulfwalsh.com/

Sent from my iPhone so apologies if my note is shorter than usual.

On 9 Jul 2008, at 06:38, Phil Archer <parcher@icra.org> wrote:

>
> 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] http://lists.w3.org/Archives/Public/public-powderwg/2008Jul/0029.html
>
>
> 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 <parcher@icra.org>  
>> 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]http://xmlns.com/foaf/spec/#term_Agent
>>>> [2]http://dublincore.org/usage/terms/history/#Agent-001
>>>> [3]http://lists.w3.org/Archives/Public/public-powderwg/2008Jul/0029.html
>>>>  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] http://lists.w3.org/Archives/Public/public-powderwg/2008Jul/0028.html 
>>>>>  onwards
>>>>>
>>>>
>
>
>
Received on Wednesday, 9 July 2008 06:40:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:42:13 GMT