Re: AW: AW: Final review of the manual

From: Ryan Lee <ryanlee_at_w3.org>
Date: Thu, 07 Jul 2005 13:32:09 -0400

Chris Bizer wrote:
>>>The second is a bit more interesting. label and valueFormat can both be
>>>interpreted only one way because labelFormat is just a specific
>>>individual, and valueFormat is just for a set of values that can't be
>>>distinguished from one another. Unfortunately, propertyFormat is
>>>usefully interpreted as either - one specific property (used in multiple
>>>resources), or a set of properties belonging to one resource.
>
> I was always understanding it the "one specific property" way.

Ok.

>>>The same
>>>could go for resources if resourceFormat were allowed for use on a
>>>Group.
>
> I don't get this one. I think a resourceFormat used on a group should be
> interpreted as "all resources rendered by any lenses belonging to the group
> should be formatted using this format if not overridden by a more specific
> format".

That would be a different interpretation than using resourceFormat on a
resource type formatDomain. It's precisely the distinction I want to
draw out.

The conflict arises in where propertyFormat gets used. If we have just
that one predicate and we want it to do the analgous action of
resourceFormat+Group ('all properties rendered by the lens for matching
resources'), we can't right now. We'd need another predicate.

in this case:
[ a fresnel:Format ;
   fresnel:classFormatDomain "foaf:Person" ;
   fresnel:propertyFormatDomain "foaf:knows" ;
   fresnel:propertyFormat [ ... ] ] .
it isn't clear what propertyFormat should do.

>>>If I choose just the 'set of properties' interpretation, I can separate
>>>properties with a '|' character, but I can't add any specific extra
>>>explanation to the my:foobar predicate in the display. The problems
>>>swap if interpreted the other way. Likewise for resources.
>
> Why can't you use the "one specific property" interpretation and say
> something like the following in order to get both:
>
> :formatMbox rdf:type fresnel:Format ;
> fresnel:propertyFormatDomain foaf:name ;
> fresnel:propertyFormat [ fresnel:contentAfter "|"^^xsd:string ].
>
> :formatMbox rdf:type fresnel:Format ;
> fresnel:propertyFormatDomain foaf:mbox ;
> fresnel:propertyFormat [ fresnel:contentAfter "(To write the
> guy, click on his eMail address) |"^^xsd:string ].
>
> :formatMbox rdf:type fresnel:Format ;
> fresnel:propertyFormatDomain foaf:homepage ;
> fresnel:propertyFormat [ fresnel:contentAfter "|"^^xsd:string ].

Absolutely beside the point, all of those Formats are identified by the
same URI, so it would all be conflated into one Format. As a best
practice, does anybody have feelings about whether most of our lenses
and formats should be identified by a URI or whether they could be
bNodes (unless referred to elsewhere)?

Back on track. This is a matter of convenience. You could engineer a
Format for every property you mention in showProperties lists, but that
seems quite tedious. In the case of hideProperties, it won't work.

>>>Do we want different properties to address this distinction? We could
>>>specify that there would be no conflict resolution, so both properties'
>>>directives would show up.
>
> We would have a problem with ordering in this case because we couldn't
> distinguish between:
>
> (To write the guy, click on his eMail address) |
> | (To write the guy, click on his eMail address)

We could specify an order if we didn't rely solely on
propertyFormatDomain Format's to set content.

> If we would have:
>
> :formatMbox rdf:type fresnel:Format ;
> fresnel:propertyFormatDomain foaf:mbox ;
> fresnel:propertyFormat [ fresnel:contentAfter "(To write the
> guy, click on his eMail address)"^^xsd:string ];
> fresnel:propertyFormat [ fresnel:contentAfter "|"^^xsd:string ].

Maybe it would make sense to restrict *Format to show up only once in a
fresnel:Format in OWL.

>>>As mentioned above, are we interested in making *Format available to
>>>Groups? Unlike *Style, there would probably have to be some conflict
>>>resolution where the more specific domain formats would override the
>>>group scoped ones. If I wanted to say that all labels should end with
>>>':,' it would be easier with a Group.
>>
>>That would indeed be convenient.
>
> What about instance formats override class formats which override group
> formats?

That's one way to do the ordering.

I'll rewrite all of this as a proposal so we can discuss solutions.

-- 
Ryan Lee                 ryanlee_at_w3.org
W3C Research Engineer    +1.617.253.5327
http://simile.mit.edu/
Received on Thu Jul 07 2005 - 17:29:37 EDT

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