My answer here is a little bit long, but I'd really like at least Chris,
Ryan and Stefano's opinion on this.
Chris Bizer wrote:
> _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 ?
> 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 .
/********************************************************/
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.
> _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.
--
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 - 09:28:26 EST