Re: [foaf-dev] Request for addition of an inverse property for foaf:member

+Cc: Jeni (see also full post c/o
http://lists.foaf-project.org/pipermail/foaf-dev/2011-September/010779.html
)

On 27 September 2011 20:23, Houghton,Andrew <[email protected]> wrote:
> Many times when I'm dealing with data that involves foaf:Group and foaf:Person its less than ideal to know up front all the persons associated with a particular group in order to create the group definition. FOAF currently requires, unless I've missed a property definition, agents to be associated with the group via the foaf:member property, e.g.:
>
> #P1 a foaf:Person .
> #P2 a foaf:Person .
>
> #G1
>  a foaf:Group ;
>  foaf:member #P1 ;
>  foaf:member #P2 ;

Yes, per http://xmlns.com/foaf/0.1/#term_member we named this in the
direction from Group to Person/Agent.

There is a natural and unavoidable tradeoff here. If we add
convenience vocabulary, the data becomes more diverse and
expensive/complex to consume. The question is where to put the cost
and work.

By adding redundant extra terms into FOAF (eg. primaryTopic is
shadowed by isPrimaryTopicOf; depicts by depiction, etc.) we can make
things easier for users of syntaxes like RDF/XML which are asymmetric.

However, this pushes work down into the application and consumption
layers, since the data now contains more variations, even while those
variable forms tell us nothing interestingly new. So for example, an
application that stored information might choose to canonicalise
'depicts' to 'depiction' or vice-versa, at the cost of losing
information about the exact original form of the data. Or it might
choose to create additional layers of data derrived from the raw
inputs, at cost of complexity, storage and processing. Or it might
choose to backwards-chain and answer questions about 'depicts' by also
consulting 'depiction' triples or vice-versa. At other costs, eg.
custom code, or integration, enabling, benchmarking or optimisation of
inference tools. Or it might choose to push the work to other
applications further downstream, e.g. by requiring more complex SPARQL
queries.

Initially (eg. at time 'depicts' and 'depictions' pair were created)
the RDF/XML syntax was even more asymmetric, since it did not have the
rdf:nodeID construct.

Post-2004, you can at least express things in RDF/XML, albeit
gracelessly, without needing inverses.

In NTriples, the issue doesn't arise; you can express things in either
direction.

In http://www.w3.org/TR/turtle/ which doesn't have N3's "p1 is member
of g1" construct, you can express things but it might not be as
elegant as you'd hope.

In RDFa 1.x, the issue depends on the availability of "rev=" in the
host language (HTML5, SVG, ...). I believe RDFa 1.0 with SVG you can
use rev="foaf:member"; but not currently in HTML5. It is worth
exploring this further.

My current inclination is to suggest that it is ultimately better if
we have an idiom such as RDFa's rel= vs rev= attributes, rather than
introduce lots of new properties that don't tell us anything new. But
it is a fair question, and I won't close the door on possibility of
new inverse properties.

I'm cc:'ing Jeni Tennison as this might be an interesting use case for
W3C's new taskforce on Web data microsyntaxes (or whatever we call
RDFa/Microdata/microformats...).

cheers,

Dan
_______________________________________________
foaf-dev mailing list
[email protected]
http://lists.foaf-project.org/mailman/listinfo/foaf-dev