[foaf-dev] Request for addition of an inverse property for foaf:member
mischa.tuffield at garlik.com
Wed Sep 28 00:02:31 CEST 2011
On 27 Sep 2011, at 20:47, Dan Brickley wrote:
> +Cc: Jeni (see also full post c/o
> On 27 September 2011 20:23, Houghton,Andrew <houghtoa at oclc.org> 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 .
>> 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
> 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
> 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.
+1 to keeping things simple.
When I did a lot of FOAF harvesting and processing the ability to represent concepts in various forms made life that much more difficult than I would have liked - either in form more or highly complex queries. swh was talking about how being able to optionally drop the WHERE clause in SPARQL selects has been known to cause confusion.
> 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
> foaf-dev mailing list
> foaf-dev at lists.foaf-project.org
Mischa Tuffield PhD
Email: mischa.tuffield at garlik.com
Homepage - http://mmt.me.uk/
+44(0)208 439 8200 http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the foaf-dev