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

Re: PROPOSED RESOLUTION of attribution (again!)

From: Stasinos Konstantopoulos <konstant@iit.demokritos.gr>
Date: Tue, 22 Jul 2008 15:41:10 +0300
Cc: Public POWDER <public-powderwg@w3.org>
Message-Id: <2F736EE5-80FA-4E37-A502-294E9196BC2F@iit.demokritos.gr>
To: Phil Archer <parcher@icra.org>


Phil,

the gentlemen might be less upset if reassured that we shall not place  
any range or
other restrictions on issuedby. In this manner, the subPropertyOf  
assertion is used
to state something about issuedby based on DC and FOAF vocabulary,  
rather than
the other way around.

Anyway, like you said, let us wait and see what comments we get.
But please do mention this alternative in the
LC versions, as well as the alternative of requiring either foaf:maker  
or dc:creator
in POWDER/XML and not defining a new property.

s


On Jul 22, 2008, at 2:19 PM, Phil Archer wrote:

>
> Thanks Stasinos,
>
> We really need some feedback from the wider community on this which  
> is why the Last Call version of the DR doc (soon to be sent to group  
> members) has a note in the status section specifically seeking  
> feedback on this issue.
>
> Your idea makes perfect sense from a logical point of view, however,  
> it has a political problem - we can't make other people's properties  
> sub properties of our own - Tom Baker (DCMI) and Dan Bri (Mr FOAF)  
> would be justifiably upset if were to do that I think.
>
> Let's see what the outside world says during Last Call - which  
> should start next week and ends on 29/8.
>
> Cheers
>
> Phil.
>
> Stasinos Konstantopoulos wrote:
>> Hi there,
>> Please allow me to assume as a premise that POWDER/XML needs to  
>> allow any of the attributions below:
>> (1)
>>  <issuedby>
>>    <foaf:Agent>
>>      <foaf:name>stasinos</foaf:name>
>>    </foaf:Agent>
>>  </issuedby>
>> (2)
>>  <issuedby>
>>    <dc:Agent>
>>      <dc:name>stasinos</dc:name>
>>    </dc:Agent>
>>  </issuedby>
>> (3)
>>  <issuedby XXX="http:/link.to/stasinos" />
>> (XXX can be rdf:resource or src or ref or whatever our XML experts  
>> say is appropriate
>> and http:/link.to/stasinos is either FOAF or DC, and the POWDER  
>> Proc cannot decide which)
>> If there were a different element name or XXX for FOAF and DC, then  
>> the transform could
>> produce POWDER-S which only has dc:creator or foaf:maker (whichever  
>> is appropriate),
>> thus solving all our SemWeb woes by making issuedby invisible to  
>> RDF.  A very similar solution
>> is to have the actual dc:creator or foaf:maker properties in POWDER/ 
>> XML; this was the situation
>> up until before the London F2F.
>> This did not sound bad at all, but matters got complicated since it  
>> is now a desideratum that
>> POWDER/XML defines its own issuedby element which is pointing to  
>> either foaf:Agent
>> or dc:Agent instances, either pre-defined or embedded in the POWDER  
>> doc. This has the
>> advantage of extendibility, as a future FOAF or DC-like schema  
>> conquering the
>> semantic world can be easily added under the hood without touching  
>> the surface form
>> of POWDER/XML documents.
>> Given the fact that the XML->RDF/XML transform cannot possibly know  
>> what issuedby is
>> pointing to, issuedby has to survive the transform and reach RDF- 
>> land. The problem is
>> that a new property is introduced which does not mean anything to  
>> RDF tools at large,
>> so the group feels the need to relate it to existing and well- 
>> understood properties, namely
>> dc:creator and foaf:maker.
>> Making issuedby a sub-property of both dc:creator and foaf:maker  
>> implies that
>> issuedby fillers are at the same time instances of both dc:Agent  
>> and foaf:Agent.
>> This might sound intuitive, but it needs a careful check of the  
>> FOAF and DC
>> definitions (as opposed to their authors' intentions) to see if  
>> such an instance
>> (a) is possible and (b) really looks like what we want it look. In  
>> other words,
>> an issuedby instance might get caught in the interaction between  
>> the two sets
>> of axioms and be forced to look like something nobody is happy with.
>> Besides, the intention is not that we *restrict* issuedby fillers  
>> so that they
>> satisfy both schemata, but rather that we *expand* them, so that they
>> satify *either*. Or a future schema we do not know about yet, and  
>> which
>> might be a perfectly good way to specify an agent, but totally  
>> incompatible
>> with both DC and FOAF.
>> Given the above, I feel that the way forward is to allow, as Andrea  
>> very
>> acutely suggested, the union of dc:Agent and foaf:Agent as the range
>> of issuedby. Phil, correctly IMHO, resisted the idea of introducing  
>> a new class.
>> I suggest the following way of saying the same thing without  
>> conjuring up a new
>> class:
>> dc:creator rdfs:subPropertyOf issuedby .
>> foaf:agent rdfs:subPropertyOf issuedby .
>> This has the following advantages:
>> (a) it logically implies that issuedby accepts either dc:Agent or  
>> foaf:Agent fllers
>> (b) it does not introduce a new class
>> (c) it can be easily extended by simply adding subPropertyOf  
>> statements,
>>     without having to redefine the range of issuedby (since it is  
>> implicit and
>>     not explicit in the first place)
>> (d) it gives generic RDF tools a rough idea of what issuedby is
>> In fact, it gives generic RDF and OWL tools as accurate an idea of  
>> what issuedby
>> is as is possible and relevant: one cannot write an OWL axiom that  
>> infers the
>> correct dc:creator or foaf:maker property from issued by, even if  
>> the filler gets
>> resolved and its class becomes known. But this is a problem of OWL  
>> and not
>> of POWDER: OWL does not allow property descriptions like it allows  
>> class
>> descriptions, so this is simply not relevant to OWL.
>> In other words: OWL tools should be happy with a semantics of:
>> (a) this might be expressing a dc:creator property
>> (b) this might be expressing a foaf:make property
>> (c) this might be expressing something else
>> Since this is what OWL allows, this must be all that OWL cares about.
>> I believe that in OWL2 one can eliminate (c), which will be a good  
>> thing.
>> We can write an informative section in anticipation of OWL2.
>> s
>
Received on Tuesday, 22 July 2008 12:42:20 GMT

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