W3C home > Mailing lists > Public > public-lod@w3.org > January 2009

Re: Granular dereferencing ( prop by prop ) using REST + LinkedData; Ideas?

From: Yves Raimond <yves.raimond@gmail.com>
Date: Mon, 5 Jan 2009 10:04:35 +0000
Message-ID: <82593ac00901050204j2fa9996bva547fb8690a62fa6@mail.gmail.com>
To: "Richard Cyganiak" <richard@cyganiak.de>
Cc: "Aldo Bucchi" <aldo.bucchi@gmail.com>, "public-lod@w3.org" <public-lod@w3.org>


> Remember that Aldo was looking for something that allows clients to make
> smart decisions about when to follow a link out of an RDF document. He was
> not looking for something to describe the contents of RDF datasets on a high
> level.

But my point is that it is the same problem: pointing clients in the
right direction, by expressing "this document holds more persons born
in NYC" or "this set of RDF triples holds Creative Commons records and
associated tags".

> More comments inline.
> On 4 Jan 2009, at 14:28, Yves Raimond wrote:
>>> Yves, the proposal above addresses this. There would be a triple:
>>>  :birthPlace link:subjectListProperty :morePersonsBornHere .
>>> This triple can be either directly in the :New_York description, or in
>>> the vocabulary (where you'd find it by dereferencing :morePersonsBornHere).
>>> The triple tells clients that they should follow the :morePersonsBornHere
>>> link if they are interested in :birthPlace triples. So, autodiscovery is
>>> solved.
>> Yes, it does work, but only for simple property lists. What about "find
>> here persons born in NYC between 1945 and 1975" ?
> I don't understand how you would express this using your proposal. From what
> I've seen, you propose to provide a characteristic example subgraph of the
> linked document. How can you express range constraints using a subgraph?

Indeed, that's a bad example - replace it by "find here persons born
in NYC and their birth date". It is easy enough to find examples that
involve more than just one property in the target document, e.g. "Find
here female scientists born in NYC", "Find here the phone numbers of
the Tabulator's developers", "Find the start time of chords on that
audio signal", "Find here my latitude and longitude and the time at
which they were captured"...

>>>> But perhaps the approach I proposed when we discussed the void:example
>>>> property could work, in exactly the same way as in [1].
>>>> In the representation of :New_York, we could write something like (in
>>>> N3):
>>>> <http://example.org/persons_nyc.rdf> void:example { :al_pacino
>>>> :birthPlace :New_York }.
>>> N3 formulae cannot be expressed in RDFa or RDF/XML. How would you
>>> serialize this in practice?
>> As in the post I refered to: you can point to
>> http://example.org/dataset-example.rdf where you put these example triples.
> Then, to decide if I want to follow any of those links, I need to do an
> extra HTTP request to retrieve a single-triple document. I think we can do
> better than that. I also don't like the idea of having to potentially
> provide an extra example document *per link*.
>>> As far as I can remember, all the examples that people have given could
>>> be addressed with a simple property-based approach. Has anyone mentioned a
>>> use case that goes beyond looking for a single property? If not, then what
>>> does the additional complexity of this proposal buy us in practice?
>> The example mentioned in my post uses more than one property, or the
>> exampl above.
> The example in your post was about describing datasets. I don't see how it
> makes sense in the context of splitting up the RDF description of an
> individual resource.

As mentioned above, it is the same problem - providing clues to a
client. IMHO, expressing "This RDF document holds persons born in NYC
and their birth date" is a similar problem as expressing "This dataset
holds Creative Commons records".


>>> (I note that the situation here is different from what you described in
>>> [1]. There it was about annotations on a dataset level. Here it is about
>>> annotating links that occur within many or all individual documents of a
>>> dataset.)
>> A RDF document is a dataset, and can be described as such :-)
> This isn't about what *can* be done, it's about what's *useful* to do.
> I think that you have an interesting approach to describing RDF datasets,
> but I don't think that it is a good solution to the problem of hinting at
> the content that is available behind an RDF link.
> Best,
> Richard
>>>> [1]
>>>> http://blog.dbtune.org/post/2008/06/12/Describing-the-content-of-RDF-datasets
Received on Monday, 5 January 2009 10:05:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:15:54 UTC