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

Regarding the XML Schema part: yes; you can enforce a choice.
Kev

----- Original Message -----
From: public-powderwg-request@w3.org <public-powderwg-request@w3.org>
To: Charles McCathieNevile <chaals@opera.com>
Cc: Public POWDER <public-powderwg@w3.org>
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] 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:54:21 UTC