W3C home > Mailing lists > Public > www-tag@w3.org > June 2011

Re: Issue-57

From: Jonathan Rees <jar@creativecommons.org>
Date: Mon, 13 Jun 2011 13:51:31 -0400
Message-ID: <BANLkTinygGeJjQtMAdtxgi+YN4qJgU6Mxg@mail.gmail.com>
To: Jeni Tennison <jeni@jenitennison.com>
Cc: "www-tag@w3.org List" <www-tag@w3.org>
On Mon, Jun 13, 2011 at 11:30 AM, Jeni Tennison <jeni@jenitennison.com> wrote:
> Hi,
> For those who don't follow it, there's a thread on httpRange-14 / Issue-57 at the moment on the linked data mailing list. A good example message is:
>  http://lists.w3.org/Archives/Public/public-lod/2011Jun/0186.html
> where Richard says:
>  Being useful trumps making semantic sense. The web succeeded *because*
>  it conflates name and address. The web of data will succeed *because*
>  it conflates a thing and a web page about the thing.
>  <http://richard.cyganiak.de/>
>    a foaf:Document;
>    dc:title "Richard Cyganiak's homepage";
>    a foaf:Person;
>    foaf:name "Richard Cyganiak";
>    owl:sameAs <http://twitter.com/cygri>;
>    .
> I don't think that this is covered by any of the scenarios in Jonathan's document at:

My *intent* was that this situation would be covered by
  4.4 Coerce an information resource to what it defines its URI to name
but I guess the section name and description are not adequately evocative.

I actually don't object to this attitude too much; if people want to
opt out of machine inference who am I to say otherwise. They
themselves say they don't care about it (i.e. inference is best done
in some subtle and complicated way by people, not in a simple and
stupid way by computers). Should they decide to care in the future,
they can generate new RDF. It might be a lost opportunity and an
interoperability risk, but so it goes - the horse has been led to
water and it finds the water unpalatable.

>  http://www.w3.org/2001/tag/awwsw/issue57/20110531/
> In particular, I don't think the kind of 'punning' that we talked about (where different properties treat the given resource as being different kinds of thing) copes with the rdf:type property (shortened to 'a' in the Turtle) having two different values.

Correct. I think that in addition to expanding all the properties,
you'd also have to expand all the types, so that 'information resource
defining its URI to be a person' is a subclass of Person and so on. I
can add this to the presentation.

> Similarly, it's really unclear in the above example whether the owl:sameAs relates to the Person or the Document (until you find a description of <http://twitter.com/cygri>, which of course might be a resource that is both a Document and a Person itself).

I think it has to be the Document, at the level of sameAs, since
otherwise you get false equations between documents that describe the
same thing. That assumes an entailment regime that can lead you to
such conclusions... RDFS entailment can't, so as long as you stay away
from interoperation with OWL content, sameAs doesn't mean anything in
particular, and there's no risk of inconsistency.

This community ought to be perfectly happy with me saying the URI
refers to the information resource, since otherwise they'd be
admitting that the assignment *does* matter!

The thing to do is to get this community involved in specifying how to
write metadata, e.g. embedded license declarations for RDF files that
are about information resources, since now we have a perfectly good
way to do this, and its linguistic territory would be preempted by
some of the "take it at face value" proposals. Until we have
*complete* alternative designs to compare the real conversation can't

Thanks for the feedback. I'll try to adjust my mail filters to pick up
the discussion. Is there reference to the draft? The draft asks for
followup to www-tag.

Hoping to do one more round of revision, then ask on the other lists
for review, maybe in 2-3 weeks.


> Cheers,
> Jeni
> --
> Jeni Tennison
> http://www.jenitennison.com
Received on Monday, 13 June 2011 17:52:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:39 UTC