Chris Bizer wrote:
> I also met with Hannes Gassert yesterday (he was in Berlin on his way back
> from DERI to Switzerland). He will publish the first version of Arago in
> about two weeks (the code will become part of RAP). Arago will support
> Lenses and Styles including CSS according to our current manual (which he
> likes). He also uses some kind of intermediate tree in his implementation
> (no XML but PHP objects) and is thus also very interested on how we design
> our intermediate tree. Another comment from him was, that he would like to
> have a mechanism to say that a URI should be interpreted as an external link
> (to an HTML page, SPARQL query, or whatever). Something that we have
> discussed and decided to delete from the spec for some reasons. Does anybody
> remember the reasons?
I'm not sure I see what you are refering to exactly by "interpreted as
an external link". Is that about the link behavior (i.e. open in a new
window, or in the same window)?
> We shouldn't forget David Karger's requirement about
> having resource URIs in the tree so that Haystack can edit the data in the
> repository if necessary. You have this URI in your tree, but I think we
> should also have it as explicit requirement.
ok.
> What's about the attribute value namespace problem? E.g. uri="foo:EP"
> Maybe we should avoid attributes at all?
Yes, I forgot about this problem. I put some data as attributes because
it is less verbose, and because that's what I do with data that I
consider as metadata (and resource URIs are metadata at this point).
But it is indeed a problem for XSLT and other processing tools that only
act at the XML level and cannot be customized to expand namespace
prefixes in attribute values. The question is: do we really need to make
this information available to XSLT transformations? I'm not convinced it
is the case. What would they do with these URIs?
One possibility is to put fully expanded URIs as attribute values. See
below.
>>XSLT or template languages could take as input either the first tree or
>>this enriched version depending on what Fresnel modules are supported.
>>Or the tree could be further enriched with styling instructions.
>>
>>
>>Some issues:
>>- I'm using class information as XML element names for elements that are
>>resources. What do we do when no such information is available? We can
>>have some kind of default name in the fresnel namespace (I've used
>>fresnel:g in the example). What if a resource is an instance of multiple
>>classes?
>>- is the class="property" really necessary?
>>
>
>
> I'm not an XSLT crack, but wouldn't it be easier for templates to have
> Resource and Property elements which they could match instead of different
> foaf:Person, foaf:Document ... elements. Changing that would also solve the
> two problems mentioned above.
>
> So something like that (also including sublens and contentafter output):
>
> <inter:Resource>
>
> <inter:type>http://xmlns.com/foaf/0.1/Person</inter:type>
> <inter:type>http://example.org/ex#Thing</inter:type>
> <inter:uri>http://foo.org/EP</inter:uri>
>
> <inter:Property>
> <inter:uri>http://xmlns.com/foaf/0.1/firstName</inter:uri>
> <inter:label> Firstname </inter:label>
> <inter:value> Emmanuel </inter:value>
> <inter:Property>
>
> <inter:Property>
> <inter:uri>http://xmlns.com/foaf/0.1/mbox</inter:uri>
> <inter:label> Mailbox </inter:label>
> <inter:value> emmanuel_at_irina.org </inter:value>
> <inter:contentAfter>, <inter:contentAfter>
> <inter:value> emmanuel_at_w3.org </inter:value>
> <inter:contentLat>.<inter:contentAfter>
> <inter:Property>
>
> <inter:Property>
> <inter:uri>http://xmlns.com/foaf/0.1/depiction</inter:uri>
> <inter:value><image>http://example.org/id.jpg</image></inter:value>
> <inter:value><image>http://example.org/id2.jpg</image></inter:value>
>
> <inter:Property>
>
> <inter:Property>
> <inter:uri>http://xmlns.com/foaf/0.1/knows</inter:uri>
> <inter:label> Knows </inter:label>
> <inter:value>
> <inter:Resource>
> <inter:type>http://xmlns.com/foaf/0.1/Person</inter:type>
> <inter:uri>http://foo.org/Chris</inter:uri>
> <inter:Property>
> <inter:uri>http://xmlns.com/foaf/0.1/firstName</inter:uri>
> <inter:label> Firstname </inter:label>
> <inter:value> Chris </inter:value>
> <inter:Property>
> </inter:Resource>
> </inter:value>
> <inter:value>
> <inter:Resource>
> <inter:type>http://xmlns.com/foaf/0.1/Person</inter:type>
> <inter:uri>http://foo.org/Stefano</inter:uri>
> <inter:Property>
> <inter:uri>http://xmlns.com/foaf/0.1/firstName</inter:uri>
> <inter:label> Firstname </inter:label>
> <inter:value> Stefano </inter:value>
> <inter:Property>
> </inter:Resource>
> </inter:value>
> <inter:Property>
>
> </inter:Resource>
I like it, but you're not solving the NS prefix binding expansion
problem, as you have URIs in #PCDATA. So I don't understand what is the
benefit of writing:
<inter:Resource>
<inter:uri>
http://foo.org/Stefano</inter:uri>
[...]
</inter:resource>
instead of:
<inter:Resource uri="
http://foo.org/Stefano">
[...]
</inter:resource>
You can address attributes in XPath using the _at_ axis (e.g.
inter:Resource/_at_uri)
Your proposal is indeed very verbose, but it is indeed not a problem as
this representation is mostly produced and consumed by machines. And it
makes processing easier.
--
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 Tue May 03 2005 - 12:44:14 EDT
