[occi-wg] RDF, RDFa and HTML
Gary Mazz
garymazzaferro at gmail.com
Fri Jun 25 04:44:51 CDT 2010
Hi Andy,
Thanks for the quick response. I did the inline.. I'll give more detail
over the weekend.
Edmonds, AndrewX wrote:
> Hey Gary :-)
>
> Responses inline...
>
> -----Original Message-----
> From: Gary Mazz [mailto:garymazzaferro at gmail.com]
> Sent: Thursday, June 24, 2010 4:27 PM
> To: Edmonds, AndrewX
> Cc: Roger Menday; occi-wg
> Subject: Re: [occi-wg] RDF, RDFa and HTML
>
> Hi,
>
> I have a couple of issues, I'm going to be terse, I don't have a lot of
> time today.
>
> 1) There are a couple of RDF initiatives to directed at fostering reuse
> and management of vocabularies; Dublin Core's DCMI and the Ontology
> Metadata Vocabulary (OMV). I'm not sure if they are mutually exclusive,
> complimentary or if they are interoperable. We need to determine the
> impact to our work. Maybe Roger Menday can help clarify ?
>
> There's plenty of sense in investigating this. One thing to be weary of is introducing dependencies on classes, attributes etc that are RDF specific. We still need to support HTTP Headers.
>
The reason for considering aligning with one or both of the initiatives
is not to adopt dependencies, but facilitate occi's adoption. The occi
only provides a subset of a solution vocabulary. Users will more than
likely adopt other existing vocabularies in their solutions, ie foaf
There could be overlap (vocabulary aliasing) between occi RDF and other
defined vocabularies, but we can't worry about that now. There are
ontologies popping up every week Then there is the case of adopting a
vocabulary to fill the gaps in occi, such as RDF Service Discovery
Descriptions (http://vocab.org/riro/ddl ) .
We should make considerations for HTTP headers as with considerations
for RDFa.
> 2) We need to take a close look at the html's RDFa's mapping. We should
> try to eliminate as much overlap as possible between elements and
> attributes that are already defined html and especially the items that
> affect browser renderings. See number 4 below
>
> I can't quite see what the issue is here yet. Can you give an example of overlaps in the examples?
>
You don't show any overlap in your examples, but the examples are more
representative of html4 than xhtml5/RDFa. We not only have to address
the issues of rdfa, but the and precedence mapping of html5 to make
human to machine documents interoperable. We do not want to re-purpose
attributes that are already defined for xhtml5, ie the 'alt' attribute.
If we do adopt them, we need to maintain current functional definition.
> 3) We need to decide whether the RDFa content is visible to browsers or
> we use JS to access RDFa elements and attributes. I had initially
> decided to make the RDFa invisible and use JS to reference information
> needed to be rendered. If we allow direct rendering, we will need to
> implement item list as number 4.
>
> Ah yes, I've another mail coming on this more so related on write-class operations using RDFa as a payload. In the example RDFa I sent values are exposed in 2 different but compliant ways; using the 'content' RDFa attribute, in which case it's visually not displayed in web browsers. The second fashion places the value pointed to by the predicate as the literal value of the enclosing HTML element. I would lean towards the latter right now.
>
Agreed,
> 4) We also need to decide on the approach take to indicate relationships
> between occi objects. RDFa will allow a server to project one or more a
> occi graphs in a document or reference graphs across documents. Graphs
> may not be top down. We need a way to represent the references and type
> of relationship between graph elements. I was using the rel, rev, and
> href to indicate relationships between information elements and the
> backbone of decoupled graphs. Today, none of these attributes impact the
> rendering of content in browsers
>
> Relationships between OCCI instances are defined by the Link entity right? There was an example in the HTML files I sent around. Can you send an example of how you were doing it to compare?
>
Well the link entity has very specific behaviors in terms of browser
technologies. The occi data model may not coincide with links. Links
do not imply any specific relationship between linked objects making
bidirectional transversal of the occi data impossible, limiting what can
be represented. This is why we use rel & rev.
There is another issue with links, we can support more than one link per
occi resource, or at least we do not restrict it. We need a way to
reconcile the purpose of the links.
> Although in certain areas we are back fitting RDFa mapping into the RDF
> vocabulary, I don't see a way to RDFa without remapping the RDF to RDFa
> vocabulary.
>
> Lost me there :-) Can you give me a concrete example to illustrate?
>
We need to define the scope and limits of what is going to be
represented and which RDFa and XHTML features we are going to use. If we
define the RDF in a pure form, we will leave out additional usability
aspects provided by xhtml5. We will need to examine the html features
and determine what we are going to adopt, reeling in the wild west phase
of the documents.
> cheers,
> gary
>
> Edmonds, AndrewX wrote:
>
>> You are more than welcome!
>>
>> Just a little note:
>> The Link entity is incorrectly modeled for those that have checked things out there's a bunch of attributes hanging off it. They should not. I'll update the python and owl files when committing to svn (2xTODOs)
>>
>> Andy
>>
>> -----Original Message-----
>> From: Roger Menday [mailto:roger.menday at uk.fujitsu.com]
>> Sent: Thursday, June 24, 2010 11:53 AM
>> To: Edmonds, AndrewX
>> Cc: occi-wg
>> Subject: Re: [occi-wg] RDF, RDFa and HTML
>>
>>
>> hi Andy
>>
>> thanks for posting this. I'm digesting (and I hope others are too).
>> I am very interested in seeing where OCCI can go with this - I hope to
>> get back to you soon.
>>
>> Roger
>>
>> On 23 Jun 2010, at 12:44, Edmonds, AndrewX wrote:
>>
>>
>>
>>> Hi all,
>>>
>>> I've been looking into how OCCI can expose itself through a HTML
>>> serialization and to demarcate machine readable, semantic content.
>>> To demarcate that content we already decided that we would use RDFa
>>> [1]. In order to truly and correctly use RDFa we need to be able to
>>> point to the ontology (model) in which subject, predicate and object
>>> triplets are defined. Defining the ontology is somewhat easy, we
>>> have it already with the OCCI model; it's just a matter of
>>> expressing it in RDF. With an ontology in hand, we can define
>>> semantically marked-up HTML with the ontology's vocabulary using the
>>> facilities of RDFa. I've worked on 2 ways of expressing the OCCI
>>> model in RDF.
>>>
>>> 1. Using python [2].
>>> 2. Using a modeling tool (Protégé) [3][4][5]. Note these owl files
>>> may need their imports modified in Protégé.
>>>
>>> The only difference in the two is that occi.owl (core spec), occi-
>>> infrastructure.owl (infrastructure spec) and occi-sla-at-soi.owl
>>> (SLA at SOI extensions) are defined in separate files with the Protégé
>>> approach. This should give folks an idea of how extensions for OCCI
>>> can be introduced. However in both examples, occi-core, occi-
>>> infrastructure and slasoi-infrastructure are separated by namespace.
>>>
>>> As RDFa does not explicitly define a rigorous structure for HTML
>>> documents, and it shouldn't, we need to be able to express 2 basics
>>> forms:
>>>
>>> 1. A concrete OCCI Kind instance (Compute, Storage, Network). I have
>>> an example here [6].
>>> 2. A collection of OCCI Kind instances. I have an example here [7].
>>> In this example values of objects are exposed using the 'content'
>>> RDFa attribute [8].
>>>
>>> Each example may not be 100% perfect but what's most interesting is
>>> when you run the each HTML rendering through a RDFa parser [9]
>>> (examples here [10] [11]). The RDF extracted is quite along the
>>> lines of what some might expect an OCCI POX format to be. Note, I'm
>>> not advocating POX, just pointing to the flexibility of RDFa. There
>>> are still some aspects to be worked out but I will follow up on
>>> these in a separate mail (this one is long enough!).
>>>
>>> If you want to see how all of this visually looks then see here:
>>> ontology only [12], ontology and graph instance [13].
>>>
>>> I'd really appreciate and love to hear people's comments, opinions
>>> on this! :-)
>>>
>>> Andy
>>>
>>> [1] http://www.w3.org/TR/rdfa-in-html/
>>> [2] http://dl.dropbox.com/u/165239/occi-rdf.py
>>> [3] http://dl.dropbox.com/u/165239/occi.owl
>>> [4] http://dl.dropbox.com/u/165239/occi-infrastructure.owl
>>> [5] http://dl.dropbox.com/u/165239/occi-sla-at-soi.owl
>>> [6] http://home.edmonds.be/occi-html5-rdfa-one.html
>>> [7] http://home.edmonds.be/occi-html5-rdfa-list.html
>>> [8] http://www.w3.org/TR/2010/WD-rdfa-core-20100422/#s_syntax
>>> [9] http://www.w3.org/2007/08/pyRdfa
>>> [10] http://www.w3.org/2007/08/pyRdfa/extract?uri=http%3A%2F%2Fhome.edmonds.be%2Focci-html5-rdfa-one.html
>>> [11] http://www.w3.org/2007/08/pyRdfa/extract?uri=http%3A%2F%2Fhome.edmonds.be%2Focci-html5-rdfa-list.html
>>> [12] http://dl.dropbox.com/u/165239/occi-rdf-graph-rev2.png
>>> [13] http://dl.dropbox.com/u/165239/occi-rdf-graph-inst-rev2.png
>>>
>>> -------------------------------------------------------------
>>> Intel Ireland Limited (Branch)
>>> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
>>> Registered Number: E902934
>>>
>>> This e-mail and any attachments may contain confidential material for
>>> the sole use of the intended recipient(s). Any review or distribution
>>> by others is strictly prohibited. If you are not the intended
>>> recipient, please contact the sender and delete all copies.
>>>
>>> _______________________________________________
>>> occi-wg mailing list
>>> occi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/occi-wg
>>>
>>>
>> Roger Menday (PhD)
>> <roger.menday at uk.fujitsu.com>
>>
>> Senior Researcher, Fujitsu Laboratories of Europe Limited
>> Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K.
>> Tel: +44 (0) 208 606 4534
>>
>> ______________________________________________________________________
>>
>> Fujitsu Laboratories of Europe Limited
>> Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
>> Registered No. 4153469
>>
>> This e-mail and any attachments are for the sole use of addressee(s) and
>> may contain information which is privileged and confidential. Unauthorised
>> use or copying for disclosure is strictly prohibited. The fact that this
>> e-mail has been scanned by Trendmicro Interscan does not guarantee that
>> it has not been intercepted or amended nor that it is virus-free.
>>
>> -------------------------------------------------------------
>> Intel Ireland Limited (Branch)
>> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
>> Registered Number: E902934
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>>
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>>
>>
>>
>
> -------------------------------------------------------------
> Intel Ireland Limited (Branch)
> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
> Registered Number: E902934
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
>
More information about the occi-wg
mailing list