> It is true that the alternative is more compact since people will
> probably tend to use more class selectors than instance selectors, but
> in my opinion consistency is more important.
>
> > I can accept that.
>
Another alternative would be not to use the abbriviation at all in oder to
make it clearer and explicit if a domain refers to instances, classes or
properties. This would mean:
classLensDomain, instanceLensDomain,
propertyFormatDomain, classFormatDomain, instanceFormatDomain.
But anything else is also fine with me.
Chris
----- Original Message -----
From: "Emmanuel Pietriga" <Emmanuel.Pietriga_at_lri.fr>
To: <fresnel-dev_at_simile.mit.edu>
Sent: Thursday, June 30, 2005 3:28 PM
Subject: Re: AW: AW: Fresnel instance and class lenses and lens specifity
function
> Ryan Lee wrote:
> > Emmanuel Pietriga wrote:
> >
> >> Chris Bizer wrote:
> >>
> >> >> Reading the current version of the manual, a terminology
consistency
> >> >> issue arose, but before discussing it I want to close this
> >> discussion.
> >> >> Do you still have concerns/problems/... about this?
> >>
> >>>
> >>> No, my misunderstanding of FSL. Problem solved.
> >>
> >>
> >> Before I begin editing the Fresnel Vocab document, there is one
> >> terminology issue that we need to discuss.
> >>
> >> The current version uses lensDomain / instanceLensDomain /
> >> classFormatDomain / instanceFormatDomain.
> >>
> >> This is not very consistent; we should either have:
> >> lensDomain / instanceLensDomain / formatDomain / instanceFormatDomain
> >> or:
> >> classLensDomain / instanceLensDomain / classFormatDomain /
> >> instanceFormatDomain
> >
> >
> > I think the complete list of domain properties includes formatDomain:
> > lensDomain, instanceLensDomain, formatDomain, classFormatDomain,
> > instanceFormatDomain.
> >
> > formatDomain expects properties or lists of properties in core. Unless
> > you were driving home a point just about the resource-type domain
> > properties, I think it makes your proposal below a bit incomplete.
> >
> > Maybe propertyFormatDomain?
>
> Yes, I was only considering resource-type domain properties. I didn't
> actually considered the case of formats, just lenses, stupidly thinking
> that it would be the same for formats. But you're right.
>
> I consider my proposal to be ok for lenses, but I'm not sure it is good
> for formats, even if we add propertyFormatDomain. Let me finish editing
> the Fresnel manual (I'll be done tomorrow), and I'll post an adapted
> proposal to the list.
>
>
>
>
> >> But actually, thinking about all this, and considering that we
> >> eventually agreed that this distinction only makes sense for simple
> >> selectors, I would like to propose slightly different names (ordered
> >> the same as above):
> >> classLensDomain / lensDomain / classFormatDomain / formatDomain
> >>
> >>
> >> Rationale for this change: as we agreed upon, making the distinction
> >> between class*Domain and instance*Domain only makes sense for simple
> >> selectors, but not for FSL/SPARQL. But if we really had to choose
> >> between instance*Domain and class*Domain for FSL/SPARQL selectors, we
> >> would choose instance*Domain (that's what we do throughout the manual).
> >>
> >> So it is actually better to use the "unqualified" name (i.e.,
> >> lensDomain/formatDomain) for replacing instance*Domain rather than
> >> class*Domain. This way we can still make the distinction between class
> >> and instance domains for simple selectors, and it does not look
> >> weird/confusing for FSL/SPARQL selectors.
> >>
> >> Is that okay with you?
> >
> >
> > It doesn't quite fit with making the most used terms compact, but it is
> > more consistent.
>
> It is true that the alternative is more compact since people will
> probably tend to use more class selectors than instance selectors, but
> in my opinion consistency is more important.
>
> > I can accept that.
>
>
>
> --
> 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 FRANCE http://www.lri.fr/~pietriga
>
Received on Thu Jun 30 2005 - 16:40:18 EDT