W3C home > Mailing lists > Public > semantic-web@w3.org > January 2007

Re: In RDF what is the best practice to represent data provenance (source)?

From: Danny Ayers <danny.ayers@gmail.com>
Date: Sun, 21 Jan 2007 13:54:47 +0100
Message-ID: <1f2ed5cd0701210454p7ed9429aoc782d1ddfe641f46@mail.gmail.com>
To: "Richard Cyganiak" <richard@cyganiak.de>
Cc: "Michael Schneider" <m_schnei@gmx.de>, "SWIG Web" <semantic-web@w3.org>, semantic_web@googlegroups.com
On 21/01/07, Richard Cyganiak <richard@cyganiak.de> wrote:

> So, I agree with ChrisR: If you feel the need to make statements
> about relationships, then maybe the modelling is not adequate to your
> use case, and the relationship ought to be turned into a resource of
> its own. Some related advice is found in [1].

A caveat on that -  it's pretty easy to mess up the modelling with n-ary
relations such as when talking about physical quantities, as highlighted by
timbl in [2].

Seems to me there are a couple of closely related but different notions
getting slightly blurred in this thread:

saying things about the single statement { subject, predicate, object }
saying things about the predicate in { subject, predicate, object }

Whatever's said about the predicate will generally apply wherever the
predicate is used (as a coarse analogy, they behave like static variables in
OO languages), but that may not be a problem. I believe I'm ok in having:

    a pet:Cat ;
    foaf:name "Neo" ;
    x:anotherNameForNeo "Bouncer" .

- where that predicate is specialised to the extent that it will only be
used with a specific subject individual (I promise). In itself it's a bit
obscure to be much use, but if:

x:anotherNameForNeo rdfs:subPropertyOf foaf:name .

then it may still be useful information in the greater scheme of things.


[1] http://www.w3.org/TR/2004/WD-swbp-n-aryRelations-20040721/

[2] http://lists.w3.org/Archives/Public/semantic-web/2006Sep/0117.html


Received on Sunday, 21 January 2007 12:54:52 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:44:59 UTC