Re: PROPOSED RESOLUTION of attribution (again!)

OK the status section of the DR doc now includes this:

Please note that this document includes a feature at risk related to the 
status of the HTTP Link header. Furthermore it refers to a feature at 
risk in the Formal Semantics document. The Working Group is particularly 
keen to receive feedback on these issues and the definition of 
wdrs:issuedby as a sub property of both foaf:maker and dcterms:creator 
(an alternative might be to make both of those sub properties of 
wdrs:issuedby, the definition of a class that is the union of 
dcterms:Agent and foaf:Agent etc).

Anyone would think we can't make up our minds or something...

P

Stasinos Konstantopoulos wrote:
> 
> 
> 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 14:04:15 UTC