RE: Open Library and RDF

Dan Brickley wrote:
> > People in our community mistakenly believe that foaf:Person is
> > unsuitable for use because of foaf:geekcode and other such
> properties.
> > Specialized models, including library models, are completely
> arbitrary.
> 
> Can you say a bit more about what you mean by 'arbitrary' here?

Not easily in an email. It's a combination of philosophy and experience. IMO, use cases are fundamental. Non-trivial models are evolutionary and their form depends on the order in which use cases are considered. Until we see how concepts are related in a formal model and applied to specific use cases, we just *think* we understand each other (and even ourselves). I believe that OWL/UML will make it easier for people to adapt to how other people/systems/themselves think, but only if the models don't expect us to believe too many arbitrary things in the process.

> > I encourage you to keep your model as simple and intuitive as
> possible
> > and encourage specialized communities to do this instead:
> >
> > ex:Person a owl:Class ;
> >        owl:equivalentClass foaf:Person .
> 
> Yes, I've heard that concern before, and this revision contains some
> steps towards addressing this.
> 
> * some old 'demo' and fun terms have been flagged 'archaic' (although
> they will remain mentioned in the spec, as it is anti-social to
> pretend a piece of vocab never existed).

I agree. 

Out of curiosity, why not use owl:DeprecatedProperty instead? I tried to use deprecation in the VIAF OWL and couldn't figure out how to preserve DL compliance. Eventually I had to abandon the stale concepts or else go crazy.

> * substantial chunks of the spec's text have been moved to the Wiki;
> this will continue, so the footprint of a term within the main body of
> the spec text can be substantially reduced. Each term has a wiki page
> now, as standard.
> * The 'at a glance' overview of FOAF at top of spec now separates the
> 'Webby' properties from core people properties and is more explicit
> about cultural heritage aspects use cases for FOAF.
> 
> I think this goes a healthy way towards reducing the perception of
> needless frivolity. The project has in fact always been a quite
> serious endeavour, despite the light tone. Serious both in the sense
> of promoting the notion of a Web of inter-linked RDF files, but also
> in terms of global ambition - I want young people discovering the Web
> to see a direct parallel between the friends and links they find in
> modern online 'social network' contexts, and the older, sometimes
> drier links that connect them via chains of collaboration, friendship
> and family to Paul Erdős, Marie Curie, Kevin Bacon, or Charles Darwin.
> And for the data to be there that makes those chains explicit and
> accessible to all. So in that sense, the bridging of 'social Web' and
> historical data is absolutely intended. However I don't want to
> embarrass anyone in a professional context with 'silly' properties,
> and I feel they have served their purpose of making a fun, accessible
> project that felt approachable and open to experimentation. So it is
> quite natural for things like 'geekcode' or 'dnaChecksum' to end up as
> historical footnotes now, and the emphasis to move towards finding fun
> things to do with the massive amounts of data we now have on hand.

I certainly agree that FOAF is serious. In hindsight, it's just funny how many examples I had to run through in my head in order to believe every person is a foaf:Person. It’s the same basic problem with every thing being an owl:Thing. The more people who realize and trust these seemingly banal assertions, the more useful they will become.

> Many of the original use cases in
> http://www.foaf-project.org/original-intro stemmed from the background
> Libby and I had in the digital library and subject gateway community,
> so at the risk of repeating myself here I'd like to get to the bottom
> of any 'x felt they couldn't use it because y' stories that are
> mentioned.

I suspect people are senselessly waiting for grand unified/normalized models to emerge. I think the possibilities of this are yes and no. On the local "yes" side, I think each domain should have its own normalized self-conceptualization based on corporate lingo and use cases. On the global "no" side, the local self-conceptualization can be mapped to other popular/emergent models at runtime to communicate inside and outside their community. VIAF does this a little bit today, but in the future I hope we can be clearer about the conceptual separations. For example:

http://viaf.org/viaf/27060791 (self-conceptualized real world object)
http://viaf.org/viaf/27060791/ (self-conceptualized generic document)
http://viaf.org/viaf/27060791/viaf.rdf (self-conceptualized Web document)
http://viaf.org/viaf/27060791/foaf.rdf (FOAF-conceptualized Web document)
http://viaf.org/viaf/27060791/skos.rdf (SKOS-conceptualized Web document)
http://viaf.org/viaf/27060791/rda.rdf (RDA-conceptualized Web document)
http://viaf.org/viaf/27060791/vcard.rdf (vCard-conceptualized Web document)
http://viaf.org/viaf/27060791/all.rdf (merged conceptualized Web document)
etc.

I didn't pick the self-conceptualized RWO URI, but Andy Houghton and I are responsible suggesting hash URIs on the generic resource to identify "foreign" RWOs w/namespace prefixes to avoid collisions:

http://viaf.org/viaf/27060791/#foaf:Person


(I wish these hash URIs were wired up to do something useful in the HTML representation.) 

Regardless, this is a generalizable model that would allow systems to "conjure up" new conceptualizations from legacy conceptualizations without redesigning physical data models or breaking legacy system dependencies. I suspect this is an extremely valuable pattern, so I will write it up as an LLD XG use case after my vacation.

> Other things I've heard mentioned are that there is no long
> term organizational backing behind the namespace yet, or that it isn't
> a 'proper standard' of some kind. The more explicit people are when
> describing obstacles, the more active we can be in addressing them.

I assume organizational backing would be the death of FOAF because "they" will almost certainly load it down with debatable "improvements". :-/

Jeff

> 
> All that said, it is of course more than fine to express a link to the
> Web of FOAF data via owl:equivalentClass.
> 
> cheers,
> 
> Dan

Received on Sunday, 15 August 2010 18:23:46 UTC