Re: PROPOSED RESOLUTION of attribution (again!)

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 10:56:44 UTC