W3C home > Mailing lists > Public > www-di@w3.org > June 2005

DPF Figure 1.

From: Keith Waters <kwaters@ftrd.us>
Date: Wed, 1 Jun 2005 16:53:57 -0400
To: www-di@w3.org
Message-Id: <4407F942-5913-45CE-97D8-4196114AFFEC@ftrd.us>
Hi Jeremy,

This message contains a response to comments on


section 4.1
Figure 1 confusing

I got really quite confused by figure 1 and the text above it.
I only really made sense of it when I had read further in the document.
In part this was that I hadn't work out what you meant by hierarchy
by this point.
In part this is that the label "DPF Component" seems to describe
the type of that rectangle, whereas the labels "Property [A-C1-6]"
seem to be being used to name the relationship between the labelled
rectangle and the rectangle above.
The lines are also working quite hard, and looking at the picture
again I think perhaps too hard. (The lines are representing
both the parent/child relationship and the sibling relationships)

I guess I'm really looking for substantive changes here, so
my suggested fix is in a different comment (mainly comment r2)

Figure 1. has been redesigned to take into account the "Property [A-C  
1-6]" issue. Figure 1. (attached) now illustrates leaf nodes as  
"Property [A1, A2]" and "Property [C1, C2]" to clarify their non- 

Importantly, while semantic representations are possible, the DPF  
considers this to be out-of-scope. The DPF focuses on describing a  
set of interfaces not RDF ontologies. As a result, the intent of  
Figure 1. is to clarify property hierarchies rather than property  
ontologies. The DPF is not a model to MetaData. Further, the DPF does  
not need a semantic representation to function and there is no means  
to describe such representations in DPF. Having said this, it is  
possible to capture such representations via the metaData interfaces.

-Keith Waters

(image/png attachment: dpf1.png)

Received on Wednesday, 1 June 2005 20:54:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:54:24 UTC