Re: Another way other than @profile, @vocab or @map

Hello Mark,

On 16/03/2010 23:42, Mark Birbeck wrote:
> Hi Martin,
>
>    
>> I like it Toby, allowing @typeof to accept a full uri is a lot better than
>> my idea and easy to use in RDFa and very little extra cost for parsing,
>>
>> +1 from me on that one too ;)
>>      
> Recent drafts of RDFa support the ability to use URIs and CURIEs
> interchangeably in the RDFa attributes, so we can actually do this
> now.
>
>    

I didn't know that ....Good ...

> However, I don't think it's such a great idea to go from the setting
> of a 'type', to (a) importing predefined tokens (Hixie's approach) or
> (b) declaring namespace prefixes (Toby's approach).
>
> It's a bit of a leap, I think.
>    

I agree, importing anything in general I think is never a "good" thing I 
don't think...

> There are a number of reasons I say this, but most significant is that
> it's increasingly common to use types from one vocabulary with
> predicates from another. In other words, it's less and less common
> that just by knowing the prefix, you know the origin of all of the
> terms.
>
> For example, in some work I was involved in, on government
> consultations, we defined a consultation as:
>
>    a foaf:Document that has a dc:type of arg:Consultation
>
> In other words:
>
>    _:a a foaf:Document .
>    _:a dc:type arg:Consultation .
>
> Similarly, we defined a job vacancy as:
>
>    _:a a foaf:Document .
>    _:a dc:type arg:Vacancy .
>
> (Note that this is a vacancy in the sense of an advert, not the job itself.)
>
> And in another project we defined a research document as:
>
>    _:a a foaf:Document .
>    _:a dc:type arg:Research .
>
> As you can see, knowing that the prefix for the type is 'foaf' tells
> you nothing about the origin of any other predicates.
>    

:)

> With Toby's solution we'd still have to define prefixes for 'dc' and
> 'arg' so that we could express the other values, and with Hixie's
> solution we'd have to magically import every possible property when we
> saw the 'foaf:Document' URI, or we only import one set of
> properties...but which set?.
>
> With profiles on the other hand, we can declare the particular profile
> that we're interested in, and then just do this:
>
>    <div typeof="Document" rel="type" resource="Research">
>      ...
>    </div>
>    

I dont really have an issue with using rdfa profiles Im just not keen on 
the level of indirection that may be involved, It would make parsing 
more intensive, particularly if for whatever reason the profile is down, 
the only way to avoid this is either having a list of profiles stored 
with the parser or having the profile stored along side the document 
that has to be parsed, what happens if it becomes popular practice to 
omit the @profile attribute ...  I worry too much anyway ;)

Better I think to have *all* the relevant information stored with the 
document itself ( like rdfa currently does ) than to introduce external 
files that may or may not be available for parsing.

Best wishes

Martin.

> All we're doing is loading the profile that the author has asked for,
> and therefore the mappings that they want. We haven't done any 'magic'
> behind the scenes, to try to deduce which tokens they want, form a
> limited piece of information.
>
> Regards,
>
> Mark
>
> --
> Mark Birbeck, webBackplane
>
> mark.birbeck@webBackplane.com
>
> http://webBackplane.com/mark-birbeck
>
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)
>    


-- 
Martin McEvoy

Received on Wednesday, 17 March 2010 09:34:31 UTC