[foaf-dev] strawpoll: migrate from foaf:holdsAccount to foaf:account?

Peter Ansell ansell.peter at gmail.com
Thu Aug 27 01:00:45 CEST 2009

2009/8/25 Simon Reinhardt <simon.reinhardt at koeln.de>:
> Peter Ansell wrote:
>> For example if I said that <http://twitter.com/p_ansell>
>> <twitterPosts> "39" and <http://twitter.com/p_ansell> <contentType>
>> "text/html", I would expect that there are two contexts being referred
>> to by virtue of a previous declaration that the domain of
>> <twitterPosts> is <foaf:Account> and the previous declaration that the
>> domain of <contentType> is <document>, and be able to have the
>> knowledge that they are that, without simply having a contradiction.
>> If foaf:Account for any reason was derived from <document> than there
>> wouldn't be a current contradiction, but if the domains are
>> independently traversed and segmented so they only apply to their
>> localised triples then there could easily be two concepts with one
>> name, and future references would have to have a range or domain that
>> either made it clear what they were referring to, or they would have
>> to refer to both concepts at the same time because that would be the
>> nature of the statement. In the example this would mean that I could
>> interpret <http://twitter.com/iand> <hasFollower>
>> <http://twitter.com/p_ansell> as referring to the foaf:Account
>> context, and <file://mycomputer/downloads/twitter.com_p_ansell>
>> <copyOf> <http://twitter.com/p_ansell> as referring to the document
>> context while <http://mailinglist.org/posts/2008/August/4342.html>
>> <containsLinkTo> <http://twitter.com/p_ansell> would have to refer to
>> both, otherwise you would not be able to interpret arbitrary links to
>> URI's in plain text mailing list posts that could infact not just be
>> of type <document>
> So, in order to treat the different contexts of triples properly you need to
> dereference all properties being used and find out their domains and ranges.
> But doesn't that kind of contradict what you said earlier:
>> I don't
>> think it is wise to indicate to people that unless they have internet
>> access they can't interpret RDF documents as I don't see any reason
>> why HTTP GET needs to be performed before any interpretation can
>> occur.

I don't see it as an issue, unless you are already using the 303/Hash
to make ontology properties into documents if they don't use 303 or
hashes. The required use of the HTTP GET was to emphasise that in the
current LD world even if you have triples you don't know what the true
type is unless you resolve the subject of the triples at some point to
get access to the HTTP protocol metadata. Having to have access to the
definitions of the predicates is a much lower barrier to entry,
particularly as you could do it without keeping information about the
HTTP resolution, as the original RDF triples containing the
definitions of the properties are enough on their own to get a clear
type resolution for the subject and object of any given triple that
uses the property as a predicate.

You also don't have to resolve the document if you believe that you
have all of the relevant triples in your database, as you can also
compute whether the type inferences from the properties are consistent
with any actual <subject> rdf:type <xyz> or <object> rdf:type <abc>
triples that are actually there and not inferred using properties.
<xyz> or <abc> could be foaf:Document that might be currently added by
a strict LD client if there is a 200 response to "help" out the author
of the triples by potentially making some of the other type inferences
or declarations inconsistent.



More information about the foaf-dev mailing list