Re: ISSUE-66: LinkedDataT

Hi Markus,

> Funny fact: the "original principles" didn't explicitly mention it:
> 
> 
> https://web.archive.org/web/20061115043657/http://www.w3.org/DesignIssues/Li
> nkedData.html
> 
> It took 3 years till that was added.

Waw, that's the fact of the day for me!

>> I'd dare to say that the majority of people do assume
>> that Linked Data is just done with RDF.
> 
> That's obviously true for the Semantic Web community. Not so true for the
> rest of the world :-)

I thought the only people who cared about Linked Data
were those in the Semantic Web community. My bad!

Any examples of non-RDF Linked Data in the wild?

> Hydra tries to bridge the gap between those two worlds
> (just as JSON-LD does).

For me, Hydra is simply defined by the applications it enables;
the same JSON-LD. Linked Data is a nice benefit, though.

I'm saying that because calling something a bridge
can lead to different kinds of feelings: do we want/need that bridge?
Enabling applications is something tangible.

>> So to what extent is it then necessary to clarify this?
> 
> I think it is very important as our group is not a homogenous group of
> Semantic Web experts.

Still not fully convinced there are people
who don't think of “RDF” when hearing “Linked Data”.
Could you point me to examples?

>> What do you think about the current introduction
>> to the triple pattern fragments spec [1]?
> 
> It's quite nice but I think it could be further improved, especially for
> people without a lot of SemWeb background. 

Any suggestions?

>>    By publishing Linked Data [LINKED-DATA],
>>    we enable automated clients to consume information.
> 
> Hmm... automated clients such as Google are quite happy consuming plain old
> HTML... I know what you are trying to say but people who haven't spent a
> whole lot of time on this won't understand it, I think.

Instead of “consume”:
- “understand” (not the right word)
- “interpret” (what does that mean)
- … ?

"interpret" might be best!

> Maybe it would be more straightforward to explain it the other way round:
>  - documents are in natural language
>  - machines are bad in understanding natural language
>  - machines prefer structured data using unambiguous identifiers
>  - the Web uses URLs* as identifiers
>  - RDF allows data to be expressed in a machine-processable way by
> leveraging URLs
>  (- RDF expresses data in the form of triples) -- could be omitted
>  - RDF can be serialized in various formats such as JSON-LD, HTML+RDFa, or
> Turtle

I suppose I could rewrite it like that, yes!

> I would also suggest to use a different term than "Linked Data document". Is
> it actually needed or could we also get rid of this concept?

I used to call them colloquially “subject pages”;
I think it was Olaf who recommended me "Linked Data document”.

Any term that's more clear is good for me.

>> On the technical level, nothing prohibits us from making Linked Data
>> Fragments broader than RDF. We'd have to be very careful, however,
>> that the concept would still be sufficiently meaningful; that it
>> doesn't become hollow by broadening it.
> 
> Yeah, I would like to explore that in the future. However, till we get
> there, we should make it clear that at least a mapping to RDF is required.

+1

Ruben

Received on Tuesday, 5 August 2014 12:21:13 UTC