Hi Emmanuel and all,
> > _at_@@ I'm sorry to come back to this again, but I still do not understand
> > why you are making a difference between selecting classes and instances.
> > We discussed this by email a few days ago, and I still don't get it.
> > When you say fresnel:lensDomain foaf:Person, you implicitely mean "the
> > domain of this lens is all instances of class foaf:Person in the model".
> >
> > Yes, I think the important word in the last sentence is *implicitly*.
> > Knowing it implicitly means that we require the RDF schema to be known
> > to figure out if a node is an instance or a class.
>
> I see your point. But in my mind, basic selector expressions are always
> to be interpreted as class identifiers, even if you don't have a schema
> that tells you that the URI actually is that of a class. So you don't
> actually need an RDF schema to confirm that the lensDomain value should
> be interpreted as a Class (that is, all instances of the class
> represented by the value's URI), simply because this is the defaut and
> only way of interpreting a basic selector.
>
> Now, I agree with you that there might be cases where you want to style
> individual instances, and the only way to do this is to specify this
> instance resource's URI as the lensDomain. Considering the
> interpretation I make of lensDomain values, you cannot just say that by
> putting the URI as the value of the lensDomain property. Because it
> would be interpreted as a class, and thus the domain would be "all
> instances that belong to the class represented by this URI", and since
> the URI refers to an instance and not a class, it is empty. So we need
> something else.
>
> What you want to do is make the difference between:
> a) lensDomain values that are to be interpreted as "instances of the
> specified class"
> b) lensDomain values that are to be interpreted as "the instance which
> has this URI"
>
> You want to do this by specifying different kinds of lenses. I'm not
> sure this is the best way of doing this. I mean, it is not the right
> level for making the difference. It artifically creates different types
> of lenses whereas this is not necessary. Because in the end there is no
> fundamental difference between the two kinds of lenses. So it would be
> better to make the difference at the lensDomain level. If we do that, I
> would be much more comfortable with the whole idea (though I'm still not
> convinced this is absolutely necessary to do it explicitely).
>
> So, where you say:
>
> /********************************************************/
> foafPersonLens rdf:type fresnel:ClassLens ;
> fresnel:lensDomain foaf:Person .
>
> :oldGuys rdf:type fresnel:InstanceLens ;
> fresnel:lensDomain
> "foaf:Person[foaf:age/* > 60]"^^fresnel:selector;
> /********************************************************/
>
>
> I'd rather say something like (for the reasons mentioned above):
>
> /********************************************************/
> foafPersonLens rdf:type fresnel:Lens ;
> fresnel:lensInstanceDomain foaf:Person .
>
> :oldGuys rdf:type fresnel:Lens ;
> fresnel:lensClassDomain
> "foaf:Person[foaf:age/* > 60]"^^fresnel:selector;
> /********************************************************/
>
> We can of course change the property names if somebody offers something
> better.
>
> What do you think ?
>
Good idea. Yes, I acutally think your solution of encoding the information
into the
property name is better than to encode it into the class name.
It makes Fresnel look less complicated if there are only two basic classes.
Or actually three basic classes if you are also counting fresnel:group.
There is interesting stuff you can do with the groups. I will send an
example for how groups can be used to render tables later today.
But I would flip the wording.
A fresnel:lensClassDomain contains the name of a class and means that the
lens applies to all instances of this class.
A fresnel:lensInstanceDomain contains a set of instances (usually created
with a FSL query) and means that the lens applies exactly to these
instances.
OK?
lensClassDomain is kind of the default behaviour, so we could also just call
it lensDomain. Or even better: Just have fresnel:domain
(fresnel:classDomain) and
fresnel:instanceDomain and use these properties on lenses and styles. There
is no real reason to have the word lens or style in the property name.
What do you think?
>
> > Another advantage is that using this explicit distinction, we can also
> > display RDF schema information and OWL ontologies, which we cann't if
> > the browser automatically infers the instances. Right?
>
> I don't see why. Suppose you want to visualize an RDF schema. You
> probably want to define a lens for resources representing classes,
> another one for resources representing properties. These are
> respectively typed as rdfs:Class and rdf:Property.
>
> So you would just have:
> /********************************************************/
> lensForClasses rdf:type fresnel:Lens ;
> fresnel:lensDomain rdfs:Class .
>
> lensForProperties rdf:type fresnel:Lens ;
> fresnel:lensDomain rdf:Property .
> /********************************************************/
>
This brings us to the interesting topic of inference. Your approach works if
the browser doesn't do subclass inferencing. If it does then your lens would
apply to all typed instances in the dataset.
There are arguments for both approaches.
1. If the browser does interencing, then a fresnel:lensDomain foaf:person
lens would apply to all instances of foaf:Person and subclasses of
foaf:Person. You would have to use instanceDomain to explicitly state that
you want to display classes as instances.
2. If the browser doesn't so inferencing, then your solution would work for
direct subclasses of rdfs:Class but not for deeper subclasses.
I would prefer the first approach. What do the others think?
>
> Now, if you want to apply a lens to a specific resource representing a
> class in the RDFS, say foaf:Person, you would write:
> /********************************************************/
> lensForClassPerson rdf:type fresnel:Lens ;
> fresnel:lensDomain "*[. =
> foaf:Person]"^^fresnel:selector .
> /********************************************************/
>
>
> > We could of course also trick around with FSL. But I would really like
> > to have this distinction in the core with basic rdf nameing.
>
> Well, yes, that's what I did, and there's no real alternative, I agree.
> So, the issue is, do we want to be able to express "specific instance
> selectors" (a corner case in my opinion) even if FSL is not available,
> or do we require the use of FSL to do that.
>
> In the first case, we indeed need to differentiate between the two at
> the Fresnel level, either using two kinds of lenses (InstanceLens and
> ClassLens), or using two kinds of lensDomain properties
> (lensInstanceDomain and lensClassDomain). I'd rather have the second as
> argued above.
>
> In the second case, we don't need to make the difference. I believe this
> case to be more elegant, but it requires indeed FSL support for
> expressing specific instance selectors, and it might be a little more
> difficult for users to master, as it is less explicit than the first
case).
>
> I'd really like other peoples' opinion on this.
>
Yes, definitivly!
>
> > _at_@@ we could add that the same thing can also be expressed as
> > "foaf:Person[foo:age/"30"]"^^fresnel:selector
> >
> > Yes, but don't we confuse user who haven't read the FSL spec with this
> > more than we help them.
> > I would prefer to mention only one syntax at this point and leave it to
> > the FSL spec to explain the different appreviations.
> >
> > The decision which syntax to put there is of course up to you.
>
> In that case I'd rather have the short one, i.e.
>
> "foaf:Person[foo:age/"30"]"^^fresnel:selector
>
> because it is simpler and closer to basic selectors.
>
OK, I will change the documentation.
Cheers,
Chris
>
>
>
> --
> Emmanuel Pietriga
> INRIA Futurs - Projet In Situ tel : +33 1 69 15 34 66
> Bat 490, Université Paris-Sud fax : +33 1 69 15 65 86
> 91405 ORSAY Cedex http://www.lri.fr/~pietriga
>
Received on Thu Mar 24 2005 - 15:18:10 EST