Re: Semantics of rdfs:seeAlso (Was: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?)

On 1/13/11 1:16 PM, Nathan wrote:
> Kingsley Idehen wrote:
>> On 1/13/11 12:04 PM, Nathan wrote:
>>> Hi Kinglsey,
>>>
>>> Kingsley Idehen wrote:
>>>> When our engine describes entities it can publish these 
>>>> descriptions using variety of structured data formats that include 
>>>> RDF. The same thing applies on the data consumption side. 
>>>> Basically, RDF formats are options re. Linked Data (the concept).
>>>
>>> A generic problem here, when using non RDF types with Linked Data 
>>> over HTTP, is that there's currently no way to indicate that a 
>>> resource is/has a set of machine readable "linked data" variants, in 
>>> many cases it is useful to publish and consume with linked data in 
>>> CSV format and related (as you well note) - but without prior out of 
>>> band knowledge that the representation contains, or is, linked data, 
>>> the machines are pretty much screwed. Typically the RDF variants 
>>> don't have this problem because the media type sets the expectation, 
>>> so you can conneg on an RDF type and know your getting back "linked 
>>> data", you can't do this with CSV and related with any expectation 
>>> that you'll get back "linked data" - thus, if there was some way to 
>>> mark the set of representations given upon dereferencing a URI as 
>>> linked data, containing rdf, rdfable 3 tuples, or a view thereof, 
>>> it'd be a lot friendlier to the web of data in general.
>>
>> So what happens to RDFa in (X)HTML? Even worse, no DOCTYPE declarations?
>> What about various JSON dialects for Linked Data graphs?
>> How about N-Triples? Ditto TriX and others?
>
> Probably wasn't clear, I'm saying there needs to be something (for 
> instance a new header) which indicates that the representation 
> contains "linked data", then you machines could automatically throw 
> the CSV through a csv-linked-data parser and it'd work, likewise every 
> type you mentioned above.

Yes, maybe, but that takes time. The practical thing is to work with 
what exists first, then finesse later. WWW already works this way. In a 
sense, the real ingenuity of the WWW is the fact that imperfection is an 
intrinsic feature :-)

>
> The problem here isn't the different types of media, the problem here is
>
> (1) internet media types are dire and badly need re-looked at
>
> (2) there's no information provided to machine so that it has a hope 
> in hell of understanding one of these other variants (lest it has it's 
> own special mediatype)

See comments above. That's InterWeb reality.

What needs fixing is Identity. Basically, what's happening via WebID 
which is a great example of Linked Data exploitation.
>
> Fix that and the door is opened to all of the above.
>
>  - RDFa needs an indicator at HTTP Message level to say it's "html+rdfa"
>  - JSON dialects need standardized (coming soon to a WG near you) w/ 
> media type registered / well-known
>  - N-Triples needs it's own media type (doesn't have one)
>  - and so on..

But it ain't going to happen within realistic timeframes, if at all.

>
> Typically we need a machine to not only ask "Accept: something/rdf" 
> but to effectively ask "if linked data give me JSON" (swap json for 
> csv, turtle, rdf+xml, whatever)

I think it should ask for data in a representation it understands as 
defined by its application senses. If the server can't produce what is 
required, the client should make a best effort to transform the data, 
and if it can't do that, move on.

Perfection has never boostrapped anything. Pragmatism wins all the time. 
WWW is a contemporary example of the aforementioned statement.

At this juncture, the goal has to be: Linked Data comprehension and mass 
exploitation. It has to be inclusive and devoid of distractions. Those 
who understand its nuances and innards should express these prowess via 
their solutions -- client or server side. Every new productive Linked 
Data solution -- that appreciate working with what exists -- simply 
enhances the ecosystem.


Kingsley
>
> Best,
>
> Nathan
>


-- 

Regards,

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

Received on Thursday, 13 January 2011 18:30:09 UTC