This document:Public document·Annotated document·View comments·Search comments·Add a new comment·Send replies to comments·Disposition of Comments·
Nearby:Protocol for Web Description Resources (POWDER) Working Group
Other specs in this tool
Quick access to LC-1884
There are 11 comments (sorted by their types, and the section they are about).
Sec 1 says "for which we use the QName wdr.". Shouldn't that be "for
which we use the QName prefix wdr."?
The issue of whether Descriptors should be linked from DR or from
resource Set met some confusion (probably due to my poor and hurried
explanation). Suggestion is that we should create two test cases to
Much concern about DRs having or not having a URI of their own. My
take from the conversation was that we should always have some sort of
identifier unless there is only one DR in the RDF instance. So we
probably need to include rdf:about="...#DR1" for each wdr:DR.
Sec 2 says: "This is a break from the RDF model and means that a
generic RDF/OWL inference engine MUST NOT be used directly to make
inferences based on DRs." This is scary, and IMO requires major
justification. What exactly is the break from the RDF model and what is
the rationale for it? It would not seem to me to make sense to use
RDF/OWL notation without their semantics. Is that what you mean?
I assume that two packages could contain different DRs with
wsd:hasScope entries that both apply to the same resource, in which case
both DRs do apply, i.e., the union of the assertions in the DRs apply to
the resource. Is that correct?
Sec 3.4 says:
Two requirements flow from this:
1. Packages MUST have an identifier (in RDF terms they must be a
2. DRs that are to be processed as part of a Package SHOULD include
the Dublin Core term isPartOf with the Package URI as its object.
I don't understand why these requirements follow, for two reasons:
- First, why can't each cached DR have an associated list of
wdr:hasScope to exclude? Such an exclude list for a DR would consist of
all of the wdr:hasScope's of other DRs that preceded it in the package.
- Second, this seems like an implementation issue. The information
that DR1 and DR2 are part of package p1 is already evident in the RDF
graph (via the rdf:first and rdf:rest predicates) even without using
dcterms:isPartOf, isn't it? It seems like the processor's problem if
it is not smart enough to make use of the information that was already
provided. Can you shed more light on this?
Dan C pointed to a line from the HTML 4 spec: "Authors may wish to
define additional link types not described in this specification. If
they do so, they should use a profile to cite the conventions used to
define the link types. Please see the profile attribute of the HEAD
element for more details." --
As already stated I'm very glad to see RDFa being
used to demo the linking capabilities in the POWDER-DR WD.
Ben  and Mark  mentioned two issues you might wish
consider taking into account when updating the WD:
1. We decided to NOT allow link/meta in the <body> (cf. )
As @href is indeed allowed on any element in the
XHTML+RDFa DTD , the Example 4-1-3 can easily be rewritten:
change to, e.g.,
2. The second comment is not actually an RDFa issue, but however ...
In '1 Introduction (Informative)' you state
'The POWDER vocabulary namespace is http://www.w3.org/2007/05/powder#
for which we use the QName wdr.'
Which is not 100% correct; the QName as defined in  consists of
an (optional) PREFIX , then ':', and then the LOCALPART. Am I
correctly that what you want to express is something like:
In the POWDER spec, 'wdr' is used as the namespace prefix for the
POWDER vocabulary URI http://www.w3.org/2007/05/powder# ?
BTW, further information on RDFa can be found in the RDFa Primer 
and in the RDFa Syntax  ...
Anyway, keep up the good work!
Michael Hausenblas, MSc.
Institute of Information Systems & Information Management
JOANNEUM RESEARCH Forschungsgesellschaft mbH
Steyrergasse 17, A-8010 Graz, AUSTRIA
phone: +43-316-876-1193 (fax:-1191)
Thank you for including the images of the RDF graphs used in the
examples! Images like this
make it much easier to understand the RDF being discussed, since RDF/XML
is nearly impossible for me to read. How about including N3 or Turtle?
In fact, as far as I'm concerned, you can drop RDF/XML entirely, as to
my mind it doesn't add any clarity, but I certainly understand that
others may feel differently.
Sec 3.2 "Forcing Processing Order Using dcterms:isPartOf" talks about
caching and says:
The set of all resources described by the DRs in the Package can only be
determined fully by taking the union of the Resource Sets of each of the
DRs themselves. However, it is useful for the Package to include a
processing hint about the range of resources described.
Must this hint specify a superset of the resources described by the DRs
in the Package? It would seem like a sensible constraint, but I don't
see it stated.
Add a comment.