W3C

List of comments on “Protocol for Web Description Resources (POWDER): Formal Semantics” (dated 8 September 2008)

Quick access to

There are 28 comments (sorted by their types, and the section they are about).

1-20 21-28

question comments

Comment LC-2141: issuedBy rfc2118
Commenter: Michael Schneider <schneid@fzi.de> (archived message)
Context: 2.2 POWDER-S Attribution Semantics
assigned to Stasinos Konstantopoulos
Resolution status:

Why the "SHOULD" here? From the assumptions stated above (wdrs:issuedBy is a subPropertyOf both dcterms:
creator and foaf:maker) it follows logically that this URI denotes an instance of both classes.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

typo comments

Comment LC-2143: irisit has/have
Commenter: Michael Schneider <schneid@fzi.de> (archived message)
Context: The ex:finish element specifies that the ex:finish relation...
assigned to Stasinos Konstantopoulos
Resolution status:

typo: "all resources in iriset [has/have] the value..."
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2146: <code>
Commenter: Michael Schneider <schneid@fzi.de> (archived message)
Context: Example 3-5: A POWDER Document Containing Multiple DRs [XML...
assigned to Stasinos Konstantopoulos
Resolution status:

The <code> elements in both DR's are probably a bug.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2147: that that
Commenter: Michael Schneider <schneid@fzi.de> (archived message)
Context: 3.2.1 Descriptor Sets expressed as RDF Properties and Values
assigned to Stasinos Konstantopoulos
Resolution status:

Typo? "that that"
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2151: this/that
Commenter: Michael Schneider <schneid@fzi.de> (archived message)
Context: Example 3-11: A Descriptor Set Containing an Identified Nod...
assigned to Stasinos Konstantopoulos
Resolution status:

Typo? "this that"
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2152: refer
Commenter: Michael Schneider <schneid@fzi.de> (archived message)
Context: 3.2.3 Referring to External Descriptor Sets
assigned to Phil Archer
Resolution status:

Typo? Is "refer" meant?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2154: owl:Property
Commenter: Michael Schneider <schneid@fzi.de> (archived message)
Context: 4.3 POWDER-S IRI Set Semantics
assigned to Stasinos Konstantopoulos
Resolution status:

There is no owl:Property, only rdf:Property.
Further, if you apply RDFS/OWL-Full semantics, then every instance of owl:DatatypeProperty is also an instance of
rdf:Property, so the second axiom would be redundant.
LC-2116
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

undefined comments

Comment LC-2138: custom ontology properties
Commenter: Michael Schneider <schneid@fzi.de> (archived message)
Context: 2.2 POWDER-S Attribution Semantics
assigned to Stasinos Konstantopoulos
Resolution status:

Although technically possible in OWL Full, I suggest to /not/ build custom ontology properties. AFAIK, the set of
ontology properties in OWL is intended to be fixed; at least I don't see any encouragement in the OWL documents to
create custom ontology properties. I suggest to make 'attribution' into an owl:AnnotationProperty, instead. The creation
of custom annotation properties is ok. It is also ok to add annotation properties to instances of the class owl:Ontology.
For example, it is quite common to add an rdfs:comment to an ontology.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2126
Commenter: Chaals <chaals@opera.com> (archived message)
Context: in
Not assigned
Resolution status:

1. We not think that POWDER is implementable if the "arbitrary RDF in
POWDER" features, those marked at risk in the Formal Semantics Document,
remain in the specification.

They are a serious barrier to making it worthwhile continuing our work, as
they require a RDF parser in any POWDER-capable tool, rather than allowing
simple POWDER authoring tools and making it feasible to have POWDER
implementations running on devices of all kinds. Given that an important
use case is for gaming machines, and other entertainment devices with
internet access, and that these devices generally have much lower
processing power than desktop computers (where it is feasible to run RDF
processors), this would make POWDER somewhat pointless.

Removing the generalityof the format and maintaining it as a simple,
well-defined XML format will make a significant difference to its
implementability, and relevance to the Web.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2116: PFPS
Commenter: Peter F. Patel-Schneider <pfps@research.bell-labs.com> (archived message)
Context: in
Not assigned
Resolution status:

Comments on POWDER semantics last call document
http://www.w3.org/TR/2008/WD-powder-formal-20080815/

I take POWDER to be a way of associating (arbitrary) attributed
information with (groups of) web-accessible resources. What does this
need over base RDF (or OWL)?
1/ It needs some way of mentioning and grouping web-accessible
resources.
2/ It needs some theory of attribution, i.e., what kinds of entities can
provide information and what are their characteristics?
3/ It may need some theory of the kinds of information that can be
placed on these resources.
4/ It needs some way of accessing the information, at least accessible
from the resources themselves, but, in addition, a way of accessing the
information directly from servers for the resources without having to
access the resources would be useful.

I don't see any of this necessarily "in tension" with the core semantics
of RDF and OWL. The last is simply outside the scope of RDF and OWL, as
it involves issues related to the workings of the web, not representing
information on the web. The second and third obviously are the kind of
thing that RDF and OWL are concerned with (although, of course, POWDER
might need more expressive power than is available in RDF or even OWL).

The mentioning and grouping of web-accessible resources is where the
most potential problems arise. Perhaps surprisingly, RDF and OWL do not
make much of a connection between certain kinds of URI references (their
names) and web resources. To RDF (and thus to OWL) the name (URI)
http://example.com/ is just the name of some resource, that may or may
not have any connection to whatever document can be obtained by
accessing that URI using web conventions. Users of RDF are thus in some
sense free to use the name http://example.com/ for any purpose
whatsoever. POWDER authors may have to take care not to combine POWDER
documents with RDF documents that do not use RDF names in the way
intended by the POWDER specification.

Further, RDF and OWL do not have any mechanism for grouping names by
their form. To RDF (and OWL), there is no closer connection between
http://example.com/p1 and http://example.com/p2 than there is
between http://example.com/p1 and mailto:pfps@lucent.com. POWDER
definitely has to go beyond the RDF and OWL world view to make these
connections.

The transformational approach used in POWDER, going from POWDER to
POWDER-BASE to POWDER-S, is also not necessarily "in tension" with the
core semantics of RDF and OWL, even if some tokens are given special or
exceptional treatment and even if missing information is filled in with
default values. In particular, the treatment in Example 3-8 is
*precisely* in accord with the RDF and OWL view.

The major problem in the document is a use-mention conflation. The
resource referred to by http://example.com/ (which might perhaps be the
document available at http://example.com/) is (almost certainly) very
different from the URI http://example.com/ (which is definitely *not*
the document available at http://example.com/). The first is referred
to in RDF by using the URI in a triple as in <http://example.com/>
rdf:type wdrs:WebDocument the second is referred to in RDF by using a
literal as the object (only) of a triple as in < http://example.com/>
wdrs:address "http://example.com/"^^xsd:anyURI

So what is the problem in the POWDER document? Well the first way of
referring to sets of web-accessible documents, in Section 4.3, uses
wdrs:matchesregex, which is defined as an owl:DatatypeProperty, with
domain rdfs:Resource. However, <x,y> is in the extension of
wdrs:matchesregex only if x is a URI (essentially a string) that matches
a regular expression. This means that POWDER is identifying
web-accessible documents with literal URIs a use-mention conflation.

It would be much better to have a POWDER class of web-accessible
resources, each of which has (at least) one URI (that can be used to
access the resource), as in

Declaration(Class(wdrs:webAccessibleResource))
Declaration(DataProperty(wdrs:hasIRI))
Range(wdrs:accessibleVia xsd:anyURI)
SubClassOf(wdrs:webAccessibleResource
MinCardinality(1 wdrs:accessibleVia))

The "intended" meaning of wdrs:hasIRI is then

<x,y> is in the property extension of wdrs:hasIRI IFF
x is a resource that can (currently) be accessed via the IRI y

This is similar to the treatment in Section 4.6, but it avoids
problems there.

Then the POWDER mapping would end up with subclasses of
wdrs:webAccessibleResource whose wdrs:accessibleVia values would match
the regular expressions, using a "special" property, as in:

Declaration(DataProperty(wdrs:hasAURIThatMatches))
Range(wdrs:hasAURIThatMatches xsd:string)
IntersectionOf(wdrs:webAccessibleResource
HasValue(wdrs:hasAURIThatMatches <regexp>))

The "intended" meaning of wdrs:hasAURIThatMatches would be

<x,y> is in the property extension of wdrs:hasAURIThatMatches IFF
x has a value for wdrs:hasIRI that matches the regex y

This could then be done better using the OWL 2 data range facilities as

IntersectionOf(wdrs:webAccessibleResource
SomeValueFrom(wdrs:accessibleVia
DatatypeRestriction(xsd:anyURI pattern <regexp>)))


Specific comments:

There appears to be some confusion in the document as to names of
built-in properties, particularly wdrs:matchesregex[p]

I would not say "semantics" so much in the document. The document is
mostly specifing a transformation. It is true that this then defines
the meaning of POWDER documents. However, saying "transform" does not
give the impression that the transform *is* the semantics.

Using a verbose syntax for OWL makes it hard to grasp the meaning of the
transform. I think that it would be better to use TURTLE (and even
better to use the OWL 2 functional syntax or even an informal syntax
like the Manchester syntax).

Note that the namespace associated with the ox prefix is still under
discussion in the OWL WG.

I would suggest using TURTLE as an example of another serialization of
RDF graphs instead of N3.

There is no notion of "null" subject in OWL. Instead the document
appears to be referring to rdf:about="", which may or may not turn into
a node with the URI of the current document. (Consider what happens if
there is an xml:base element in scope.) In any case, Example 2-1
certainly does not show the attribution element being transformed into
an owl:OntologyProperty. This section of the document needs to be fixed.

There is no formal notion of an RDF statement being about anything. RDF
statements have subjects, predicates, and objects.

I am not sure what force the "SHOULD" in the issuedby section has. RDF
is not prescriptive, so using a node as the object of a statement with
issuedby as predicate *enforces* that the object is in the range of the
property.

The use of triple syntax requires some sort of pointer to an appropriate
definition.

Why not use XML Schema datatypes more in the transformation to RDF?

There may be a use-mention problem for certifiedby and supportedby. If
these properties are supposed to have URIs as ranges, then rdf:resource
is not the correct kind of thing to use.

I think that it would be a good idea to provide domains and ranges for
the POWDER properties, e.g., something like wdrs:IRISet for
wdrs:matchesregex. I further think that there should be some sort of
true semantics document that talks about the extensions to RDF that are
used in POWDER. This document would look something like the RDF
Semantics document or the OWL Semantics and Abstract Syntax document (or
its replacement in OWL 2).

There is no built-in OWL resource with name owl:Property. Triples using
it should probably be removed.

Note that the value space of xsd:anyURI consists of strings, and the
lexical mapping is the identity mapping, so the use of I for anyURI
lexical values is unnecessary. Note also that using literals as
subjects of OWL properties is only possible in OWL Full.



Peter F. Patel-Schneider
Bell Labs Research
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2119
Commenter: Phil Archer <parcher@fosi.org> on behalf of Ivan Herman (archived message)
Context: in
I've extracted this from a mail to me from Ivan.

He wants to use POWDER to ascribe CC licenses to the SW logos. The
examples he's created after reading the docs have been very helpful in
raising issues over several months. The latest one is this:

- The intention I
had, when using the <seealso> was that for each resource in the resource
set, the following triple would also appear:

<.../logo.png> rdfs:seeAlso <http://www.w3.org/2007/10/sw-logos.html>

but your translation (and the specification) uses the seealso to
annotate the _Class_ and not the individuals. Ie, the triple above will
not appear.

I realize that there may simply be no way around that. To be more exact,
there is, namely by defining the same restriction structure for
rdfs:seeAlso as for all other properties, which is perfectly o.k. for
OWL Full, but will drive you out of OWL DL. But if you know that, it is
worth documenting it somewhere so that well prepared users would be warned.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2149: blank nodes
Commenter: Michael Schneider <schneid@fzi.de> (archived message)
Context: Example 3-10: A Descriptor Set Containing a Blank Node POWD...
assigned to Stasinos Konstantopoulos
Resolution status:

I don't follow this argumentation. I don't see that the bNode leads to any problems when the descriptor set is defined
independent on any DR.
Maybe there is a misunderstanding in what the above example means. The existential variable isn't about resources
from a DR, but about the values of a descriptor for such resources. The construct above tells the following: If the
above descriptorset is defined for some DR, and r is a resource in that DR (i.e. if r is in the IRI-set defined by that DR),
then there /exists/ some x, being an instance of class Wood, where x has a shiny finish and is made of cedar, and the
following relationship holds: 'r ex:material x'. the existential variable x appears on the /right/ hand side of the
relationship!
If this was a misunderstanding, then I suggest to simply remove the whole paragraph.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2150: why a class
Commenter: Michael Schneider <schneid@fzi.de> (archived message)
Context: Example 3-11: A Descriptor Set Containing an Identified Nod...
assigned to Stasinos Konstantopoulos
Resolution status:

Why a class? I think that this is a bug. PolishedCedar should probably rather be an /instance/ of class Wood. Just
compare this with Example 3-10 and my comment to paragraph following Ex 3-10. The only difference between
Ex-3-10 and Ex-3-11 is that the latter uses an URI where the former uses a bNode. In both cases, an instance of class
ex:Wood is created.
So the correct mapping should be:
1 <owl:Class rdf:nodeID="descriptorset_1">
2 <owl:intersectionOf rdf:parseType="Collection">
3 <owl:Restriction>
4 <owl:onProperty rdf:resource="http://example.org/vocab#material"/>
5 <owl:hasValue>
6 <ex:Wood rdf:about="http://my.example.org/myVocab#PolishedCedar">
7 <ex:finish rdf:resource="http://example.org/vocab#shiny"/>
8 <ex:madeof>cedar</ex:madeof>
9 </ex:Wood>
10 </owl:hasValue>
11 </owl:Restriction>
12 </owl:intersectionOf>
13 </owl:Class>
LC-2126
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-2112: Clarify arbitrary RDF
Commenter: <parcher@fosi.org> on behalf of Rotan Hanrahan (archived message)
Context: in
Not assigned
Resolution status:

(Otherwise, we find POWDER intriguing, though we wonder what is meant by "use of arbitrary RDF in POWDER documents" in the recent request for feedback.)
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2135: OWL/XML URI
Commenter: Michael Schneider <schneid@fzi.de> (archived message)
Context: 1.1 Namespaces, Terminology and Conventions Used in This Document.
assigned to Stasinos Konstantopoulos
Resolution status:

The OWL/XML URI is at risk: There is an ongoing discussion in the OWL WG whether there should be a URI for the
XML syntax which is distinct from the OWL namespace. See <http://www.w3.org/2007/OWL/tracker/issues/109>
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2136: example.org
Commenter: Michael Schneider <schneid@fzi.de> (archived message)
Context: 1.1 Namespaces, Terminology and Conventions Used in This Document.
assigned to Phil Archer
Resolution status:

AFAIK, the URI <http://example.org> is reserved for such examples. And I have seen it being used elsewhere in this
document. So I suggest to simply state this URI here instead of the given sentence.
pa6
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2137: rfc2118 location
Commenter: Michael Schneider <schneid@fzi.de> (archived message)
Context: 1.1 Namespaces, Terminology and Conventions Used in This Document.
assigned to Phil Archer
Resolution status:

The introduction on POWDER-S above also uses the key word "MAY NOT".
Perhaps, the paragraph here should be lifted more to the top of the document, since some of those keywords are
already used earlier.
keywords
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2139: RDF/XML statements
Commenter: Michael Schneider <schneid@fzi.de> (archived message)
Context: 2.2 POWDER-S Attribution Semantics
assigned to Stasinos Konstantopoulos
Resolution status:

Even though RDF/XML is the preferred RDF serialization used to represent RDF data in this document, it is probably
not a good idea to talk about "RDF/XML statements" when referring to child elements of 'attribution'. I cannot see any
RDF/XML-specific aspects here. These statements are probably intended to show up in every RDF serialization, such
as Turtle. So I suggest to rather talk about "RDF statements".
LC-2116
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2140: confusing paragraph
Commenter: Michael Schneider <schneid@fzi.de> (archived message)
Context: 2.2 POWDER-S Attribution Semantics (p starting "As a shortcut...")
I found this sentence/paragraph hard to understand. A bit more elaboration or splitting it up into several sentences
would be useful.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2142: printer friendly titles
Commenter: Michael Schneider <schneid@fzi.de> (archived message)
Context: 2.2 POWDER-S Attribution Semantics
assigned to Phil Archer
Resolution status:

Perhaps keep a little care that printouts in A4 or Letter format don't get truncated. Shorter titles would already do much
of the job.
eg2-2
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

1-20 21-28

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:44:51 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org