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

wdrs:issuedby fc. foaf:maker and dcterms:creator

From: Phil Archer <parcher@icra.org>
Date: Sat, 19 Jul 2008 11:30:57 +0100
Message-ID: <4881C261.5030304@icra.org>
To: Public POWDER <public-powderwg@w3.org>

Andrea, I hope you don't mind me moving this to the public list and 
renaming the thread - it's an important discussion. Thanks for pursuing it.

Andrea Perego wrote:
[...At the face to face last week we recognised that the problem with 
>> wdrs:issuedby owl:equivalentProperty foaf:maker
>> wdrs:issuedby owl:equivalentProperty dcterms:creator
>> is that it is inescapable that
>> dcterms:creator owl:equivalentProperty foaf:maker
>> is also true - which would bring the anger of several people upon our 
>> heads. Charles seemed sure that by using sub property of we got what 
>> we wanted without upsetting anyone.
> I agree completely.
>> wdrs:issuedby rdfs:subPropertyOf foaf:maker
>> wdrs:issuedby rdfs:subPropertyOf dcterms:creator
>> says that all instances of issuedby are also instances of the other 
>> two but does not make the assertion that all instances of foaf:maker 
>> are also instances of dcterms:creator. 
> Yes. What we assume is that *some* instances of foaf:maker are also 
> instances of dcterms:creator, otherwise the property extension of 
> wdrs:issuedby would be empty. However,
>   wdrs:issuedby rdfs:subPropertyOf foaf:maker .
>   wdrs:issuedby rdfs:subPropertyOf dcterms:creator .
> does not necessarily imply any relation between dcterms:creator and 
> foaf:maker - i.e., our assumption may well be wrong, and the property 
> extension of wdrs:issuedby may be empty. So, we don't hurt anyone.


>> The key thing is that you can use wdrs:issuedby to point to either 
>> foaf:Agent or dcterms:Agent and that we're not REQUIRING the use of 
>> FOAF (just making it easy for people to use it in a POWDER environment 
>> without making it impossible to use dcterms).
>> I hope that's all true because I've just changed _all_ the examples ;-)
> It's true in the sense that the range of wdrs:issuedby is the 
> intersection of the class extensions of foaf:Agent and dcterms:Agent. 
> I.e., the author of a POWDER doc is *both* a foaf:Agent *and* a 
> dcterms:Agent.

That's the idea, yes

  If we want that the author of a POWDER document were
> *either* a foaf:Agent *or* a dcterms:Agent, wdrs:issuedby must be 
> defined differently (i.e., the range of wdrs:issuedby must be the union 
> of the class extensions of dcterms:Agent and foaf:Agent).

What we want to be able to do is either of



_without_ having to define our own Agent class - 2 is enough already!

> The question in my previous email was also related to the fact that, in 
> the current version of the docs, POWDER-S examples use dcterms:creator. 
> Does this mean that you can use either dcterms:creator, foaf:maker, or 
> wdrs:issuedby in the attribution of a POWDER-S doc?

No. The idea is that in POWDER-S you should always see this

<owl:Ontology rdf:about="">
     Agent here or referenced using rdf:resource= on issued by property

Now... POWDER-S /can/ be written independently of any originating POWDER 
doc and, even if it is created by performing a transform on such a doc, 
we say that syntactic differences don't matter as long as the semantics 
are the same - i.e. the POWDER XSLT is not normative.

Therefore, as I understand it, a POWDER-S doc could say

<owl:Ontology rdf:about="">
     Agent here or referenced using rdf:resource= on maker property

but is this so given what we say about semantic equivalence?

We're stuck between practicality and broad acceptance on the one hand 
(i.e. FOAF) and future-proofing/standardisation on the other (i.e 
dcterms). So we're trying to have our cake and eat it by just defining 
the property and leaving the choice of the DR author.

Now, at the f2f, we weren't 100% sure we had it right so if, in the cold 
light of day, this is an error then we'll need to go back to allowing 
the use of either maker or creator directly - we really can't make it 
hard for people to do what comes naturally so to speak. But the keeping 
it simple by mandating a single property - the only one that MUST be 
included in every POWDER doc - does have its attractions too.

Received on Saturday, 19 July 2008 10:31:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:04 UTC