Re: AW: Final review of the manual

From: Emmanuel Pietriga <Emmanuel.Pietriga_at_lri.fr>
Date: Thu, 07 Jul 2005 08:31:09 +0200

Ryan Lee wrote:

> Almost... I realized a few small things while working through the
> format implementation.
>
> The first is minor. There should be a labelFormat property for, e.g.,
> if you want to display "name: John" with the colon. It's just that
> contentAfter/contentLast and contentBefore/contentFirst will end up
> being the same thing, but that already follows from what we've written
> up on content* conflicts. If fresnel:label is fresnel:none, I think I
> would ignore any labelFormat information. Thoughts?

Yes, these should be ignored. I would add, a Fresnel interpretor should
issue a warning in debug mode when encountering label formatting
instructions in conjunction with a fresnel:label=fresnel:none.



> 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. The same
> could go for resources if resourceFormat were allowed for use on a Group.

I'm not sure I understand what you mean exactly by "one specific
property (used in multiple resources)". That's a little bit ambiguous,
as I don't understand whether you're talking about a property type or a
what I calla property instance for lack of a better term, i.e., an
actual arc in the RDF graph. Can we talk about this in terms of nodes
and arcs instead? (I just want to make sure I get what you're saying
correctly).


> 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.
>
> 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. Or should we pick just one interpretation, as
> we already did before (sort of, by specifying which domain a content
> *Format was valid for)?

Waiting for clarification of the above part befre answering.




> 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.


> Would all formats be group-wise
> applicable?

I don't understand what you mean here.



> Lastly, does contentNoValue apply to every formatting it's used in? It
> clearly doesn't make sense in a valueFormat since one must be missing
> the entire triple in a model, not just a value. It makes sense for
> propertyFormat and intereferes with label resolution in labelFormat. I
> can't think of how to implement it smoothly for resources, especially
> specific instances, but I don't think it should be applied at that level
> anyways (and this is irrelevant if resourceFormat can't be used on a
> Group).

Yes, it is irrelevant in several cases. We should just forbid it to
appear where it does not make sense.




>>> What are our next steps now?
>>>
>>> We are having three things on our agenda:
>>> 1. Get the W3C website up.
>>> 2. Get something running "for real"
>>> 3. Write the workshop paper
>>
>>
>> Ryan and I are working on 2. Ryan's doing most of the work. I'm only
>> working on FSL implementation.
>>
>>> Ryan: Anything new about the first point?
>
>
> Working on what I wrote about above. It's the last step, and while a
> big one, I can probably have a command-line transformer to show off
> before the paper deadline. I don't know about Longwell integration, but
> it will be a working interpreter.

Good news!


-- 
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 Jul 07 2005 - 06:31:16 EDT

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