- From: Dan Brickley <danbri@danbri.org>
- Date: Wed, 18 Jun 2014 20:41:12 +0100
- To: Mark Harrison <mark.harrison@cantab.net>
- Cc: "public-vocabs@w3.org" <public-vocabs@w3.org>, "Jason Johnson (BING)" <jasjoh@microsoft.com>, Vicki Tardif Holland <vtardif@google.com>
On 18 June 2014 19:19, Mark Harrison <mark.harrison@cantab.net> wrote: > Hi Dan, > > Thanks for the update about http://schema.org/Role > > On the whole, I think introducing http://schema.org/Role is an improvement, to allow additional context to be added to the role associated with the original predicate such as http://schema.org/actor > > There might be other non-static / transient relationships elsewhere in schema.org that are currently being expressed via a simple predicate, where something analogous to a Role is required, just as we already have http://schema.org/Event and http://schema.org/Order (representing a record of a transaction). Yes, our intent was that the Role type could be applied directly to such situations. The name of the type does evoke the sporting/movies/music scenarios, but is also also a more generic sense of "role" that is a reasonable fit for our usage ("the function assumed or part played by a person or thing in a particular situation."). > However, I think there is now a need to update the documentation for the recently 'overloaded' predicates ( such as http://schema.org/actor ) to mention that a schema:actor property may accept a schema:Person OR a schema:Role as its value and it may ALSO be used with a type of schema:Role. There are a lot of properties where it is equally applicable, so I'm not sure spotlighting "actor" (vs "author", "publisher", etc.) is urgently needed. As Vicky says, it's a tricky balancing act. It might be that we could do something on the per-property pages with examples (current we only show examples for types). > It might also be helpful to provide some guidance that if anyone was using SPARQL queries on RDF data expressed using predicates such as schema:actor , they might need to change the WHERE clause of their query to use (SPARQL v1.1) predicate paths / property chains, to expect schema:actor+ instead of schema:actor , since schema:actor is being re-used to connect a schema:Movie to a schema:Role and a schema:Role to a schema:Person, as well as directly from a schema:Movie to a schema:Person. Alternatively, a SPARQL query could introduce an intermediate ?role variable and match on > > ?movie schema:actor ?role . > ?role schema:actor ?actor . > > in addition to the existing ?movie schema:actor ?actor . pattern that they may already have in their WHERE clause. I think you've just done that! (i.e. provide guidance). Good point about v1.1 of SPARQL where schema:actor+ is a nice idiom for working with Role. I was yesterday looking at other graph navigation frameworks and how they deal with this - for those interested, https://groups.google.com/forum/#!topic/gremlin-users/LId-WybOaDo has some discussion of Gremlin and Property Graphs, including code samples. They've used a very similar representation - see eg. http://www.slideshare.net/slidarko/titan-the-rise-of-big-graph-data/60 > I have prepared a small zip file to illustrate two ways in which existing SPARQL queries can be modified to support the introduction of an intervening node of class http://schema.org/Role > > You can download it from http://www.autoidlabs.org.uk/GS1Digital/schema-role-test.zip and try it out with any SPARQL v1.1 implementation such as Jen ARQ. works for me, using https://jena.apache.org/download/index.cgi e.g sparql --query=oldsparql.rq --data=oldtriples.ttl sparql --query=newsparql1.rq --data=newtriples.ttl sparql --query=newsparql2.rq --data=newtriples.ttl There are also things you can do like PREFIX schema: <http://schema.org/> CONSTRUCT { ?movie schema:name ?moviename . ?actor schema:name ?actorname . ?movie schema:actor ?actor } WHERE { ?movie schema:actor+ ?actor . ?movie schema:name ?moviename . ?actor schema:name ?actorname . } ... which turn new-style data into old-style data. > Please feel free to include such guidance to SPARQL users in the schema.org documentation for the introduction of schema:Role , to help users cope with data that does / does not make use of schema:Role . So far we've tended to keep the main site very 'mainstream webmaster' oriented, but I'm getting to think it does deserve a page or so for this more specialized audience of people working with the W3C RDF specs and technologies. That said we already have links to http://www.w3.org/wiki/WebSchemas which should be writable by anyone here. So feel free to jump in via the Wiki, and we can link to interesting entries from schema.org more directly. > Furthermore, I noticed an inconsistency in the third example in the http://schema.org/Role page - in the JSON-LD example, the predicate is correctly shown as http://schema.org/alumniOf - but for the Microdata and RDFa versions of the same example, the inverse property (http://schema.org/alumni ) is shown by mistake. This appears to be just a copy-paste error from example 2 on that page. Thanks - fixed! https://github.com/rvguha/schemaorg/pull/50 > I hope this helps! Very much :) it's always healthy to have running code and demos to help people understand complex ideas... cheers, Dan > Best wishes, > > - Mark > > > Dr. Mark Harrison > Senior Research Associate, Distributed Information and Automation Laboratory > Director, Auto-ID Labs at Cambridge > Institute for Manufacturing > University of Cambridge > 17 Charles Babbage Road > Cambridge, UK > CB3 0FS > > E-mail: mark.harrison@cantab.net > http://www.autoidlabs.org.uk > > > >
Received on Wednesday, 18 June 2014 19:41:50 UTC