Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Martin Hepp]

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, information for the machine - so we can say that  
if O points to a resource that doesn't contain any information at  
all (no rdf, or isn't the subject of any statements) then we've  
created a meaningless statement, it may as well be { S rdfs:seeAlso  
[] }


One could easily suggest that it's good for RDF Schema properties to  
have some use in RDF, and thus that if rdfs:seeAlso is used in a  
statement, that it should point to some information, some rdf for  
the machine, otherwise it's a bit of a pointless property.


Given the above, we could take the meaning of the sentence no  
constraints are placed on the format of those representations and  
assert that this simply means that RDF/XML is not required, and that  
any RDF format can be used.


I don't buy in to restricting the meaning of data in the context of  
RDF to RDF data. If the subject or object of RDF triples can be any  
Web resource (information and non-information resource), then the  
range of rdfs:seeAlso should also include information resources (i.e.,  
data) of a variety of conceptual and syntactic forms.


And PDF, HTML without RDFa as well as images clearly qualify as data.  
They are also clearly machine-accessible. If you are still not  
convinced: What about CSV files or text files containing ACE  
(controlled English), or OData / GData?


By the way, the problem of having to load huge amounts of data  
following rdfs:seeAlso is not limited to PDFs - even obeying Tim's  
proposal means there could be huge RDF graphs linked to via  
rdfs:seeAlso, and that is of course conceptually perfectly okay.


After all, rdfs:seeAlso is not  
rdfs:linkToASmallChunkOfVeryRelatedDateInRDF ;-) Data management and  
data quality heuristics should not be solved at the conceptual level.  
If old clients employ outdated heuristics, those clients should update  
their heuristics, IMO.


Best
Martin


On 12.01.2011, at 16:13, Nathan wrote:


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 might provideadditional information  
about the subject resource.

A triple of the form:
S rdfs:seeAlso O
states that the resource O may provide additional information about  
S. It may be possible to retrieve representations of O from the  
Web, but this is not required. When such representations may be  
retrieved, ***no constraints are placed on the format of those  
representations***.




Generally it appears to me that rdfs:seeAlso is a property for a  
machine to follow in order to get more information, and that much of  
the usage mentioned in this thread requires a property which informs  
a human that they may want to check resource O for more information  
- essentially something similar to a hyperlink in a html document  
with no @rel value.


Best,

Nathan

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Christopher Gutteridge]

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...
   rdf:type 
rdf:resource=http://purl.org/xtypes/Document-RDFSerialisation; /

 /rdf:Description
   /rdfs:seeAlso
 /rdf:Description


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 
context being rdf, information for the machine - so we can say that 
if O points to a resource that doesn't contain any information at all 
(no rdf, or isn't the subject of any statements) then we've created a 
meaningless statement, it may as well be { S rdfs:seeAlso [] }


One could easily suggest that it's good for RDF Schema properties to 
have some use in RDF, and thus that if rdfs:seeAlso is used in a 
statement, that it should point to some information, some rdf for 
the machine, otherwise it's a bit of a pointless property.


Given the above, we could take the meaning of the sentence no 
constraints are placed on the format of those representations and 
assert that this simply means that RDF/XML is not required, and that 
any RDF format can be used.


I don't buy in to restricting the meaning of data in the context of 
RDF to RDF data. If the subject or object of RDF triples can be any 
Web resource (information and non-information resource), then the 
range of rdfs:seeAlso should also include information resources (i.e., 
data) of a variety of conceptual and syntactic forms.


And PDF, HTML without RDFa as well as images clearly qualify as data. 
They are also clearly machine-accessible. If you are still not 
convinced: What about CSV files or text files containing ACE 
(controlled English), or OData / GData?


By the way, the problem of having to load huge amounts of data 
following rdfs:seeAlso is not limited to PDFs - even obeying Tim's 
proposal means there could be huge RDF graphs linked to via 
rdfs:seeAlso, and that is of course conceptually perfectly okay.


After all, rdfs:seeAlso is not 
rdfs:linkToASmallChunkOfVeryRelatedDateInRDF ;-) Data management and 
data quality heuristics should not be solved at the conceptual level. 
If old clients employ outdated heuristics, those clients should update 
their heuristics, IMO.


Best
Martin


On 12.01.2011, at 16:13, Nathan wrote:


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 might provideadditional information 
about the subject resource.

A triple of the form:
S rdfs:seeAlso O
states that the resource O may provide additional information about 
S. It may be possible to retrieve representations of O from the Web, 
but this is not required. When such representations may be 
retrieved, ***no constraints are placed on the format of those 
representations***.




Generally it appears to me that rdfs:seeAlso is a property for a 
machine to follow in order to get more information, and that much of 
the usage mentioned in this thread requires a property which informs 
a human that they may want to check resource O for more information - 
essentially something similar to a hyperlink in a html document with 
no @rel value.


Best,

Nathan






--
Christopher Gutteridge -- http://id.ecs.soton.ac.uk/person/1248

You should read the ECS Web Team blog: http://blogs.ecs.soton.ac.uk/webteam/

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Phil Archer]

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 
with the, AIUI fundamental notion, that a URI is an identifier and no more.


I'd say that if you see an rdfs:seeAlso property, sure, send an HTTP 
request, but do it with a suitable accept header. If you get a 200, 
great, add the data, but be ready to deal with a 406 (I've got it but 
not in the format you have specified in your request).


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 sounds like a relatively heavy bit of 
processing that HTTP kind of takes care of for you.


Phil.

On 13/01/2011 10:10, 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
context being rdf, information for the machine - so we can say that
if O points to a resource that doesn't contain any information at
all (no rdf, or isn't the subject of any statements) then we've
created a meaningless statement, it may as well be { S rdfs:seeAlso
[] }

One could easily suggest that it's good for RDF Schema properties to
have some use in RDF, and thus that if rdfs:seeAlso is used in a
statement, that it should point to some information, some rdf for
the machine, otherwise it's a bit of a pointless property.

Given the above, we could take the meaning of the sentence no
constraints are placed on the format of those representations and
assert that this simply means that RDF/XML is not required, and that
any RDF format can be used.


I don't buy in to restricting the meaning of data in the context of
RDF to RDF data. If the subject or object of RDF triples can be any
Web resource (information and non-information resource), then the
range of rdfs:seeAlso should also include information resources (i.e.,
data) of a variety of conceptual and syntactic forms.

And PDF, HTML without RDFa as well as images clearly qualify as data.
They are also clearly machine-accessible. If you are still not
convinced: What about CSV files or text files containing ACE
(controlled English), or OData / GData?

By the way, the problem of having to load huge amounts of data
following rdfs:seeAlso is not limited to PDFs - even obeying Tim's
proposal means there could be huge RDF graphs linked to via
rdfs:seeAlso, and that is of course conceptually perfectly okay.

After all, rdfs:seeAlso is not
rdfs:linkToASmallChunkOfVeryRelatedDateInRDF ;-) Data management and
data quality heuristics should not be solved at the conceptual level.
If old clients employ outdated heuristics, those clients should update
their heuristics, IMO.

Best
Martin


On 12.01.2011, at 16:13, Nathan wrote:


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 might provide additional information
about the subject resource.
A triple of the form:
S rdfs:seeAlso O
states that the resource O may provide additional information about
S. It may be possible to retrieve representations of O from the
Web, but this is not required. When such representations may be
retrieved, ***no constraints are placed on the format of those
representations***.




Generally it appears to me that rdfs:seeAlso is a property for a
machine to follow in order to get more information, and that much of
the usage mentioned in this thread requires a property which informs
a human that they may want to check resource O for more information
- essentially something similar to a hyperlink in a html document
with no @rel value.

Best,

Nathan





Please consider the environment before printing this email.

Find out more about Talis at http://www.talis.com/
shared innovation™

Any views or personal opinions expressed within this email may not be
those of Talis Information Ltd or its employees. The content of this
email message and any files that may be attached are confidential, and
for the usage of the intended recipient only. If you are not the
intended recipient, then please return this message to the sender and
delete it. Any use of this e-mail by an unauthorised recipient is
prohibited.

Talis Information Ltd is a member of the Talis Group of companies and is
registered in England No 3638278 with its registered office at Knights
Court, Solihull Parkway, Birmingham Business 

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Nathan]

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 every time seems at odds 
with the, AIUI fundamental notion, that a URI is an identifier and no more.


I'd say that if you see an rdfs:seeAlso property, sure, send an HTTP 
request, but do it with a suitable accept header. If you get a 200, 
great, add the data, but be ready to deal with a 406 (I've got it but 
not in the format you have specified in your request).


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 sounds like a relatively heavy bit of 
processing that HTTP kind of takes care of for you.


So then if you use { S rdfs:seeAlso O } then O is used with a 
dereferencable http/https scheme URI which deferences to an information 
resource with a representation in any format which may or may not have 
something to do with the subject of the triple.


Apologies, previously I'd thought the O was a name which you'd look for 
in the subject position of other statements. (as in, any RDF URI 
Reference, any scheme, or any blank node).


Best,

Nathan

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Vasiliy Faronov]

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 sounds like a relatively heavy bit of 
 processing that HTTP kind of takes care of for you.

Phil, how then do you propose to deal with the following:

- RDFa
- web servers that (in full compliance with the spec[1]) ignore the Accept
  header and just send 200 with the only representation they have (try
  HEAD http://dev.w3.org/html5/spec/Overview.html with Accept:
  application/rdf+xml, pay attention to the Content-Length returned)

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.7

-- 
Vasiliy Faronov

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Nathan]

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 
context being rdf, information for the machine - so we can say that if 
O points to a resource that doesn't contain any information at all (no 
rdf, or isn't the subject of any statements) then we've created a 
meaningless statement, it may as well be { S rdfs:seeAlso [] }


One could easily suggest that it's good for RDF Schema properties to 
have some use in RDF, and thus that if rdfs:seeAlso is used in a 
statement, that it should point to some information, some rdf for 
the machine, otherwise it's a bit of a pointless property.


Given the above, we could take the meaning of the sentence no 
constraints are placed on the format of those representations and 
assert that this simply means that RDF/XML is not required, and that 
any RDF format can be used.


I don't buy in to restricting the meaning of data in the context of 
RDF to RDF data. If the subject or object of RDF triples can be any 
Web resource (information and non-information resource), then the range 
of rdfs:seeAlso should also include information resources (i.e., data) 
of a variety of conceptual and syntactic forms.



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 whole thing 
work.


We cannot build a web of data (machine understandable dereferencable 
data) without these constraints.


And PDF, HTML without RDFa as well as images clearly qualify as data. 
They are also clearly machine-accessible. If you are still not 
convinced: What about CSV files or text files containing ACE (controlled 
English), or OData / GData?


I'm far from convinced, and have discussed this at length w/ Kingsley 
and others.


A three column CSV is not linked data, yes you can take linked data and 
format it in a 3 column CSV, and yes with some out of band knowledge 
about a particular CSV you can /convert it to/ to RDF, this is not true 
for /all/ csv files and only ever works if you have prior knowledge of 
the particular file being considered - that is to say, we can't build a 
web of data by publishing csv files, or traverse a web of data by 
setting our Accept headers to text/csv and hoping that any data 
received matches our three column constrains (and hoping again when it 
does that it actually is something we can use and not just x x x). The 
same is true of text files containing ACE.


As for OData and GData, sure it is more linky, and looks more like RDF, 
but it's not, and the rabbit hole runs much deeper with these two but 
essentially it's the difference between people making open world 
semantics and making statements they intended to make, and people having 
RDF gleaned from data they've put out which may take on a different 
meaning when in RDF other than that which was intended.


Ultimately, a big part of the linked data protocol is having machine 
readable and understandable data in negotiable well defined formats 
available at dereferencable http and https scheme URIs - if you drop any 
one of those elements it's simply not linked data


Perhaps this points to a need to standardize Linked Data as a protocol.

Best,

Nathan

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Nathan]

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 provide 
additional information about the resource S - information in this 
context being rdf, information for the machine - so we can say that 
if O points to a resource that doesn't contain any information at all 
(no rdf, or isn't the subject of any statements) then we've created a 
meaningless statement, it may as well be { S rdfs:seeAlso [] }


One could easily suggest that it's good for RDF Schema properties to 
have some use in RDF, and thus that if rdfs:seeAlso is used in a 
statement, that it should point to some information, some rdf for 
the machine, otherwise it's a bit of a pointless property.


Given the above, we could take the meaning of the sentence no 
constraints are placed on the format of those representations and 
assert that this simply means that RDF/XML is not required, and that 
any RDF format can be used.


I don't buy in to restricting the meaning of data in the context of 
RDF to RDF data. If the subject or object of RDF triples can be any 
Web resource (information and non-information resource), then the 
range of rdfs:seeAlso should also include information resources (i.e., 
data) of a variety of conceptual and syntactic forms.



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 whole thing 
work.


We cannot build a web of data (machine understandable dereferencable 
data) without these constraints.


And PDF, HTML without RDFa as well as images clearly qualify as data. 
They are also clearly machine-accessible. If you are still not 
convinced: What about CSV files or text files containing ACE 
(controlled English), or OData / GData?


I'm far from convinced, and have discussed this at length w/ Kingsley 
and others.


A three column CSV is not linked data, yes you can take linked data and 
format it in a 3 column CSV, and yes with some out of band knowledge 
about a particular CSV you can /convert it to/ to RDF, this is not true 
for /all/ csv files and only ever works if you have prior knowledge of 
the particular file being considered - that is to say, we can't build a 
web of data by publishing csv files, or traverse a web of data by 
setting our Accept headers to text/csv and hoping that any data 
received matches our three column constraints (and hoping again when it 
does that it actually is something we can use and not just x x x). The 
same is true of text files containing ACE.


As for OData and GData, sure it is more linky, and looks more like RDF, 
but it's not, and the rabbit hole runs much deeper with these two, but 
essentially it's the difference between people making statements with

open world semantics and people having RDF gleaned from data they've put
out which may take on a different meaning when in RDF, other than that
which was intended.

Ultimately, a big part of the linked data protocol is having machine 
readable and understandable data in negotiable well defined formats 
available at dereferencable http and https scheme URIs - if you drop any 
one of those elements it's simply not linked data


Perhaps this points to a need to standardize Linked Data as a protocol.

Best,

Nathan

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Dave Reynolds]

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 rdfs:seeAlso?

[I believe I have reasonably decent understanding of, and experience
with, linked data. It is a useful set of conventions and practices
building on some underlying formal specifications. However, I'm not
aware of those practices being so universally agreed and formally
codified as to justify some of the claims being made in this thread.]

Dave

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Nathan]

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 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
building on some underlying formal specifications. However, I'm not
aware of those practices being so universally agreed and formally
codified as to justify some of the claims being made in this thread.]


Hence my comment:

Perhaps this points to a need to standardize Linked Data as a protocol.

Best,

Nathan

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Phil Archer]

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 
can process/use. If you follow an rdfs:seeAlso and get back something 
that you can use, whatever format its in, well, use it. 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.


Now, things like foaf:isPrimaryTopicOf and other predicates may well be 
better choices than rdfs:seeAlso for linking to non-RDF sources, but to 
err is human. As more people publish triples, be they in RDFa, Turtle 
RDF/XML or whatever, there will be errors and we'll have to handle them. 
What I would feel very uncomfortable with is the idea that if you 
include S rdfs:seeAlso O and O is not RDF then that action alone might 
be seen as meaning the data is invalid - which I think is way too strong 
an inference to make.


Phil

On 13/01/2011 11:36, Vasiliy Faronov wrote:

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 sounds like a relatively heavy bit of
processing that HTTP kind of takes care of for you.


Phil, how then do you propose to deal with the following:

- RDFa
- web servers that (in full compliance with the spec[1]) ignore the Accept
   header and just send 200 with the only representation they have (try
   HEAD http://dev.w3.org/html5/spec/Overview.html with Accept:
   application/rdf+xml, pay attention to the Content-Length returned)

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.7



--


Phil Archer
Talis Systems Ltd
Web: http://www.talis.com
Tel: +44 1473 434770
Twitter: philarcher1
LinkedIn: http://uk.linkedin.com/in/philarcher
Personal: http://philarcher.org

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Vasiliy Faronov]

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 of telling apart links
to useful (in our context, RDF) data from non-useful (non-RDF).

You propose, as far as I understand, that standard HTTP conneg is
sufficient for this, but to me it seems quite limited. On the other
hand, RDF itself allows for this sort of hints to be added very easily.
All it takes is a common vocabulary that both publishers and consumers
would understand and agree to.

-- 
Vasiliy Faronov

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Tim Berners-Lee]

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
 building on some underlying formal specifications. However, I'm not
 aware of those practices being so universally agreed and formally
 codified as to justify some of the claims being made in this thread.]
 
 Dave
 



Well, I looked.

The current spec  http://xmlns.com/foaf/spec/  says: (my emphasis)

Perhaps the most important use of knows is, *alongside the rdfs:seeAlso 
property*, to connect FOAF files together. Taken alone, a FOAF file is somewhat 
dull. But linked in with 1000s of other FOAF files it becomes more interesting, 
with each FOAF file saying a little more about people, places, documents, 
things... By mentioning other people (via knows or other relationships), *and 
by providing an rdfs:seeAlso link to their FOAF file*, you can make it easy for 
FOAF indexing tools ('scutters') to find your FOAF and the FOAF of the people 
you've mentioned. And the FOAF of the people they mention, and so on. This 
makes it possible to build FOAF aggregators without the need for a centrally 
managed directory of FOAF files...

So here is seeAlso being set up as the target for crawlers.
This clearly breaks when rdfs:seeAlso links go to a big PDF file.

The old FOAF spec is not easy to find. Previous version links go back to
http://xmlns.com/foaf/spec/20050403.html
which has copyright Copyright © 2000-2004 Dan Brickley and Libby Miller 
This is all new flavor in which the document is generated from small documents 
one about
each term in the vocabulary and so does not have the general description in 
which the seeAlso
stuff was.

The RDFS spec
http://www.w3.org/TR/rdf-schema/#ch_seealso of course doesn't not define it at 
all.

On the client side, the first Tabulator paper in 2006
http://swui.semanticweb.org/swui06/papers/Berners-Lee/Berners-Lee.pdf
has a section 4.2 

4.2What to dereference

The Tabulator automatically and recursively loads the ontology file for any 
term used as a predicate or type (object of rdf:type), recursively (ontological 
closure).
Here we consider a user is browsing or querying information about a subject x. 
When the user opens up a tab asking for information on x, or a query is being 
resolved and x is the subject or object of a statement in the query pattern, or 
is x is bound to a variable during the query, then x is looked up. Looking up 
currently involves:

– looking up the URI of x itself, and also
 – looking up any y where the store includes the fact that { x rdfs:seeAlso y}.

The latter is necessary for the Friend of A Friend (FOAF) conventions. It is 
currently not widely used elsewhere. It can, be useful, however, to allow a 
third party to point out that information is available, when the owner of the 
URI itself has not, for whatever reason, included that information when x is 
dereferenced. We implemented the dereferencing of URIs using the HTTP protocol. 
Suc- cessful dereferencing of an HTTP URI gives a status code and either a 
redirection (status 300-303) or (status 200) a representation consisting of 
content bytes and metadata.


Since then, I have certainly used seeAlso as a way to distribute information 
between several files,
to be able to have a read-only file pull in a machine-editable file, and so on.

I suspect other client libraries have used this algorithm. 

At the time you certainly couldn't navigate the FOAF graph, which was then
the leading and dominant linked data graph remember, without that algorithm.
It may be that things have changed and we should turn off seeAlso handling in 
our clients
and see what breaks.  Or better, if someone could crawl a significant chunk of 
the 
FOAF graph (not all one site!) to see how many of the links out there rely on 
it.

If small, then we could migrate the clients to a # link:pleaseLoadData y new
property or something.

Or maybe FOAF people know the answer to this question.

Tim

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Bob Ferris]

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

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Vasiliy Faronov]

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

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Kingsley Idehen]

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 our clients, if need be. Basically, we 
use content negotiation algorithms to specify what we want, and then 
transform if we don't receive a structured data representation of a 
description graph, in desired format i.e., RDF family of formats, and a 
few others we know how to handle.


The need to transform data to reflect the sense of the data consumer 
is something we all have to live with (IMHO). If an app has a linked 
data sense (I like Nathan's phrase btw), then said app should take on 
the burden of transformation re. compatibility with its sense, post 
negotiated data retrieval.



--

Regards,

Kingsley Idehen 
President  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Kingsley Idehen]

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 whole 
thing work.


Then it should be: Linked Structured Data :-)

Then we stimulate the following sense: machine readable data that's 
defined and constrained by a schema.


We cannot build a web of data (machine understandable dereferencable 
data) without these constraints. 


Yes, but the moniker has to be clear enough to stimulate the right 
senses. If Structure matters, it has to be part of the moniker, 
otherwise, we have a grey area (which is the case today) that's best 
resolved via transformation handled on the client side inline, with its 
particular senses etc..



--

Regards,

Kingsley Idehen 
President  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Kingsley Idehen]

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 that provides more data in RDF and many applications will 
make that assumption. But to /rely/ on that every time seems at odds 
with the, AIUI fundamental notion, that a URI is an identifier and no 
more.


Yes, its a Super Key (in context of Linked Data), it can Lift (GET) 
Things up, and PUT Things down [1] .


I'd say that if you see an rdfs:seeAlso property, sure, send an HTTP 
request, but do it with a suitable accept header. If you get a 200, 
great, add the data, but be ready to deal with a 406 (I've got it but 
not in the format you have specified in your request).

+1

Yep, as per my comments about sponging.

[SNIP]

Links:

1. http://www.youtube.com/watch?v=M-cpojkILO0 -- Nice URI Ad. 
Identifiers are Identifiers, URIs re. Linked Data are just Identifiers 
on Steroids


Kingsley




Phil.

On 13/01/2011 10:10, 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
context being rdf, information for the machine - so we can say that
if O points to a resource that doesn't contain any information at
all (no rdf, or isn't the subject of any statements) then we've
created a meaningless statement, it may as well be { S rdfs:seeAlso
[] }

One could easily suggest that it's good for RDF Schema properties to
have some use in RDF, and thus that if rdfs:seeAlso is used in a
statement, that it should point to some information, some rdf for
the machine, otherwise it's a bit of a pointless property.

Given the above, we could take the meaning of the sentence no
constraints are placed on the format of those representations and
assert that this simply means that RDF/XML is not required, and that
any RDF format can be used.


I don't buy in to restricting the meaning of data in the context of
RDF to RDF data. If the subject or object of RDF triples can be any
Web resource (information and non-information resource), then the
range of rdfs:seeAlso should also include information resources (i.e.,
data) of a variety of conceptual and syntactic forms.

And PDF, HTML without RDFa as well as images clearly qualify as data.
They are also clearly machine-accessible. If you are still not
convinced: What about CSV files or text files containing ACE
(controlled English), or OData / GData?

By the way, the problem of having to load huge amounts of data
following rdfs:seeAlso is not limited to PDFs - even obeying Tim's
proposal means there could be huge RDF graphs linked to via
rdfs:seeAlso, and that is of course conceptually perfectly okay.

After all, rdfs:seeAlso is not
rdfs:linkToASmallChunkOfVeryRelatedDateInRDF ;-) Data management and
data quality heuristics should not be solved at the conceptual level.
If old clients employ outdated heuristics, those clients should update
their heuristics, IMO.

Best
Martin


On 12.01.2011, at 16:13, Nathan wrote:


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 might provide additional information
about the subject resource.
A triple of the form:
S rdfs:seeAlso O
states that the resource O may provide additional information about
S. It may be possible to retrieve representations of O from the
Web, but this is not required. When such representations may be
retrieved, ***no constraints are placed on the format of those
representations***.




Generally it appears to me that rdfs:seeAlso is a property for a
machine to follow in order to get more information, and that much of
the usage mentioned in this thread requires a property which informs
a human that they may want to check resource O for more information
- essentially something similar to a hyperlink in a html document
with no @rel value.

Best,

Nathan





Please consider the environment before printing this email.

Find out more about Talis at http://www.talis.com/
shared innovation™

Any views or personal opinions expressed within this email may not be
those of Talis Information Ltd or its employees. The content of this
email message and any files that may be attached are confidential, and
for the usage of the intended recipient only. If you are not the
intended recipient, then please return this message to the sender and
delete it. Any use of this e-mail by an unauthorised recipient is
prohibited.

Talis Information Ltd is a member of the Talis Group of companies and 

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Martin Hepp]

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 when looking up x and finding x see:also y will
load y.  So must any similar client or any crawler.

So there is a lot of existing use we would throw away if we
allowed rdfs:seeAlso for pointing to things which do not
provide data. (It isn't the question of conneg or mime type,
that is a red herring. it is whether there is machine-redable
standards-based stuff about x).


Are you saying that we should NOT use rdfs:seeAlso to point

a) from conceptual entities to Web pages (regular HTML, no RDFa)  
describing them, nor

b) from conceptual entities to images and logos depicting them?

Historically, we had always suggested a) for GoodRelations recipes and  
turned to recommending foaf:page instead only recently. The main  
reason to use rdfs:seeAlso initially was that it did not require  
anybody to commit to a second ontology.


Also, b) has been used in many cases in parallel to Yahoo's  
media:image property in the context of Yahoo Searchmonkey. As of  
today, Yahoo still recommends to use both, see


   http://developer.search.yahoo.com/help/objects/product

span rel=rdfs:seeAlso media:image
  img src=http://example.com/product.jpg/
  /span

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 might provideadditional information about  
the subject resource.


A triple of the form:

S rdfs:seeAlso O

states that the resource O may provide additional information about S.  
It may be possible to retrieve representations of O from the Web, but  
this is not required. When such representations may be retrieved,  
***no constraints are placed on the format of those representations***.


So I tend to recommend that instead of discouraging the use of  
rdfs:seeAlso, clients consuming rdfs:seeAlso should take measures to  
not load unneeded payload. For example, they could limit such behavior  
to a context of certain FOAF elements or fetch the headers first and  
skip all PDF and images content. In the case of HTML, it will be  
difficult to tell ex ante whether it actually contains useful RDFa  
payload. The DOCTYPE and other header meta-data alone will be a bad  
indicator.


Best wishes

Martin





On 10.01.2011, at 16:01, Tim Berners-Lee wrote:


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 up the seeAlso  or they
don't follow any links.

So tabulator always when looking up x and finding x see:also y will
load y.  So must any similar client or any crawler.

So there is a lot of existing use we would throw away if we
allowed rdfs:seeAlso for pointing to things which do not
provide data. (It isn't the question of conneg or mime type,
that is a red herring. it is whether there is machine-redable
standards-based stuff about x).

Further, we should not make any weaker properties like  
seeDocumentation

subproperties of see:Also, or they would imply
We maybe need a very weak top property like

mayHaveSomeKindOfInfoAboutThis

to be the superProperty of all the others.

One things which could be stronger than seeAlso is definedBy if it
is normally used for data, to point to the definitive ontology.
That would then imply seeAlso.

Tim

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Nathan]

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 might provideadditional information about 
the subject resource.


A triple of the form:

S rdfs:seeAlso O

states that the resource O may provide additional information about S. 
It may be possible to retrieve representations of O from the Web, but 
this is not required. When such representations may be retrieved, ***no 
constraints are placed on the format of those representations***.


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, 
information for the machine - so we can say that if O points to a 
resource that doesn't contain any information at all (no rdf, or isn't 
the subject of any statements) then we've created a meaningless 
statement, it may as well be { S rdfs:seeAlso [] }


One could easily suggest that it's good for RDF Schema properties to 
have some use in RDF, and thus that if rdfs:seeAlso is used in a 
statement, that it should point to some information, some rdf for the 
machine, otherwise it's a bit of a pointless property.


Given the above, we could take the meaning of the sentence no 
constraints are placed on the format of those representations and 
assert that this simply means that RDF/XML is not required, and that any 
RDF format can be used.


Generally it appears to me that rdfs:seeAlso is a property for a machine 
to follow in order to get more information, and that much of the usage 
mentioned in this thread requires a property which informs a human that 
they may want to check resource O for more information - essentially 
something similar to a hyperlink in a html document with no @rel value.


Best,

Nathan

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Phil Archer]

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 about the same thing - and rdfs:seeAlso doesn't really 
cover that nuance!


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 respond with that content type, there are 
codes to handle that.


Phil.

On 09/01/2011 15:21, Vasiliy Faronov wrote:

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
an HTTP redirect.
Not a generic this is vaguely related link at all, and not in
general to point to human-readable stuff.


Maybe it's time to define several specializations of rdfs:seeAlso with
stronger semantics?

For example (in a hypothetical namespace):

- see:authoritative -- strong pointer to a defining document,
   equivalent to (or even superseding) follow-your-nose. Could probably
   just reuse wrds:describedby, though it's not a subproperty of
   rdfs:seeAlso.
- see:continued -- pointer to more data of the same nature. Would be
   useful for paged data. When you have a blog marked up with RDFa, you
   may want to let the consumer know that any given page is really just
   a part of it. Strength depends on the application.
- see:historical -- pointer to data that no longer holds, thus cannot
   be taken at face value, but only in conjunction with some
   time-related terms (like owlTime:Interval). In other words, don't go
   there unless you are time-enabled.
- see:non_rdf -- pointer to a machine-readable description that is not
   in a serialization of RDF (GRDDL not counted as one).
- see:human_readable -- pointer to a description that is human-readable
   only.

--
Vasiliy Faronov



Please consider the environment before printing this email.

Find out more about Talis at http://www.talis.com/
shared innovation™

Any views or personal opinions expressed within this email may not be those of 
Talis Information Ltd or its employees. The content of this email message and 
any files that may be attached are confidential, and for the usage of the 
intended recipient only. If you are not the intended recipient, then please 
return this message to the sender and delete it. Any use of this e-mail by an 
unauthorised recipient is prohibited.

Talis Information Ltd is a member of the Talis Group of companies and is 
registered in England No 3638278 with its registered office at Knights Court, 
Solihull Parkway, Birmingham Business Park, B37 7YB.

Talis North America is Talis Inc., 11400 Branch Ct., Fredericksburg, VA 22408, 
United States of America.



--


Phil Archer
Talis Systems Ltd,
Web: http://www.talis.com
Tel: +44 1473 434770
Twitter: philarcher1
LinkedIn: http://uk.linkedin.com/in/philarcher
Personal: http://philarcher.org

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Vasiliy Faronov]

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 respond with that content type, there are 
 codes to handle that.

RDF often comes in the form of RDFa, which doesn't have a separate media
type from that of the host language. There are also custom provisions
for RDF in OpenDocument and PDF as far as I understand.

But I agree that using a property to indicate non-RDF content might be
conflating things, as format is orthogonal to the role of the relation.

Maybe something like this could work:

/foo rdfs:seeAlso /bar .
/bar
a see:HumanReadableOnlyDescription ;
dcterms:format http://example.net/text/html .

-- 
Vasiliy Faronov

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Ivan Herman]

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:

@prefix ore: http://www.openarchives.org/ore/terms/ .
@prefix dc: http://purl.org/dc/terms/ .
http://www.w3.org/2010/1124-Amsterdam-IH/#talk a ore:Aggregation ;
   ore:aggregates http://www.w3.org/2010/Talks/1124-Amsterdam-IH/Talk.pdf,
   . 

http://www.w3.org/2010/Talks/1124-Amsterdam-IH/Talk.pdf a 
ore:AggregatedResource ;
 dc:format http://purl.org/NET/mediatypes/application/pdf . 

If you have something like that, you can the do a 

   rdfs:seeAlso http://www.w3.org/2010/1124-Amsterdam-IH/#talk .

Would that help?

Caveat: the purl.org/NET/mediatypes includes only the formally registered media 
type, eg, not (yet?) Turtle... but that is a different thread...

Ivan 



On Jan 6, 2011, at 20:40 , Peter DeVries wrote:

 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 of http://lod.taxonconcept.org/ses/v6n7p.rdf )
 
   txn:SpeciesOriginalDescription 
 rdf:about=http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription;
 !-- Ideally, this should link to a resource in the Biodiversity Heritage 
 Library --
 dcterms:titleOriginal Published Description relating to Species Concept 
 Puma concolor se:v6n7p/dcterms:title
 
 dcterms:identifierhttp://lod.taxonconcept.org/ses/v6n7p#OriginalDescription/dcterms:identifier
 dcterms:descriptionLOD metadata about the original species description 
 relating to Species Concept Puma concolor se:v6n7p/dcterms:description
 dcterms:isPartOf 
 rdf:resource=http://lod.taxonconcept.org/ses/v6n7p#Species/
 txn:hasAuthorURI 
 rdf:resource=http://dbpedia.org/resource/Carl_Linnaeus/
 txn:hasBasionymNameFelis concolor Linnaeus 1771/txn:hasBasionymName
 txn:year1771/txn:year
 txn:hasPDFVersion 
 rdf:resource=http://assets.geospecies.org/spec_concept_uuid/603bebac-cc44-4168-bbf7-b11b976f9d79/Felis_concolor_Linnaeus_1771.pdf/
 txn:speciesOriginalDescriptionHasSpeciesConcept 
 rdf:resource=http://lod.taxonconcept.org/ses/v6n7p#Species/
 !-- There should be a type specimen. Add link to GBIF via 
 'txn:sodHasTypeSpecimen' if they know about it. --
 wdrs:describedBy 
 rdf:resource=http://lod.taxonconcept.org/ses/v6n7p.rdf/
   /txn:SpeciesOriginalDescription
 
 Some have suggested using rdfs:seeAlso to link to what could be a 
 multimegabyte PDF, but I think this would cause problems for a number of RDF 
 crawlers like Elmo.
 
 In summary, I think it would be useful to have a predicate that can be used 
 for linking specifically to a PDF document.
 
 Is there an existing predicate for this?
 
 What do people think about the suggestion to use rdfs:seeAlso to link to a 
 PDF?
 
 I would also like to know of others thoughts or suggestions regarding this 
 issue,
 
 Respectfully,
 
 - Pete
 
 
 
 ---
 Pete DeVries
 Department of Entomology
 University of Wisconsin - Madison
 445 Russell Laboratories
 1630 Linden Drive
 Madison, WI 53706
 TaxonConcept Knowledge Base / GeoSpecies Knowledge Base
 About the GeoSpecies Knowledge Base
 



Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf







smime.p7s
Description: S/MIME cryptographic signature

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[William Waites]

* [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. if the server can't respond with that content type, there are 
] codes to handle that.

I disagree that we should rely on HTTP headers for this.
Consider local processing of a large multi-graph dataset.
These kinds of properties can act as hints to process one
graph or another without the need to dereference something.
(tending to think of graph as equivalent to document 
obtained by dereferencing the graph's name).

Slightly more esoteric are graphs made available over 
ftp, finger, freenet, etc.. Let's take advantage of HTTP
where appropriate but not mix up the transport and 
content unnecessariy.

Cheers,
-w
-- 
William Waitesmailto:w...@styx.org
http://eris.okfn.org/ww/ sip:w...@styx.org
9C7E F636 52F6 1004 E40A  E565 98E3 BBF3 8320 7664

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Phil Archer]

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 'wrong', especially if the Accept Headers indicate a 
preference for PNG over GIF). RDF does not require any URI to be 
dereferencable so that, as you say, you can process a graph without 
having to dereference anything. If you /do/ dereference a URI you might 
get a 406 Not Acceptable response, which, IMHO, is as valid as any other 
(and I'm trying hard not to reopen the 303 debate yet again here!!). If 
the User Agent can only accept certain content types then it should make 
that explicit in is request headers and be ready to handle a 406 in some 
intelligent way.


Phil.

On 10/01/2011 12:45, William Waites wrote:

* [2011-01-10 08:55:59 +] Phil Archerphil.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. if the server can't respond with that content type, there are
] codes to handle that.

I disagree that we should rely on HTTP headers for this.
Consider local processing of a large multi-graph dataset.
These kinds of properties can act as hints to process one
graph or another without the need to dereference something.
(tending to think of graph as equivalent to document
obtained by dereferencing the graph's name).

Slightly more esoteric are graphs made available over
ftp, finger, freenet, etc.. Let's take advantage of HTTP
where appropriate but not mix up the transport and
content unnecessariy.

Cheers,
-w


--


Phil Archer
Talis Systems Ltd,
Web: http://www.talis.com
Tel: +44 1473 434770
Twitter: philarcher1
LinkedIn: http://uk.linkedin.com/in/philarcher
Personal: http://philarcher.org

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Toby Inkster]

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 format.

s rdfs:seeAlso o .
# Like powder-s:describedby but perhaps more tangential.
# o might have information on something similar to s; or
# if s is a document, o might have information on the
# things described by s.

s foaf:page o .
# o provides information about s, often in a human-readable
# format.

s rdfs:isDefinedBy o .
# o provides the canonical definition of s .

We also have foaf:isPrimaryTopicOf, various terms from the XHTML
vocabulary (xhv:meta, xhv:next, xhv:prev, etc), various terms from
Dublin Core (dc:source, dc:relation, dc:replaces/isReplacedBy,
dc:references/isReferencedBy, dc:hasVersion/isVersionOf,
dc:hasPart/isPartOf, dc:isFormatOf/hasFormat) and countless others.

To answer the original question, I'd say foaf:page is a better predicate
than rdfs:seeAlso for a large PDF.

-- 
Toby A Inkster
mailto:m...@tobyinkster.co.uk
http://tobyinkster.co.uk

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Toby Inkster]

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. Either way, it's worth noting that he
 and I are talking about the same thing - and rdfs:seeAlso doesn't
 really cover that nuance! 

@prefix dc:   http://purl.org/dc/terms/ .
@prefix uri:  http://purl.org/NET/uri# .
@prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
@prefix xsd:  http://www.w3.org/2001/XMLSchema# .

foo rdfs:seeAlso http://example.com/bar .
http://example.com/bar uri:identifier [
uri:literal http://example.com/bar^^xsd:anyURI ;
dc:issued 2011-01-08^^xsd:date ;
u:policy _:ExampleDotComUriPolicy ;
u:assigned_by http://example.com/alice#me
] .
_:ExampleDotComUriPolicy
rdfs:comment
  These URIs are not authoritative, but may become so.@en .

-- 
Toby A Inkster
mailto:m...@tobyinkster.co.uk
http://tobyinkster.co.uk

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Jiří Procházka]

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 RDF then it should have a suitable accept 
 ] header. if the server can't respond with that content type, there are 
 ] codes to handle that.
 
 I disagree that we should rely on HTTP headers for this.
 Consider local processing of a large multi-graph dataset.
 These kinds of properties can act as hints to process one
 graph or another without the need to dereference something.
 (tending to think of graph as equivalent to document 
 obtained by dereferencing the graph's name).
 
 Slightly more esoteric are graphs made available over 
 ftp, finger, freenet, etc.. Let's take advantage of HTTP
 where appropriate but not mix up the transport and 
 content unnecessariy.
 
 Cheers,
 -w

I agree, there is nothing wrong in having a subProperty which includes
more information, whether it be about the subject or object of the
triple, regardless if it's about content type or anything else.
I believe it is good practice to specify domain and range of property in
as precisely as possible. Failing to do so begs for usage which either
is wrong by the original intention or making the meaning of the property
very fuzzy, which in both cases results in less useful data.

Best,
Jiri



signature.asc
Description: OpenPGP digital signature

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Nathan]

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 of URIs, and always has been.

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Phil Archer]

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
this is by far the most common usage of URIs, and always has been.


True, of course. But the fact that the identified resource is only 
available in a single representation is not denoted by the identifier. 
One might have reasonable expectations about 
http://example.com/index.html but no more. The only authoritative 
declaration of the content type of a resource is given in the HTTP 
response headers received when dereferencing the identifier.


--


Phil Archer
Talis Systems Ltd,
Web: http://www.talis.com
Tel: +44 1473 434770
Twitter: philarcher1
LinkedIn: http://uk.linkedin.com/in/philarcher
Personal: http://philarcher.org

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Vasiliy Faronov]

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 appropriate
predicates.


 s powder-s:describedby o .
 # o provides some more information about o, often in a
 # machine-readable format.

Or could as well be a 15M PDF. An autonomous LD client cannot tell.

An informal recommendation like use wdrs:describedby to point to a
terse and authoritative RDF description and/or wdrs:describedby is
equivalent to a follow-your-nose description would help.

Then again, nothing in the POWDER spec says it shouldn't be a 15M PDF.
So we kind of imbue a predicate with semantics it doesn't have according
to the standard. A separate term with a clear specification would avoid
this problem and everyone could rely on it.


 s rdfs:seeAlso o .
 # Like powder-s:describedby but perhaps more tangential.

As Tim's email suggests, this interpretation is not universal.


 s rdfs:isDefinedBy o .
 # o provides the canonical definition of s .

It's clear what a definition is for an RDFS vocabulary term, but not
clear if I can apply this to instance data. Is authoritative
description synonymous with definition? Does anyone use isDefinedBy
for things other than classes and properties?

-- 
Vasiliy Faronov

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Tim Berners-Lee]

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 up the seeAlso  or they 
don't follow any links.

So tabulator always when looking up x and finding x see:also y will 
load y.  So must any similar client or any crawler.

So there is a lot of existing use we would throw away if we 
allowed rdfs:seeAlso for pointing to things which do not 
provide data. (It isn't the question of conneg or mime type,
that is a red herring. it is whether there is machine-redable
standards-based stuff about x).

Further, we should not make any weaker properties like seeDocumentation
subproperties of see:Also, or they would imply
We maybe need a very weak top property like

mayHaveSomeKindOfInfoAboutThis 

to be the superProperty of all the others.

One things which could be stronger than seeAlso is definedBy if it
is normally used for data, to point to the definitive ontology.
That would then imply seeAlso.

Tim

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Peter DeVries]

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 the Biodiversity Heritage
Library --
 dcterms:titleOriginal Published Description relating to Species Concept
Puma concolor se:v6n7p/dcterms:title
 dcterms:identifier
http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription
/dcterms:identifier
 dcterms:descriptionLOD metadata about the original species description
relating to Species Concept Puma concolor se:v6n7p/dcterms:description
 dcterms:isPartOf rdf:resource=
http://lod.taxonconcept.org/ses/v6n7p#Species/
 dcterms:creator rdf:resource=http://dbpedia.org/resource/Carl_Linnaeus/
 txn:hasBasionymNameFelis concolor Linnaeus 1771/txn:hasBasionymName
 dcterms:created rdf:datatype=http://www.w3.org/2001/XMLSchema#gYear
1771/dcterms:created
 dcterms:hasFormat rdf:resource=
http://assets.geospecies.org/spec_concept_uuid/603bebac-cc44-4168-bbf7-b11b976f9d79/Felis_concolor_Linnaeus_1771.pdf
/
 txn:speciesOriginalDescriptionHasSpeciesConcept rdf:resource=
http://lod.taxonconcept.org/ses/v6n7p#Species/
 !-- There should be a type specimen. Add link to GBIF via
'txn:sodHasTypeSpecimen' if they know about it. --
 wdrs:describedby rdf:resource=http://lod.taxonconcept.org/ses/v6n7p.rdf
/
/txn:SpeciesOriginalDescription

rdf:Description rdf:about=
http://assets.geospecies.org/spec_concept_uuid/603bebac-cc44-4168-bbf7-b11b976f9d79/Felis_concolor_Linnaeus_1771.pdf

 dcterms:formatapplication/pdf/dcterms:format
/rdf:Description

Here is the link to the entire RDF for this species
http://lod.taxonconcept.org/ses/v6n7p.rdf

I have updated the CKAN information http://ckan.net/package/taxonconcept

http://ckan.net/package/taxonconceptand the void
http://lod.taxonconcept.org/ontology/void.rdf

The RDF dump files have been updated.

http://lod.taxonconcept.org/ontology/void.rdfThe semantic sitemap is here
http://lod.taxonconcept.org/sitemap.xml.gz

http://lod.taxonconcept.org/sitemap.xml.gzI still have not figured out the
best way to generate the interlink counts but the CKAN numbers are close.

There are probably still errors or suboptimal semantic markup in these or
their related ontology.

I would welcome any suggestions or comments on ways to make these better.

With each iteration I have been trying to add additional information that
makes it easier to determine what is a and what is not an instance of one of
the species concepts.

It will take a while for these to get to what they should be.

Thanks Again,

Respectfully,

- Pete

On Mon, Jan 10, 2011 at 9:01 AM, Tim Berners-Lee ti...@w3.org wrote:

 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 up the seeAlso  or they
 don't follow any links.

 So tabulator always when looking up x and finding x see:also y will
 load y.  So must any similar client or any crawler.

 So there is a lot of existing use we would throw away if we
 allowed rdfs:seeAlso for pointing to things which do not
 provide data. (It isn't the question of conneg or mime type,
 that is a red herring. it is whether there is machine-redable
 standards-based stuff about x).

 Further, we should not make any weaker properties like seeDocumentation
 subproperties of see:Also, or they would imply
 We maybe need a very weak top property like

 mayHaveSomeKindOfInfoAboutThis

 to be the superProperty of all the others.

 One things which could be stronger than seeAlso is definedBy if it
 is normally used for data, to point to the definitive ontology.
 That would then imply seeAlso.

 Tim











-- 
---
Pete DeVries
Department of Entomology
University of Wisconsin - Madison
445 Russell Laboratories
1630 Linden Drive
Madison, WI 53706
TaxonConcept Knowledge Base http://www.taxonconcept.org/ / GeoSpecies
Knowledge Base http://lod.geospecies.org/
About the GeoSpecies Knowledge Base http://about.geospecies.org/

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Vasiliy Faronov]

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
 an HTTP redirect.
 Not a generic this is vaguely related link at all, and not in
 general to point to human-readable stuff.

Maybe it's time to define several specializations of rdfs:seeAlso with
stronger semantics?

For example (in a hypothetical namespace):

- see:authoritative -- strong pointer to a defining document, 
  equivalent to (or even superseding) follow-your-nose. Could probably 
  just reuse wrds:describedby, though it's not a subproperty of 
  rdfs:seeAlso.
- see:continued -- pointer to more data of the same nature. Would be 
  useful for paged data. When you have a blog marked up with RDFa, you 
  may want to let the consumer know that any given page is really just
  a part of it. Strength depends on the application.
- see:historical -- pointer to data that no longer holds, thus cannot
  be taken at face value, but only in conjunction with some
  time-related terms (like owlTime:Interval). In other words, don't go 
  there unless you are time-enabled.
- see:non_rdf -- pointer to a machine-readable description that is not 
  in a serialization of RDF (GRDDL not counted as one).
- see:human_readable -- pointer to a description that is human-readable 
  only.

-- 
Vasiliy Faronov

RE: {Disarmed} Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Andy Powell]

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 Director
Eduserv
t: 01225 474319
m: 07989 476710
twitter: @andypowe11
blog: efoundations.typepad.com

www.eduserv.org.ukhttp://www.eduserv.org.uk

From: public-lod-requ...@w3.org [mailto:public-lod-requ...@w3.org] On Behalf Of 
Andy Powell
Sent: 07 January 2011 14:30
To: Christopher Gutteridge; Hugh Glaser
Cc: Peter DeVries; public-lod@w3.org
Subject: RE: {Disarmed} Re: Is it best practices to use a rdfs:seeAlso link to 
a potentially multimegabyte PDF?, existing predicate for linking to PDF?

I suspect you might already be in FRBR hell with your use of dcterms:hasPart 
(at least in the case of linking to the PDF)... you just don't know it yet! :-)

In response to the original question about linking to the PDF file, I would 
have thought that dcterms:hasVersion would do the job?

Andy

--
Andy Powell
Research Programme Director
Eduserv
t: 01225 474319
m: 07989 476710
twitter: @andypowe11
blog: efoundations.typepad.com

www.eduserv.org.ukhttp://www.eduserv.org.uk

From: public-lod-requ...@w3.org [mailto:public-lod-requ...@w3.org] On Behalf Of 
Christopher Gutteridge
Sent: 06 January 2011 21:02
To: Hugh Glaser
Cc: Peter DeVries; public-lod@w3.org
Subject: {Disarmed} Re: Is it best practices to use a rdfs:seeAlso link to a 
potentially multimegabyte PDF?, existing predicate for linking to PDF?

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 
record, and you rapidly decend into FRBR hell.

Until a few people have consumed my data I consider it very much a work in 
progress!

Hugh Glaser wrote:

I see that Chris Gutteridge uses dc:hasPart for the ePrints RDF (eprints.org).

Eg:



http://eprints.ecs.soton.ac.uk/21681/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 
http://eprints.ecs.soton.ac.uk/id/eprint/21681http://eprints.ecs.soton.ac.uk/id/eprint/21681
 .



http://eprints.ecs.soton.ac.uk/id/eprint/21681http://eprints.ecs.soton.ac.uk/id/eprint/21681

ep:hasDocument 
http://eprints.ecs.soton.ac.uk/id/document/36430http://eprints.ecs.soton.ac.uk/id/document/36430,



http://eprints.ecs.soton.ac.uk/id/document/36430http://eprints.ecs.soton.ac.uk/id/document/36430

dct:hasPart 
http://eprints.ecs.soton.ac.uk/21681/1/cold2010%2Dpaper16%2Dcamera%2Dready.pdfhttp://eprints.ecs.soton.ac.uk/21681/1/cold2010%2Dpaper16%2Dcamera%2Dready.pdf;





Cheers

Hugh



On 6 Jan 2011, at 19:40, Peter DeVries wrote:





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 of http://lod.taxonconcept.org/ses/v6n7p.rdf )



  txn:SpeciesOriginalDescription rdf:about=MailScanner has detected a possible 
fraud attempt from lod.taxonconcept.org claiming to be 
http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription;http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription

!-- Ideally, this should link to a resource in the Biodiversity Heritage 
Library --

dcterms:titleOriginal Published Description relating to Species Concept 
Puma concolor se:v6n7p/dcterms:title


dcterms:identifierhttp://lod.taxonconcept.org/ses/v6n7p#OriginalDescription/dcterms:identifier

dcterms:descriptionLOD metadata about the original species description 
relating to Species Concept Puma concolor se:v6n7p/dcterms:description

dcterms:isPartOf rdf:resource=MailScanner has detected a possible fraud 
attempt from lod.taxonconcept.org claiming to be 
http://lod.taxonconcept.org/ses/v6n7p#Species;http://lod.taxonconcept.org/ses/v6n7p#Species/

txn:hasAuthorURI rdf:resource=MailScanner has detected a possible fraud 
attempt from dbpedia.org claiming to be 
http://dbpedia.org/resource/Carl_Linnaeus;http://dbpedia.org/resource/Carl_Linnaeus/

txn:hasBasionymNameFelis concolor Linnaeus 1771/txn:hasBasionymName

txn:year1771/txn:year

txn:hasPDFVersion rdf:resource=MailScanner has detected a possible fraud 
attempt from assets.geospecies.org claiming to be 

Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Peter DeVries]

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 of http://lod.taxonconcept.org/ses/v6n7p.rdf )

  txn:SpeciesOriginalDescription rdf:about=
http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription;
!-- Ideally, this should link to a resource in the Biodiversity
Heritage Library --
dcterms:titleOriginal Published Description relating to Species
Concept Puma concolor se:v6n7p/dcterms:title
dcterms:identifier
http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription
/dcterms:identifier
dcterms:descriptionLOD metadata about the original species description
relating to Species Concept Puma concolor se:v6n7p/dcterms:description
dcterms:isPartOf rdf:resource=
http://lod.taxonconcept.org/ses/v6n7p#Species/
txn:hasAuthorURI rdf:resource=
http://dbpedia.org/resource/Carl_Linnaeus/
txn:hasBasionymNameFelis concolor Linnaeus 1771/txn:hasBasionymName
txn:year1771/txn:year
txn:hasPDFVersion rdf:resource=
http://assets.geospecies.org/spec_concept_uuid/603bebac-cc44-4168-bbf7-b11b976f9d79/Felis_concolor_Linnaeus_1771.pdf
/
txn:speciesOriginalDescriptionHasSpeciesConcept rdf:resource=
http://lod.taxonconcept.org/ses/v6n7p#Species/
!-- There should be a type specimen. Add link to GBIF via
'txn:sodHasTypeSpecimen' if they know about it. --
wdrs:describedBy rdf:resource=
http://lod.taxonconcept.org/ses/v6n7p.rdf/
  /txn:SpeciesOriginalDescription

Some have suggested using rdfs:seeAlso to link to what could be a
multimegabyte PDF, but I think this would cause problems for a number of RDF
crawlers like Elmo.

In summary, I think it would be useful to have a predicate that can be used
for linking specifically to a PDF document.

Is there an existing predicate for this?

What do people think about the suggestion to use rdfs:seeAlso to link to a
PDF?

I would also like to know of others thoughts or suggestions regarding this
issue,

Respectfully,

- Pete



---
Pete DeVries
Department of Entomology
University of Wisconsin - Madison
445 Russell Laboratories
1630 Linden Drive
Madison, WI 53706
TaxonConcept Knowledge Base http://www.taxonconcept.org/ / GeoSpecies
Knowledge Base http://lod.geospecies.org/
About the GeoSpecies Knowledge Base http://about.geospecies.org/

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Hugh Glaser]

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 http://eprints.ecs.soton.ac.uk/id/eprint/21681 .
...
http://eprints.ecs.soton.ac.uk/id/eprint/21681
ep:hasDocument http://eprints.ecs.soton.ac.uk/id/document/36430,
...
http://eprints.ecs.soton.ac.uk/id/document/36430
dct:hasPart 
http://eprints.ecs.soton.ac.uk/21681/1/cold2010%2Dpaper16%2Dcamera%2Dready.pdf;
...

Cheers
Hugh

On 6 Jan 2011, at 19:40, Peter DeVries wrote:

 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 of http://lod.taxonconcept.org/ses/v6n7p.rdf )
 
   txn:SpeciesOriginalDescription 
 rdf:about=http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription;
 !-- Ideally, this should link to a resource in the Biodiversity Heritage 
 Library --
 dcterms:titleOriginal Published Description relating to Species Concept 
 Puma concolor se:v6n7p/dcterms:title
 
 dcterms:identifierhttp://lod.taxonconcept.org/ses/v6n7p#OriginalDescription/dcterms:identifier
 dcterms:descriptionLOD metadata about the original species description 
 relating to Species Concept Puma concolor se:v6n7p/dcterms:description
 dcterms:isPartOf 
 rdf:resource=http://lod.taxonconcept.org/ses/v6n7p#Species/
 txn:hasAuthorURI 
 rdf:resource=http://dbpedia.org/resource/Carl_Linnaeus/
 txn:hasBasionymNameFelis concolor Linnaeus 1771/txn:hasBasionymName
 txn:year1771/txn:year
 txn:hasPDFVersion 
 rdf:resource=http://assets.geospecies.org/spec_concept_uuid/603bebac-cc44-4168-bbf7-b11b976f9d79/Felis_concolor_Linnaeus_1771.pdf/
 txn:speciesOriginalDescriptionHasSpeciesConcept 
 rdf:resource=http://lod.taxonconcept.org/ses/v6n7p#Species/
 !-- There should be a type specimen. Add link to GBIF via 
 'txn:sodHasTypeSpecimen' if they know about it. --
 wdrs:describedBy 
 rdf:resource=http://lod.taxonconcept.org/ses/v6n7p.rdf/
   /txn:SpeciesOriginalDescription
 
 Some have suggested using rdfs:seeAlso to link to what could be a 
 multimegabyte PDF, but I think this would cause problems for a number of RDF 
 crawlers like Elmo.
 
 In summary, I think it would be useful to have a predicate that can be used 
 for linking specifically to a PDF document.
 
 Is there an existing predicate for this?
 
 What do people think about the suggestion to use rdfs:seeAlso to link to a 
 PDF?
 
 I would also like to know of others thoughts or suggestions regarding this 
 issue,
 
 Respectfully,
 
 - Pete
 
 
 
 ---
 Pete DeVries
 Department of Entomology
 University of Wisconsin - Madison
 445 Russell Laboratories
 1630 Linden Drive
 Madison, WI 53706
 TaxonConcept Knowledge Base / GeoSpecies Knowledge Base
 About the GeoSpecies Knowledge Base
 

-- 
Hugh Glaser,  
  Intelligence, Agents, Multimedia
  School of Electronics and Computer Science,
  University of Southampton,
  Southampton SO17 1BJ
Work: +44 23 8059 3670, Fax: +44 23 8059 3045
Mobile: +44 78 9422 3822, Home: +44 23 8061 5652
http://www.ecs.soton.ac.uk/~hg/

{Disarmed} Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

[Christopher Gutteridge]

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 record, and you rapidly decend into FRBR hell.


Until a few people have consumed my data I consider it very much a work 
in progress!


Hugh Glaser wrote:

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 http://eprints.ecs.soton.ac.uk/id/eprint/21681 .
...
http://eprints.ecs.soton.ac.uk/id/eprint/21681
ep:hasDocument http://eprints.ecs.soton.ac.uk/id/document/36430,
...
http://eprints.ecs.soton.ac.uk/id/document/36430
dct:hasPart 
http://eprints.ecs.soton.ac.uk/21681/1/cold2010%2Dpaper16%2Dcamera%2Dready.pdf;
...

Cheers
Hugh

On 6 Jan 2011, at 19:40, Peter DeVries wrote:

  

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 of http://lod.taxonconcept.org/ses/v6n7p.rdf )


  txn:SpeciesOriginalDescription 
rdf:about=http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription;
!-- Ideally, this should link to a resource in the Biodiversity Heritage 
Library --
dcterms:titleOriginal Published Description relating to Species Concept Puma 
concolor se:v6n7p/dcterms:title

dcterms:identifierhttp://lod.taxonconcept.org/ses/v6n7p#OriginalDescription/dcterms:identifier
dcterms:descriptionLOD metadata about the original species description relating 
to Species Concept Puma concolor se:v6n7p/dcterms:description
dcterms:isPartOf 
rdf:resource=http://lod.taxonconcept.org/ses/v6n7p#Species/
txn:hasAuthorURI rdf:resource=http://dbpedia.org/resource/Carl_Linnaeus/
txn:hasBasionymNameFelis concolor Linnaeus 1771/txn:hasBasionymName
txn:year1771/txn:year
txn:hasPDFVersion 
rdf:resource=http://assets.geospecies.org/spec_concept_uuid/603bebac-cc44-4168-bbf7-b11b976f9d79/Felis_concolor_Linnaeus_1771.pdf/
txn:speciesOriginalDescriptionHasSpeciesConcept 
rdf:resource=http://lod.taxonconcept.org/ses/v6n7p#Species/
!-- There should be a type specimen. Add link to GBIF via 
'txn:sodHasTypeSpecimen' if they know about it. --
wdrs:describedBy rdf:resource=http://lod.taxonconcept.org/ses/v6n7p.rdf/
  /txn:SpeciesOriginalDescription

Some have suggested using rdfs:seeAlso to link to what could be a multimegabyte 
PDF, but I think this would cause problems for a number of RDF crawlers like 
Elmo.

In summary, I think it would be useful to have a predicate that can be used for 
linking specifically to a PDF document.

Is there an existing predicate for this?

What do people think about the suggestion to use rdfs:seeAlso to link to a PDF?

I would also like to know of others thoughts or suggestions regarding this 
issue,

Respectfully,

- Pete



---
Pete DeVries
Department of Entomology
University of Wisconsin - Madison
445 Russell Laboratories
1630 Linden Drive
Madison, WI 53706
TaxonConcept Knowledge Base / GeoSpecies Knowledge Base
About the GeoSpecies Knowledge Base




  


--
Christopher Gutteridge -- http://id.ecs.soton.ac.uk/person/1248

You should read the ECS Web Team blog: http://blogs.ecs.soton.ac.uk/webteam/