Hi Nathan:
There are other ways of looking at this, remembering we're in the
realm of machine readable information and the context of RDF.
rdfs:seeAlso is used to indicate a resource O which may provide
additional information about the resource S - information in this
context being rdf,
One obvious solution is to use an extra triple to indicate that the URL
is a serialisation of some triples. eg.
rdf:Description rdf:about=...URI-X...
rdfs:labelthe name of the thing for which more data is
available/rdfs:label
rdfs:seeAlso
rdf:Description rdf:about=...RDF-URL...
Martin seems to be fighting a lone battle, but fwiw I'll add my +1 to
his comments.
I do take the point that, in context, it's really nice if rdfs:seeAlso
gives a URI that provides more data in RDF and many applications will
make that assumption. But to /rely/ on that every time seems at odds
Phil Archer wrote:
Martin seems to be fighting a lone battle, but fwiw I'll add my +1 to
his comments.
I do take the point that, in context, it's really nice if rdfs:seeAlso
gives a URI that provides more data in RDF and many applications will
make that assumption. But to /rely/ on that
On Чтв, 2011-01-13 at 11:04 +, Phil Archer wrote:
Describing a URI with further triples is good, nothing wrong with that,
but to use that to decide whether or not to dereference an rdfs:seeAlso
URI means looking for a description of the linked resource and then
acting accordingly. That
Martin Hepp wrote:
Hi Nathan:
There are other ways of looking at this, remembering we're in the
realm of machine readable information and the context of RDF.
rdfs:seeAlso is used to indicate a resource O which may provide
additional information about the resource S - information in this
wow, typo's to the point of being incomprehensible! fixed:
Nathan wrote:
Martin Hepp wrote:
Hi Nathan:
There are other ways of looking at this, remembering we're in the
realm of machine readable information and the context of RDF.
rdfs:seeAlso is used to indicate a resource O which may
On Thu, 2011-01-13 at 06:29 -0500, Tim Berners-Lee wrote:
This is the Linked Open Data list.
The Linked Data world is a well-defined bit of engineering.
It has co-opted the rdf:seeAlso semantics of if you are looking up x load y
from the much
earlier FOAF work.
Where is this
On Thu, 2011-01-13 at 11:43 +, Nathan wrote:
linked data is not some term for data with links, it's an engineered
protocol which has constraints and requirements to make the whole thing
work.
Where is the spec for this engineered protocol and where in that spec
does it redefine
On 01/13/2011 01:09 PM, Dave Reynolds wrote:
On Thu, 2011-01-13 at 06:29 -0500, Tim Berners-Lee wrote:
This is the Linked Open Data list.
The Linked Data world is a well-defined bit of engineering.
It has co-opted the rdf:seeAlso semantics of if you are looking up x load
y from the much
Dave Reynolds wrote:
On Thu, 2011-01-13 at 11:43 +, Nathan wrote:
linked data is not some term for data with links, it's an engineered
protocol which has constraints and requirements to make the whole thing
work.
Where is the spec for this engineered protocol and where in that spec
does
Hi Vasiliy,
I think it comes down to the application. Whenever you dereference a
URI, your application is almost certainly going to want some types of
content and not others. You're bound to do various bits of sniffing and
testing to see whether what you're going to get back is something you
On Чтв, 2011-01-13 at 12:32 +, Phil Archer wrote:
What I'm concerned about is the implication that, S rdfs:seeAlso O
implies that O is RDF that somehow doesn't need to be tested before
you throw it at a parser. That seems dangerous at best.
I fully agree, and therefore we need other means
Dave Reynolds wrote:
On Thu, 2011-01-13 at 06:29 -0500, Tim Berners-Lee wrote:
One *can* argue that the RDFS spec is definitive, and it is very loose in its
definition.
Loose in the sense of allowing a range of values but as a specification
it is unambiguous in this case, as Martin has
On 2011-01 -13, at 07:23, Dave Reynolds wrote:
Where is the spec for this engineered protocol and where in that spec
does it redefine rdfs:seeAlso?
[I believe I have reasonably decent understanding of, and experience
with, linked data. It is a useful set of conventions and practices
be strict when sending and tolerant when receiving [1]
I guess, we shouldn't expect to much ;)
Cheers,
Bob
[1] http://tools.ietf.org/html/rfc1958
As there seems to be some interest in this issue, I created a page on
the W3C SW wiki:
http://www.w3.org/2001/sw/wiki/Linking_patterns
to keep track of the situation with the current practices.
Additions and fixes are very welcome.
--
Vasiliy Faronov
On 1/13/11 8:44 AM, Bob Ferris wrote:
be strict when sending and tolerant when receiving [1]
I guess, we shouldn't expect to much ;)
Cheers,
Bob
[1] http://tools.ietf.org/html/rfc1958
Bob,
That's the very reason why we sponge (retrieve) and transform
rdfs:seeAlso property values in
On 1/13/11 6:43 AM, Nathan wrote:
The data part of linked data is not generic, machine accessible !=
machine understandable, and that's what this is all about.
linked data is not some term for data with links, it's an engineered
protocol which has constraints and requirements to make the
On 1/13/11 6:04 AM, Phil Archer wrote:
Martin seems to be fighting a lone battle, but fwiw I'll add my +1 to
his comments.
+1 for Martin's comments. Assuming my other comments didn't make this
obvious :-)
I do take the point that, in context, it's really nice if rdfs:seeAlso
gives a URI
Hi Tim:
On 13.01.2011, at 12:29, Tim Berners-Lee wrote:
On 2011-01 -13, at 05:10, Martin Hepp wrote:
I don't buy in to restricting the meaning of data in the context
of RDF to RDF data.
You can define data however you like for the purpoes of an
argument, but with
nothing to do with how
On 1/13/11 6:29 AM, Tim Berners-Lee wrote:
The protocol deployed in FOAF and linked data clients requires it to be RDF.
Tim,
Assuming we are discussing HTTP based Linked Data in a protocol sense,
doesn't client side content negotiation come into the mix? The client
knows what it wants, so
Hi Kinglsey,
Kingsley Idehen wrote:
When our engine describes entities it can publish these descriptions
using variety of structured data formats that include RDF. The same
thing applies on the data consumption side. Basically, RDF formats are
options re. Linked Data (the concept).
A
IMHO (i) Martin is right regarding the (interpretation of the) definition of
rdfs:seeAlso (ii) Tim is right regarding the practical issues thrown up by use
of the wider interpretation of the range of rdfs:seeAlso.
The question is: how to fix this for the community in general - maybe we should
On 1/13/11 12:04 PM, Nathan wrote:
Hi Kinglsey,
Kingsley Idehen wrote:
When our engine describes entities it can publish these descriptions
using variety of structured data formats that include RDF. The same
thing applies on the data consumption side. Basically, RDF formats
are options re.
On 1/13/11 12:17 PM, David Booth wrote:
FWIW, I also agree with Martin's comments. It is the client's
responsibility to decide what to retrieve and accept:
1. The definition of rdfs:seeAlso very clearly states that When such
representations may be retrieved, no constraints are placed on the
On 1/13/11 8:36 AM, John F. Sowa wrote:
Folks,
John,
Great comments. I've cc'd in the LOD community mailing list as these
sentiments have some bearing on an ongoing conversation thread [1].
Links:
1. http://lists.w3.org/Archives/Public/public-lod/2011Jan/
Others: please read on
We
(related to seeAlso discussion) If I resolve a URI /foo and it gives a
301 seeOther to /bar then I should be able to infer a triple from that,
I think?
At the very least, /foo rdfs:seeAlso /bar .
Resolvable URIs are a cool hack, but I think the system would make more
sense if they were an
28 matches
Mail list logo
