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

Thanks for putting even more time into this.

If I understand you correctly it would be fair to allow this:

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

but we should explain that this means that "there should be a resource 
out there which is of the type ex:Wood that has the color brown, and 
that this is the value filler for our properties." Although this may be 
  semantically valid, such a construct is usually inappropriate for use 
in POWDER.

Giving the node an ID using rdf:about effectively creates a new 
vocabulary term that is duplicated every time the POWDER document is 
processed and although, again, this may be useful in some circumstances 
it's generally better to use a pre-defined term if possible.

Finally, since POWDER transports RDF/XML, it is not unreasonable to 
expect a POWDER Processor to be do at least minimal processing of RDF 
and not just always as XML.

Phil.

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