DPF comments: relation to RDF properties; cardinality; property declarations

cc:'d to the Semantic Web Coordination Group (a W3C-Member only list).
(CG members please note the www-multimodal list is public distribution).


Hi. I've just been taking an (admittedly quick) look at DPF.

http://www.w3.org/TR/2004/WD-DPF-20041122/

Very interesting work, in particular I really like the idea of an 
event system for such things.

Some initial questions. My apologies if I've missed obvious answers to
these.

1) relation to RDF properties

The draft notes the link to CC/PP, which uses RDF, as well as a very broad 
scope for the kinds of properties that might be exposed via DPF.

Examples include device configuration, people descriptions /
preferences, locations, environmental conditions such as temperature, 
battery levels, networking infrastructure (online/offline etc). 

Since so many kinds of property could be useful within DPF, I believe it
would be good to understand a few things about the potential
relationship(s) between DPF's property model and RDF's. Both systems
identify properties via namespace URIs and can be applied across a 
great number of descriptive domains.

Q: Can any/all/some RDF properties be used as DPF properties?

  eg. wgs84:lat="30.12" for a location, or srw:masters="fr" to express 
  competence with French. These are actual RDF vocabs btw, see
  http://f14web.com.ar/inkel/rdf/schemas/lang/index.en.html
  http://www.w3.org/2003/01/geo/

Q: Are there any RDF properties which cannot be used as DPF properties?
  (http://www.w3.org/TR/2004/WD-DPF-20041122/#s3 suggests that 
  this might be the case, since RDF properties can lack datatype 
  restrictions, and don't use the DOM approach adopted in DPF, but
  instead allow XML schema-style datatyping via a datatype URI).

Q: Can any/all/some DPF properties be used as RDF properties?

 If so, please consider adding an appendix specifying the exact
 RDF triples that correspond to a DPF property, or larger property tree. 
 Detail will likely be needed regarding datatype URIs for literal-valued 
 properties, and perhaps some consideration for reflecting resource URIs 
 into the RDF graph (eg. via well known DPF properties whose values are
 URIs? <- thinking out loud). 

Aside: I suspect that defining a complete serialization format, allowing all
properties to be extracted at once using some XML representation, might make 
the business of mapping into RDF easier, as well as benefit applications 
that want access to device properties over an expensive or bandwidth 
constrained environment. Property-at-a-time access is of course useful,
but might be too 'chatty' in some environments. 

Q: Are there any DFP properties which cannot be used as RDF properties?
 (this affects, for example, our ability to use the upcoming
 RDF Data Access WG's SPARQL query language for matching against 
 DPF-modelled data alongside CC/PP, UAProf and other RDF data, eg. 
 describing locations, natural language prefs etc.).


2) Cardinality and property 

re	http://www.w3.org/TR/2004/WD-DPF-20041122/#s4
	4.2.7 getDPFPropertyList

Can the exact same property (eg. 'net:hostname') be applied to a single 
DPF-described entity directly? The spec gives the impression that this 
isn't allowed (presumably simplifying the edit/update APIs), and that 
nested structures, or a NodeList, have to be used rather than simple
property repetition. Or am I misreading? (quite possible...)

FWIW RDF allows property repetition, but also allows for RDFS/OWL vocabulary 
declarations to declare certain properties to be 'Functional' or 
'InverseFunctional' (amongst other things; see OWL specs for detail).

3) Property Declarations

Taking your use cases as an example, ie.
http://www.w3.org/TR/2004/WD-DPF-20041122/#A2

...how do DPF adopters publish and publicise their DPF property
namespaces? Do you have an mechanism/plans/roadmap to allow properties
to be documented in some form other than human-oriented prose?

eg. from B1:
	DPF.location.format="postal code";

Who defines the property 'location'? In practice, what do they do to 
tell users of the property that it's correct value is an entity that 
has properties such as 'format'. I assume some namespace mechanism
disambiguates 'location' and 'format' by associating them with URIs, 
but am unclear how this alone is enough to support the loosly-coupled,
multi-party heterogenous extensibility that DPF seems to aim for.

If I'm a DPF adopter and want to publicise a property that applies to 
locations, and I've somehow found the URI for this 'location'
property, what do I do? 
Pretend my new property is danbri:averageRainfall, and I've a 
domain name etc etc I can assign to it. What can I do, in a
machine-readable (and hence more I18N-friendly than prose) way to say
that my danbri:averageRainfall property is intended to apply to the kind of 
thing that b1:location takes as its value? How do we help DPF adopters,
many of whom won't read English, from mis-using the 'location' property,
eg. by using it with textual strings values. Can XML schema languages 
be used somehow? RDF/RDFS/OWL? Is new work planned in this area?

This is related to my questions above of course, since RDF/RDFS/OWL
might serve as an already-existing property declaration mechanism, assuming 
the datamodels match up. But it could well be the case that RDF doesn't
suit your WG's needs, or even that figuring out whether it is usable could be 
too expensive an undertaking. I intend the questions above as small
steps towards figuring out how DPF and RDF might inter-relate, rather
than as evangelism/advocacy to persuade you all to "go over to RDF"!

So I should stress that while I'm clearly coming at this problem space 
from the RDF tradition, I don't yet know enough about DPF. These are my 
initial reactions on reading the WD, basically that it would be good to
be able to consume DPF data in RDF environments, since RDF is also based
around a hetergenous model for properties. And also that there are many 
RDF-defined properties already in existence, some of which might address 
DPF usage scenarios. I'd like to be able to advice RDF and DPF adopters
on whether a single property URI/namespace can be used, and if not, have 
some explanation to offer them to account for apparent duplication.

cheers,

Dan

Received on Wednesday, 22 December 2004 21:22:55 UTC