Q:
Why the definition of such schema?
A: The Universal Profiling Schema (UPS) was created
in order to resolve the problem of the content negotiation and adaptation of
multimedia services in heterogeneous systems; i.e. where there is a wide diversity
of clients. In such situation, services and documents providers must be able
to deliver a well adapted document that respects the end-user preferences and
capabilities. To achieve that task properly, an efficient solution needs to
know some information about the set of elements that play a role in services
delivery. UPS is created to be a model that responds to such need. In UPS, elements
concerned by the content negotiation and adaptation are identified and so profiles
can be defined easily.
Q:
Is there any implementations behind UPS?
A: The need of the definition of universal profiling
framework for the content negotiation problem was encountered initially during
the implementation of an architecture (NAC)
that aims to deliver adapted services for heterogeneous devices: i.e. devices
like PDA, phones, laptops, etc. UPS was defined to respond to NAC needs but
also to be an extensible and flexible tool, indispensable for content authors,
application developers, universal services providers, etc. and for those who
aim to enable the universal access to their content.
Q:
Is the definition of UPS is finished?
A: Not yet. Other new elements and structures will
be defined.
Q:
Is it realy necessary to include the element 'document profile' in UPS?
A: Yes, if we aim to provide an advanced content
negotiation and adaptation strategy we must provide the document profile, which
is simply the description of the characteristics and the content of the document
and may also include, in some architectures, its semantic. People who work in
the context of the content adaptation feel better the importance of such descriptions.
In fact, to adapt a content, and to choose the appropriate method to apply according
to the delivery context, we need to know the nature of the content that we will
process. An example of some of the adaptation efforts, the one introduced in
http://www8.org/w8-papers/2b-customizing/user/user.html
where the adaptation focuses on synchronized multimedia presentations, note
that the need of the document profile (or 'content descriptions', see section
4.1 ) was well identified.
Q:
Why a new schema while other schemas exist such as WAG UAProf?
A: UPS is defined in the context of the content
negotiation. This means simply that any content negotiation solution, whatever
its own matching algorithm or strategy, can use UPS as a base that provide utile
information required in the matching and the content deliverance. UPS is not
dependent to any particular service or document kind such as WML. Indeed, services
can be in the form of WML, XHTML, HTML, or other. Furthermore, UPS don't disregard
the "document profile" concept that includes a description of the
document structure and semantic; this concept is very important if we aim to
ensure an advanced content negotiation solution. Finally, the UPS includes other
components such as the network description, the capabilities of servers in term
of adaptation and transformation methods etc.
Q:
hello, my name is Norberto Chatlani, from Spain, and i have started to study
xml, xsl, and finally found cc/pp. while i was doing this trip, tried to understand
cc/pp how works it. the information is in xml format. the webserver looks the
request and what kind of client do the request (User Agent Profile). According
to this profile, use the stylesheet apropiated. the question that i have is:
This operation can be done by a proxy or an intermediary element? for example,
the proxy do a xml (http) request to the server, and the conversion is made
in the proxy. I have heard it but i am not sure that it would be true. thanks
norberto chatlani (norberto chatlani)?
A: Applying a style sheet or another kind of adaptation method is called the
"content adaptation" and can be
applied by the original server or an intermediate proxy. The content
adaptation is applied when:
1- The original content can't be used directly by the client
and
2- There is no existed version (or 'variant' using the HTTP vocabulary!)
that meet the need of the client
and
3- The service or document provider has an adaptation method which can
transform the original content to
another content that respects the target context.
-NC-- for example, the proxy do a xml (http) request to the server, and the
-NC-- conversion is made in the proxy.
-NC-- I have heard it but i am not sure that it would be true.
Before choosing the adaptation method to apply or the selected version to deliver,
the content negotiation step must be achieved. To achieve this task, some information
are needed such as information about: the user agent profile, the requested
content, the server capabilities etc. The more suitable situation to use an
advanced content negotiation is to include the negotiation module at the server
side, and to provide other required information such as the document profiles
(document characteristics, document meta data, etc.). The use of the proxy based
architecture can be more suitable if we target some well known adaptation or
transcoding. This why in the literature we find proxies like image transcoding
proxies, HTML to WML proxies etc. Hope this will help.
Q:
Hi Tayeb, I took a look to your UPS and I have just a coment/question about
it. You named attributes (like DeviceName, PixelStretch, etc.) without taking
care of the "interCap" naming convention (http://www.w3.org/TR/CCPP-struct-vocab/#3.3.4)
Why did you act this way ? (to differentiate some meanings ?) Best regards,
Luc. (Luc Pezet)?
A: To clarify the ideas about the UPS schema, I'd
like to give some important notes: - The UPS schema was created mainly to resolve
the problem of the content negotiation over internet and heterogeneous networks.
- The UPS schema presents the idea of the creation of profiles for different
elements which are required during the content negotiation task such as the
client profile, the document profile (functionalities, metadata..), etc. Elements
and attributes that exists actually can change and be extended in the future.
- Each element in a profile following the UPS schema defines a constraint (atomic
or composite) about the described component. - Constraints are resolved during
the matching and the process of content negotiation by the content server. For
the server constraints resolution that concerns UPS attributes, the name style
such as the "interCap" one is not important. Simply to retrieve the constraint
semantic, the server ignores the style of attributes included in the profile
and that are preceded by the "neg" namespace.
Q:
I would like to use CC/PP to describe different kinds of profile which would
contain context information useful for those content adapation mechanism.
By taking a look at your work, I came up with a couple of questions:
1) Is your schemata has a xml or
a rdfs extension? 2) Does it make any difference since your schemata are using
RDF sintax and schema?
3) Would you mind to explain me how your client schemata defines a property
as NonSupportedResources and one of your instance shown below the Schema uses
a rdf:ParseType property? Is this rdf:ParseType a RDF attribute or element?
Where is this rdf:ParseTYpe defined? By reading the RDF Model And Syntax and
RDF Schema, I was not able to find this attribute. I am very interested to understand
this structure because I was trying to create such a similar structure and I
thought RDF would not give support for that. I thought I would have to create
each attribute as a separate list.
4) UAPROF has used the rdfs:comment property to store some profile resolution
rule as you might be aware. How do you solve this problem within your profiles?
5) I noticed you have created an API for profiles creation. Could you explain
the benefit of creating profiles using your API instead of creating them manually
and then parsing it on Jena?
6) Have you implemented your NAC architecture
I spent the last couple of days
reading your articles and trying to understand your proposal on UPS. I found
it excellent and very much interesting. Is it possible to use your UPS profiles
in my master thesis? If you give me authorization, I may have a couple of new
properties to add, is this possible too?
7) When I made my sixth question
asking you if you if you had implemented the NAC architecture what I was trying
to understand was
- if you have created an API that implements your Negotiation Module, Adaptation
Module, UCM and the component that contains the players and users context listeners.
Have you? Is it an open source code that anyone could have access? If this is
the case, would you mind to give the link?
8) Regard my third question, I read the RDF Primer specification and I think
I understood how to use the rdf:ParseType. This is a functionality that RDF
has to allow representing a structured information within a list format, is
this correct?
9) With UAPROF, the rdfs:comment of each property was used to store data type
and the resolution rule (override, append, lock). On your NAC architecture,
I didn´t understand if it had a CC/PP repository. In case it has, how
have you addressed the problem related to the profile resolution?
10) When you built the UPS Profiles, did you intend the Client Resource Profile
to be previous stored in a repository or sent by the client device along with
its client profile?
Best regards (Claudia Alvarez
Rolins)