Re: Reading through vocabulary

From: Chris Bizer <chris_at_bizer.de>
Date: Fri, 1 Jul 2005 11:18:38 +0100

Hi Ryan,

----- Original Message -----
From: "Ryan Lee" <ryanlee_at_w3.org>
To: <fresnel-dev_at_simile.mit.edu>
Sent: Thursday, June 30, 2005 8:50 PM
Subject: Reading through vocabulary


> I did a quick skim through the latest repository version of the
> vocabulary, skipping details for now knowing Emmanuel is working on some
> revisions.
>
>
> 1. :myGroup fresnel:stylesheetLink <http://...> .
>
> seems like it should be an optional hint. I don't think I'll be writing
> code for Longwell to pick up externally referenced CSS stylesheets. In
> keeping with the 'if I say it, do it' razor for core, I think this
> should be moved to extended.
>

No. I think the idea that browsers search for display knowledge for unkown
vocabularies on the web is still one very important feature of Fresnel and
thus the core vocabulary should also support getting the relevant styling
information from external sites.

Touching this would bring us back to one of our basic design problems: Ryan
and Stefano tend to see Fresnel as a local configuration language for
Longwell. I see it as a mechanism to exchange display knowledge. So better
leave this point untouched.

>
> 2. :labelLens
>
> It was unclear to me during implementation how to interpret a label lens
> that's more complex than one property. What happens when something like
> the following is submitted to a Fresnel engine?
>
> :foafPersonLabelLens rdf:type fresnel:Lens ;
> fresnel:purpose fresnel:labelLens ;
> fresnel:classLensDomain foaf:Person ;
> fresnel:showProperties ( foaf:name foaf:mbox ) .
>

Then this lens is used for labelling, meaning that a person is
labelled/represented with its name *and* mailboxes (which makes sense if I'm
having 10 Millers)

If the label lens is used together with FOAF knows then something like this
could be rendered:

Name: Chris Bizer
eMail: Chris_at_bizer.de
knows Ryan (ryanlee_at_w3.org)
            Emmanuel (Emmanuel.Pietriga_at_lri.fr)

> Is each implementer going to be left to determine how to concatenate
> multiple property values on their own? Multiple values for one property?
>
> Though... does this look reasonable (abbreviated lens)?
>
> :foafPersonLabelLens fresnel:showProperties (
> foaf:name
> [ rdf:type fresnel:PropertyDescription ;
> fresnel:property foaf:mbox ;
> fresnel:valueFormat [
> fresnel:contentBefore "(" ;
> fresnel:contentAfter ")" ;
> ]
> ) .
>
> If it does, should we include it as an example somewhere?
>

I think we are still trying to somehow striclty seperate between selection
(lens) and formating (format) and I would thus prefer.

 :foafPersonLabelLens fresnel:showProperties (
    foaf:name
    [ rdf:type fresnel:PropertyDescription ;
      fresnel:property foaf:mbox ;
      fresnel:use :mboxFormat .
      ]
 ) .

:mboxFormat rdf:type fresnel:Format ;
         fresnel:valueFormat [
              fresnel:contentBefore "(" ;
              fresnel:contentAfter ")" ] .


or even

 :foafPersonLabelLens fresnel:showProperties (
    foaf:name
    [ rdf:type fresnel:PropertyDescription ;
      fresnel:property foaf:mbox .
      ]
 ) .

:mboxFormat rdf:type fresnel:Format ;
         fresnel: propertyFormatDomain foaf:mbox;
         fresnel:valueFormat [
              fresnel:contentBefore "(" ;
              fresnel:contentAfter ")" ] .

Without the hardcoded link between the two.

I think we really shouldn't mix selection and formatting/styling!

> 3. Searching for sublenses
>
> Section 2.5 discusses using FSL to search Fresnel for a sublens. Aside
> from being outside of core, this feels like an odd capability since FSL
> is normally used to query the data being Fresnel'ed. This raises
> questions of consistency. Also, the introspection aspect of using FSL
> on Fresnel seems like it would force implementers to consider their
> Fresnel information as a navigable RDF model in addition to whatever
> else they do with it. They should anyways, but it's... weird.
>

This example is in the manual to show how Haystack functionality could be
emmulated. Therefor moving it should be discussed with David Karger.

Cheers and a nice weekend.

Chris

> --
> Ryan Lee ryanlee_at_w3.org
> W3C Research Engineer +1.617.253.5327
> http://simile.mit.edu/
Received on Fri Jul 01 2005 - 09:15:23 EDT

This archive was generated by hypermail 2.3.0 : Thu Aug 09 2012 - 16:40:51 EDT