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 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
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
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:
It was the FOAF folks who, initially, instead of using linked data,
used an Inverse Functional Property to uniquely identify
someone and then rdfs:seeAlso to find the data about them.
So any FOAF browser has to look up the seeAlso or they
don't follow any links.
So tabulator always
Hi Martin,
Martin Hepp wrote:
For my taste, using rdfs:seeAlso is perfectly valid (yet suboptimal,
because too unspecific), according to the RDFS spec:
http://www.w3.org/TR/rdf-schema/#ch_seealso
Quote: rdfs:seeAlso is an instance of rdf:Property that is used to
indicate a resource that
I'd be happy enough to see greater granularity for rdfs:seeAlso. I have
a use case where I want to say something like the uri has been minted
recently by a source that is not authoritative but that, if widely
adopted, could become so. Either way, it's worth noting that he and I
are talking
On Пнд, 2011-01-10 at 08:55 +, Phil Archer wrote:
However... a property should not imply any content type AFAIAC. That's
the job of the HTTP Headers. If software de-references an rdfs:seeAlso
object and only expects RDF then it should have a suitable accept
header. if the server can't
I know it is not the same, but I use a combination of the ORE aggregation and
the dc:format terms when I publish my presentation slides in different formats.
This is really relevant if you have a document that has different formats but
is the same logical 'thing'. What I do, roughly, is:
* [2011-01-10 08:55:59 +] Phil Archer phil.arc...@talis.com écrit:
] However... a property should not imply any content type AFAIAC. That's
] the job of the HTTP Headers. If software de-references an rdfs:seeAlso
] object and only expects RDF then it should have a suitable accept
] header.
Hmmm... no, sorry, William, I think we're destined to disagree.
On the Web in general, URIs don't, or certainly shouldn't, imply any
particular content type. It is perfectly valid, for example, to return a
PNG image from a URI that ends in .gif (awkward, unexpected, probably
silly, but not
On Sun, 2011-01-09 at 18:21 +0300, Vasiliy Faronov wrote:
Maybe it's time to define several specializations of rdfs:seeAlso with
stronger semantics?
Don't we already have enough of those?
s powder-s:describedby o .
# o provides some more information about o, often in a
# machine-readable
On Mon, 2011-01-10 at 08:55 +, Phil Archer wrote:
I'd be happy enough to see greater granularity for rdfs:seeAlso. I
have a use case where I want to say something like the uri has been
minted recently by a source that is not authoritative but that, if
widely adopted, could become so.
On 01/10/2011 01:45 PM, William Waites wrote:
* [2011-01-10 08:55:59 +] Phil Archer phil.arc...@talis.com écrit:
] However... a property should not imply any content type AFAIAC. That's
] the job of the HTTP Headers. If software de-references an rdfs:seeAlso
] object and only expects
Phil Archer wrote:
On the Web in general, URIs don't, or certainly shouldn't, imply any
particular content type.
They don't imply anything, they name things, and the thing that's named
can by all means be a representation with a specific mediatype, infact
this is by far the most common usage
On 10/01/2011 14:16, Nathan wrote:
Phil Archer wrote:
On the Web in general, URIs don't, or certainly shouldn't, imply any
particular content type.
They don't imply anything, they name things, and the thing that's named
can by all means be a representation with a specific mediatype, infact
On Пнд, 2011-01-10 at 13:04 +, Toby Inkster wrote:
Don't we already have enough of those?
Maybe we do, but then it's an issue of best practice consensus and
documentation. I think both publishers and consumers could benefit from
a broadly-agreed-upon list of common link types with
It is well to look at and make best practices for the things
we have if we don't
It was the FOAF folks who, initially, instead of using linked data,
used an Inverse Functional Property to uniquely identify
someone and then rdfs:seeAlso to find the data about them.
So any FOAF browser has to look
Thanks to everyone.
I fixed the issues with wdrs:describedby, used dcterms:hasFormat to link to
the PDF the #OriginalDescription section now shows.
txn:SpeciesOriginalDescription rdf:about=
http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription;
!-- Ideally, this should link to a resource in
On Птн, 2011-01-07 at 11:47 -0500, Tim Berners-Lee wrote:
Certainly. the tabulator follows rdfs:seeAlso and expects some terse
RDF.
and so would be crippled by any large file, and PDF would not of
course help it at all.
I take seeAlso as a fairly strong request to see the other thing, like
Duh, apologies... I meant dcterms:hasFormat rather than dcterms:hasVersion.
A related resource that is substantially the same as the pre-existing
described resource, but in another format.
http://www.dublincore.org/documents/dcmi-terms/#terms-hasFormat
Andy
--
Andy Powell
Research Programme
I was wondering if there is an existing predicate for linking to a PDF file?
I would like to incorporate a link between bibliographic reference
description and a URL to the location of a PDF of that document.
I had minted a predicate txn:hasPDFVersion, as demonstrated in this RDF
snippet. (Part
I see that Chris Gutteridge uses dc:hasPart for the ePrints RDF (eprints.org).
Eg:
http://eprints.ecs.soton.ac.uk/21681/
dc:format text/html;
dc:title HTML Summary of #21681 Consuming multiple linked data
sources: Challenges and Experiences;
foaf:primaryTopic
But that's me making a reasonable guess and getting on with it.
The EPrints document is a URI which represents a conceptual document
which consists of a number of actual files, eg. HTML+JPG+CSS, so the
dct:hasPart makes sense there. The main issue is how to relate the
document to the metadata
37 matches
Mail list logo
