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

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
>

Received on Thursday, 13 January 2011 11:52:21 UTC