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

Re: Blank nodes in descriptor sets - a proposal to deal with this using Occam's Razor

From: Stasinos Konstantopoulos <konstant@iit.demokritos.gr>
Date: Wed, 16 Jul 2008 17:49:13 +0300
To: Ivan Herman <ivan@w3.org>, Phil Archer <parcher@icra.org>
Cc: Public POWDER <public-powderwg@w3.org>, Dan Brickley <danbri@danbri.org>
Message-ID: <20080716144913.GA25886@iit.demokritos.gr>

On Wed Jul 16 14:53:27 2008 Ivan Herman said:

> Phil Archer wrote:
>
>> My problem is the 'ref' attribute. A descriptor set is meant to to 
>> carry RDF/XML directly so adding in non-RDF attributes strikes me as 
>> something to avoid if we can. rdf:ID or rdf:about is what we really 
>> need isn't it?
>
> I am not sure what the Stasinos' intention is with @ref. Doesn't that  
> depend on the transformation into POWDER-S? You mean that it compiles to  
> what is below?

In the email you are referring to, I was describing a situation where
POWDER defines a new vocabulary item where one is missing, where what 
the POWDER author needed to express did not already have a name.

So Stasinos was, in fact, intending this to translate in an rdf:about,
concentrated on the POWDER-S and counting on the more XML-savvy POWDER
members to fix the POWDER/XML bits.

Now, if you see
http://lists.w3.org/Archives/Member/member-powderwg/2008Jul/0057.html
in the 0058(b) section, I am describing two alternative readings of the
original

  <ex:material>
    <ex:Wood><ex:colour>brown</ex:colour></ex:Wood>
  </ex:material>

construct, and I am asking the rest of the group to explain what the
intention is. Alternative (1) names the node and turns it into a new
vocabulary item. Alternative (2) retains a blank node to express that
there should be a resource out there which is like so and so, and is the
value filler for our properties, and we do no need to name. In our
carpentry example, (1) allows talking about wood in a way that the vocab
author missed and (2) allows talking about a particular piece of wood
a particular piece of resource is made of.

Incidentaly, I tend to agree with Ivan, in that I see how blanks can be
a hussle, but if it's necessary then so be it. POWDER authors should be
warned, but I don't think it's worth to cripple a formalism to keep
authors from requesting the existence of pieces of wood that look like
something drawn by Escher. So, IMHO, the real question is "is this
useful?" as opposed to, "how can this be abused?" In the case of POWDER
I found (2) hard to justify by a use case (as opposed to too dangerous
to let POWDER authors get their hands on), which is why I my suggestion
swinged (1)'s way.

But situation (1) seems to me something that should be in POWDER.
Vocabulary items might be missing, and it does not seem reasonable to
presuppose that all POWDER authors will also be in control of the
vocabulary they are using, or technically able to own a namespace and
publish a new RDF vocabulary. A POWDER processor/user policy might
decide to trust a POWDER doc with a custom vocabulary less, but outright
forbidding it sounds like an overkill.

The same argument applies to attribution elements. It seems to me that
expecting that all annotation entities have a published FOAF of DC
document describing them is too restrictive, when W3C itself
(apparently) hasn't got one.

As for the potential problems this might create, I do not see here a way
to keep authors from shooting themselves in the foot without losing too
much. We let POWDER authors define empty IRI sets and apply mutually
exclusive descriptors anyway, and accept this as a fact of life. Authors
can refrain from using features they do not fully understand, or use
front-end authoring tools, and, anyway, there are going to be POWDER
documents of varying quality and usefulness.

>> Let's cycle back to a discussion we had at the f2f on Monday.
>>
>> [..]
>>
>> So right now I'm thinking we should not only restrict descriptor sets 
>> to having child elements that have no child elements to avoid a lot of  
>> semantic hassle, but we could do the same for attribution and obviate  
>> the need to understand RDF at all to process POWDER at least at an  
>> operational level.
>>
>> What would we lose?
>>
>> Well, we'd lose the ability to put anything other than simple RDF in 
>> the descriptor set and that must surely mean a reduction in 
>> flexibility. It also makes some things a little more awkward. We were 
>> happily expecting all xx:Agent classes to be defined externally until 
>> Ivan said that the W3C hasn't got a FOAF file so can he put it in the 
>> POWDER file itself. So we made it possible... but, well, if we said no, 
>> sorry Ivan, it's about time W3C had an RDF description of itself 
>> somewhere, would that be a show stopper?

I think so. In W3C's case it's perfectly possible, it's just that it
hasn't be done yet. But why would POWDER want to exclude all potential
annotators who have something to say about a site, but can only provide
a name, a phone number, and an email? They might be less credible than
an organization that controls a URL, but why not let the user decide
that?

>> Let me summarise with a proposed resolution.
>>
>> PROPOSED RESOLUTION: That the descriptor set and attribution elements 
>> in a POWDER document may contain RDF properties that have either a 
>> literal value or that use the rdf:resource attribute to point to an 
>> instance of owl:Thing only. Arbitrary RDF may not be included ()in XML 
>> terms the child elements of descriptorset and attribution must not have 
>> any child elements).

Given the above, I think that this would be an overkill, especially for
attribution.

s
Received on Wednesday, 16 July 2008 14:50:06 GMT

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