W3C home > Mailing lists > Public > www-rdf-interest@w3.org > December 2001


From: Danny Ayers <danny666@virgilio.it>
Date: Sat, 29 Dec 2001 12:59:14 +0100
To: "RDF-Interest" <www-rdf-interest@w3.org>
Message-ID: <EBEPLGMHCDOJJJPCFHEFMEMNEJAA.danny666@virgilio.it>
While working on a graph visualisation app, I've run into a problem that
suggests a generic solution but I haven't been able to figure out the best
approach, so I was hoping for suggestions.

The specific case is that I have a graph described in RGML [1] which I want
to display. RGML has a Node class, and label property (string literal), so
there is no problem giving a visual representation of a node a label. The
immediate problem is I want to be able to say that this node in the graph
represents something else, from which resource I can choose the info that
gets displayed. Another problem is that to be able to reason with the
information contained in the graph it will not only be necessary to be able
to express what each node represents, but also the relationships expressed
by the edges in the graph.

At first this looks very like it should be achievable using rdf:about or at
a pinch rdf:isDefinedBy, though I don't think either of these really convey
the same semantics.

In general, this is to make the statement that resource A represents B.
Turned around to read hasRepresentation makes this look just like a regular
property, though such a statement would be associated with the description
of B and in cases like that above it would be desirable for the statement to
be associated with A.

Properties xxx:represents & xxx:hasRepresentation might apply to a lot of
cases where resource A provides a view (however incomplete) or model
(apologies for the term) of B.

Is such a property necessary in a case like that above? Or am I not seeing
the wood for the trees once again?

Any suggestions?


[1] http://www.cs.rpi.edu/~puninj/RGML/

Danny Ayers
<stuff> http://www.isacat.net </stuff>

Alternate email (2001) :
Received on Saturday, 29 December 2001 07:03:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:38 UTC