[Accessforall] Alternative way of handling conditions (was Re: I presume our meetings ...)
Gottfried Zimmermann (List)
zimmermann at accesstechnologiesgroup.com
Tue Apr 10 06:14:23 UTC 2012
i appreciate your input to this discussion. We want to learn from DC, and I
think we are more like DC than you assume.
1. The DC refinement does not apply to your reasoning about integrating
conditions into refinements.
- You say that we can make "refinement properties" by appending conditions
to properties. However, according to DC,
http://dublincore.org/documents/dc-elem-refine/, a refinement implies that a
statement using a refinement property can be generalized into a statement
using the property that is the ancestor of the refinement.
- Now, apply this to the Martha scenario,
s+in+A+User+Profile, to the following triple:
Martha subtitle-fontsize-1800-0600 xxlarge
(Sidenote: Actually, the subject of any statement in a user profile is the
person that the user profile is assigned to. The preference properties are
the predicates, and the values are the objects - typically literals.)
Since subtitle-fontsize-1800-0600 is a refinement (subproperty) of
subtitle-fontsize, this would imply:
Martha subtitle-fontsize xxlarge
But this is not true! We just lost our condition.
(The other way would be true, though: subtitle-fontsize is a refinement of
subtitle-fontsize-1800-0600. But that doesn't really help here either, I
2. The proposed syntax for conditions is trying to keep as much semantics as
possible. We are using first-class data as part of the conditions (e.g.
time or location). If we cumulate everything into a string as part of the
property name, we lose the relations that are the foundations of the
condition. Also, think about more complex conditions, that are made up of
AND/OR conjunctions. Transforming a complex condition into a property name
would not be a good idea, I think.
3. I would like to involve a semantic Web expert on the question of
conditional statements. I see that this issue has been raised many times,
but I don't see a good solution to it, currently. Maybe I am overlooking
something here? Do you have a proposed syntax for conditional statements in
the semantic Web?
Anyway, with the proposed "condition" syntax in a user profile, we would
like to be able to transform any conditional item of a user profile into a
set of statements that would express a condition in a "pure" semantic web
way. I was thinking about dividing the user profile up into several
sections, each of which is only valid if a certain condition comes true.
This can become arbitrarily complex, but it would be a formal method for
transforming our "conditions syntax" into something more formal and
Any other ideas?
Von: accessforall-bounces at fluidproject.org
[mailto:accessforall-bounces at fluidproject.org] Im Auftrag von Liddy Nevile
Gesendet: Freitag, 6. April 2012 00:20
An: Andy Heath
Cc: Accessforall at fluidproject. org
Betreff: Re: [Accessforall] Alternative way of handling conditions (was Re:
I presume our meetings ...)
These responses confuse me????
DC is not a language, or a format, it represents a way of making and using
metadata that has evolved over the last 15 years of work on metadata. It
depends on an abstract model that has been carefully developed (it has some
historic bugs, in fact). What we are doing cannot be just 'expressed' in DC
or some such thing - it does not follow the principles. It seems to me we
are building something like the LOM that cannot be expressed as DC metadata
other than with great loss .
Also, there is little too much 'flexibility' in what we are doing. If we
were developing principles that were consistent then, like with DC and Sem
Web metadata, more could be derived and added. As I see it, what we are
doing is arbitrary and so will be dependent on our (your) database.
I believe one of the clever things about AccessForAll is its potential to
support cumulative, just-in-time metadata and therefore accessibility. I
cannot see how we are supporting that or the other benefit of using other
Am I a grinch? I am really really excited about the possibilities, in fact!
On 06/04/2012, at 3:56 AM, Andy Heath wrote:
> <SNIPPED argument for refinement within the registry>
>> Well the approach we are using allows us to go both ways in the User
>> Preference Profiles
>> again - the registry is like the dictionary of words that we use to
>> create terms. The terms can still be expressed in DC format if that
>> is the desired format in the end.
> I agree completely with this - the approach is *more* flexible and
> still allows DC (and other Metadata approaches) to be used with it.
> Putting these semantic mechanisms within the registry would not do
> Andy Heath
Accessforall mailing list
Accessforall at fluidproject.org
More information about the Accessforall