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

Mischa Tuffield 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
> http://lists.foaf-project.org/pipermail/foaf-dev/2011-September/010779.html
> )
> 
> 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 .
>> 
>> #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.

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


Mischa #2cents 

> 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
> foaf-dev at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev

___________________________________
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...
URL: http://lists.foaf-project.org/pipermail/foaf-dev/attachments/20110927/8c64b93d/attachment.htm 


More information about the foaf-dev mailing list