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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 22 Dec 2004, Dan Brickley wrote:

> 
> 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/

I see no reason why these particular properties might not used
within the DPF. The DPF is just a framework, so you would still need
to define the actual interfaces and their semantics, for instance,
any events that may be involved. This only answers your question for
any/some RDF properties. I am unsure about "all" (I would need some
kind of formal proof).

DPF uses the IDL "any" type for generic property values, but this
would need to be restricted for specific properties, e.g. to a set
of language identifiers, or to a structured data type for location.
In principle, specific properties may provide additional methods for
mapping data types, e.g. for converting units of measure.

> 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).

This is worth discussing further. We envisage there being formal
definitions for specific properties based upon extending the IDL
interfaces defined in the DPF spec. In principle, you could have a
subset of properties that include a reference to a datatype URI as
you envisage.

> 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).

We would need help with that. RDF could certainly be used to name
specific DPF properties and to describe parent/child relationships
between DPF properties. I guess one could define a general treatment
of IDL in RDF, but am unsure of the utility of that. Could you
expand on what you are hoping for?

> 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.

The DPF deliberately doesn't define how properties are accessed
remotely, leaving this to lower layers. The exact mechanisms will
depend on the specific properties and the overall environment.
We expect to deal with these issues in separate specifications as
part of a broader vision for device coordination.

An XML serialization could be used to name what properties a given
device supports, but probably wouldn't be a complete description of
those properties. An open issue is what criteria should apply to
deciding which properties should be exposed to servers for server
side content selection/adaptation, and which are purely local to the 
device. This is trickier than it sounds.

> 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.).

I don't think I know enough to really answer that question. In 
principle, RDF is sufficiently powerful to describe any IDL 
interface definition, so in that sense, general RDF query mechanisms
should be capable in theory of dealing with any IDL definition.

On a more humdrum level, DPF defines a hierarchy of properties,
where each property has a data type for its value, and a set of
associated attributes, methods and events. There may also be
integrity constraints and access control mechanisms. I have no
doubt that RDF could be used to model some of these.

> 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...)

It would depend on the definition of the specific property. Some DPF
properties might be defined as arrays. We borrowed heavily from the
existing DOM in defining the DPF, including the definition for
NodeList. We wanted to enable the use of DPF from ECMAScript and
XPath.

> 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?

We currently envisage specifications that describe properties in a
mixture of prose and IDL (like the DPF specification). Such 
specifications would be defined by different organizations e.g. W3C,
OMA and specific vendors for proprietary properties.
 
> 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.

The Device Independence working group is looking at properties that
are particularly relevant to server-side content selection and
adaptation - see "Core Presentation Characteristics: Requirements
and Use Cases", http://www.w3.org/TR/cpc-req/

The Multimodal Interaction working group has looked at a broader 
range of properties that are valuable for dynamic adaption of
application behavior by the client (i.e. device).

The Open Mobile Alliance specification for UAProf defines a
hierarchy of static properties describing characteristics of
mobile devices.

In general, we would expect the owner of the specification for a
property to place constraints on what child properties it may have.
These would become more specific as you move from the root to the
leaves. Property hierarchies have been widely used for configuring
computer systems, e.g. on Gnome and on Microsoft Windows to name but
a few.

> 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 where access control and integrity constraints play a part.
Some properties will be readonly and therefore "safe". For others,
it will be important for the implementation to apply the integrity
constraints e.g. checking that the value being assigned is 
acceptable. Mobile devices are expected to be reliable and shouldn't
crash due to bugs in web applications.

DPF does allow you to ask what child properties are present, and
in principle, the IDL definitions could be exposed as part of an
reflection mechanism. We haven't gone that far, as it is unclear
that that is needed for the kinds of applications we have in mind.
You might want a richer environment for authoring tools.

> 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"!

The main focus for DPF is on mobile devices, where resource 
constraints remain an issue and are like to do so for some time
to come given the limitations of battery technology. Any new
features have to compete with others for the available resources.
Can RDF/RDFS/OWL be packaged into a small footprint that offers
a big return for mobile environments?

> 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.

I anticipate a lot of upcoming work on defining properties that
describe user preferences, device capabilities, configurations
and environmental conditions. This will present plenty of 
opportunities for collaboration.

Thanks for your questions and comments.

- -- 
 Dave Raggett <dsr@w3.org>  W3C lead for voice and multimodal.
 http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFByrKNb3AdEmxAsUsRAnNOAKCxfU5KGJ4WILfsdvDXOmdM9lGaRACfQwni
ppGHeALGovQDdD5NhcO7rx4=
=jn4c
-----END PGP SIGNATURE-----

Received on Thursday, 23 December 2004 11:55:40 UTC